This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Security Integration System"

From OWASP
Jump to: navigation, search
(→‎OWASP Tool Project Template)
(→‎OWASP Tool Project Template)
Line 32: Line 32:
 
<li><b>Development teams</b>: I need to do all of the above and within a two week sprint cycle :-)</li>
 
<li><b>Development teams</b>: I need to do all of the above and within a two week sprint cycle :-)</li>
 
</ol>
 
</ol>
 +
  
 
<br>
 
<br>
−
<b>What impact do these stakeholder requirements have on software development</b><br>
+
<b>How these stakeholder requirements are often met?</b><br>
−
When the development team codes, for example, functionality that requires a front end screen and a database.
+
For every development cycle
 
<ol>
 
<ol>
−
<li>Firstly, the dev teams need to read and understand all 99 articles of the GDPR:  to make sure, for example, the data is categorised and user consent is stored</li>
+
<li><b>Development teams</b>: Need to read and understand all 99 articles of the GDPR:  to make sure, for example, the data is categorised and user consent is stored</li>
−
<li>Secondly, the dev teams need to read and understand the 114 controls listed in ISO 27002 (if the use ISO):  To make sure the solution can be safely integrated into the organisations information security management system (ISMS) and for example, application logs are in a format that can be consumed and reported to the SEIM</li>
+
<li><b>Development teams</b>:  Need to read and understand the 114 controls listed in ISO 27002 (if the use ISO):  To make sure the solution can be safely integrated into the organisations information security management system (ISMS) and for example, application logs are in a format that can be consumed and reported to the SEIM</li>
−
<li>Thirdly the dev teams needs to select form the 99 GDPR articles and the 114 ISO controls those that apply to the solution, perform a risk assessment on the selected controls, write security test plans to test selected controls</li>
+
<li><b>Development teams</b>: Need to select from the 99 GDPR articles and the 114 ISO controls those that apply to the solution, perform a risk assessment on the selected controls, write security test plans to test selected controls</li>
−
<li>Fourthly the dev teams need to select an appropriate and approved technical implementation for the selected security control</li>
+
<li><b>Development teams</b>: Need to technically implementation and test security requirements</li>
−
<li>An only then begin development</li>
+
<li><b>Approvers</b>:  Need to hunt through hundreds of automated test results to find the testing evidence proving that the security requirements were tested</li>
 +
<li><b>Business</b>:  Need Scream and shout about not meeting the two week sprint cycle deadline</li>
 
</ol>
 
</ol>
 
<i>Development teams cannot perform these security tasks within a reasonable time frame, let alone a two week sprint cycle By this time the 2 week sprint cycle has elapsed and </i>
 
<i>Development teams cannot perform these security tasks within a reasonable time frame, let alone a two week sprint cycle By this time the 2 week sprint cycle has elapsed and </i>
 
</p>
 
</p>
  
−
 
+
<br>
 +
<b>How should these stakeholder requirements be met</b><br>
 +
For every development cycle
 +
<ol>
 +
<li><b>Information security</b>: Needs to understand the technical implementation and generate a list of security requirements to protect against vulnerabilities</li>
 +
<li><b>Information security</b>: Make sure development teams understand the security requirements</li>
 +
<li><b>Development teams</b>: Need to implement, test and record evidence proving the security requirements are met</li>
 +
<li><b>Approvers</b>:  Need to review testing evidence, accept the risk and approve the release</li>
 +
<li><b>Compliance and Assurance</b>: Need to review collect evidence for consistency and traceability</li>
 +
</ol>
  
  
Line 52: Line 63:
 
<br>
 
<br>
 
<p>
 
<p>
−
<b>The solution(s)</b><br>
+
<b>Why is it so hard to meet these stakeholder requirements?</b><br>
−
There are 2 ways to ensure development teams meet these varied requirements.<br>
 
−
<b>Without control integration</b>:
 
 
<ul>
 
<ul>
−
  <li>Dev teams read and understand the GDPR, ISO 27002, familiarise themselves with the organisation ISMS requirements and also, keep up to date with the technical changes in the development language they use.</li>
+
  <li>Each stakeholder represents a separate domain, each domain contains a huge body of knowledge.</li>
−
  <li>This usually results in dev teams being referred to 50 page policy documents and told "Please implement this and we will check it after" </li>
+
<li>This huge body of security, risk, compliance and assurance knowledge needs to be filtered, made applicable and applied to every critical function in the application landscape</li>
 +
<li>Adding to the complexity is that every critical function in the application landscape could be coded in a different language and implemented in a different environment</li>
 +
  <li>Further compounding the problem is the fact that most other organisational processes have a <b>first line of defence that integrates these security controls into the process</b> but, unless your organisation is gifted with budget and resources the software development process does not have a first line of defence</li>
 
</ul>
 
</ul>
−
<b>With a planned control integration effort</b>:
+
<b>The lack of a dedicated fist line of defence or a planned security control implementation usually results in a a 50 page security policy being dumped on the developers desk with the comment "Implement this please"</b>
−
<ul>
+
 
−
<li>Using a very simple, 5 screen, mySQL db tool based on OWASP data that</li>
+
<br>
 +
<b>What will the role of a first line of defence be in the software development process</b>:
 
<ol>
 
<ol>
 
<li>Generates security requirements before coding begins</li>
 
<li>Generates security requirements before coding begins</li>
Line 69: Line 81:
 
<li>Inform risk based decision making and prioritising</li>
 
<li>Inform risk based decision making and prioritising</li>
 
</ol>
 
</ol>
−
</ul>
+
<b>To combat the limited budget and resources the Secure coding tool attempts to fill the shoes of the first line of defence</b>
  
−
<br>
 
−
<p>
 
−
<b>What does the Secure coding tool do?</b><br>
 
−
The secure coding tool, goes beyond theory and procedure and attempts to implement a planned control integration effort.<br>
 
−
The Secure coding tool is written in MVC \ MySQL and consists of 5 screens each serving a specific stakeholder
 
−
<ol>
 
−
<li><b>Information security stakeholder</b>: Filters the security requirements according to the functional requirement:  Streamlining security requirements generation </li>
 
−
<li><b>Dev team stakeholder</b>: Provides secure code blocks to implement the security requirement:  Providing code level guidance for developers towards correctly implementing security requirements</li>
 
−
<li><b>Dev team stakeholder</b>: Provides security test plans to testing the security requirements: Guiding testers towards correctly verifying security requirements are met</li>
 
−
<li><b>Compliance and assurance stakeholder</b>: Provides a central store for testing results: Promoting traceability through requirements and serving as a quick reference screen for assurance to view control assurance evidence, speeding up the approval process and minimising its impact on responsiveness to market</li>
 
−
<li><b>IT risk stakeholder</b>: Provides IT risk with an overview of each applications exposure to OWASP TOP 10 risks:  Informing risk based decision making and prioritising</li>
 
−
</ol>
 
  
 
<br>
 
<br>
Line 89: Line 89:
 
It's important to note that the secure coding tool is part of a system of components to secure software development. <br>
 
It's important to note that the secure coding tool is part of a system of components to secure software development. <br>
 
Other components of the system include <b>governance</b>, <b>human support</b> and <b>vulnerability management<b>. <br>
 
Other components of the system include <b>governance</b>, <b>human support</b> and <b>vulnerability management<b>. <br>
−
I've detailed these components in a different article that will be published in the Nov/Dec issue of the ISC2 magazine.  
+
I've detailed these components in a different article that will be published in the Nov/Dec issue of the ISC2 magazine, I will add a link here after publication.  
 
</p>
 
</p>
−
 
−
 
−
 
−
<br>
 
−
<p>
 
−
<b>Implementation instructions</b><br>
 
−
Not a silver bullet ready to go
 
−
<ol>
 
−
<li>Filter the list of OWASP risks</li>
 
−
<li>Filter the list of OWASP ASVS requirements</li>
 
−
<li>Add additional architectural security requirements</li>
 
−
<li>Filter the list of OWASP security tests</li>
 
−
</ol>
 
−
</p>
 
−
 
−
After reading this short article, please take a look at the video link below to see the tool in action.
 
−
 
−
Summary of the tool functionality:
 
−
Developers
 
−
Testers
 
−
Approvers \Assurance
 
−
IT risk
 
  
 
==Description==
 
==Description==

Revision as of 11:59, 13 August 2019

OWASP Project Header.jpg

Instructions are in RED text and should be removed from your document by deleting the text with the span tags. This document is intended to serve as an example of what is required of an OWASP project wiki page. The text in red serves as instructions, while the text in black serves as an example. Text in black is expected to be replaced entirely with information specific to your OWASP project.

Project About

PROJECT INFO
What does this OWASP project offer you? 		RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: Software Integration System
Purpose: N/A
License: N/A
who is working on this project?
Project Leader(s):
  • Michael Bergman @
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: N/A
Project Roadmap: Not Yet Created
Key Contacts
  • Contact Michael Bergman @ to contribute to this project
  • Contact Michael Bergman @ to review or sponsor this project
current release
Not Yet Published
last reviewed release
Not Yet Reviewed


other releases


OWASP Tool Project Template

This section should include an overview of what the project is, why the project was started, and what security issue is being addressed by the project deliverable.


Introduction
Secure software development has a number of stakeholders.

  1. IT risk: I need to know where my highest risks are, so I can focus on mitigating these
  2. Information security: I need to generate a list f security requirements to protect against vulnerabilities
  3. Compliance and Assurance: I need to ensure the code meets security requirements and we have evidence proving that
  4. Business: I need to get the functionality to the market before our competitors
  5. Development teams: I need to do all of the above and within a two week sprint cycle :-)



How these stakeholder requirements are often met?
For every development cycle

  1. Development teams: Need to read and understand all 99 articles of the GDPR: to make sure, for example, the data is categorised and user consent is stored
  2. Development teams: Need to read and understand the 114 controls listed in ISO 27002 (if the use ISO): To make sure the solution can be safely integrated into the organisations information security management system (ISMS) and for example, application logs are in a format that can be consumed and reported to the SEIM
  3. Development teams: Need to select from the 99 GDPR articles and the 114 ISO controls those that apply to the solution, perform a risk assessment on the selected controls, write security test plans to test selected controls
  4. Development teams: Need to technically implementation and test security requirements
  5. Approvers: Need to hunt through hundreds of automated test results to find the testing evidence proving that the security requirements were tested
  6. Business: Need Scream and shout about not meeting the two week sprint cycle deadline

Development teams cannot perform these security tasks within a reasonable time frame, let alone a two week sprint cycle By this time the 2 week sprint cycle has elapsed and


How should these stakeholder requirements be met
For every development cycle

  1. Information security: Needs to understand the technical implementation and generate a list of security requirements to protect against vulnerabilities
  2. Information security: Make sure development teams understand the security requirements
  3. Development teams: Need to implement, test and record evidence proving the security requirements are met
  4. Approvers: Need to review testing evidence, accept the risk and approve the release
  5. Compliance and Assurance: Need to review collect evidence for consistency and traceability



Why is it so hard to meet these stakeholder requirements?

  • Each stakeholder represents a separate domain, each domain contains a huge body of knowledge.
  • This huge body of security, risk, compliance and assurance knowledge needs to be filtered, made applicable and applied to every critical function in the application landscape
  • Adding to the complexity is that every critical function in the application landscape could be coded in a different language and implemented in a different environment
  • Further compounding the problem is the fact that most other organisational processes have a first line of defence that integrates these security controls into the process but, unless your organisation is gifted with budget and resources the software development process does not have a first line of defence

The lack of a dedicated fist line of defence or a planned security control implementation usually results in a a 50 page security policy being dumped on the developers desk with the comment "Implement this please"


What will the role of a first line of defence be in the software development process:

  1. Generates security requirements before coding begins
  2. Guiding developers towards correctly implementing security requirements
  3. Guiding testers towards correctly verifying security requirements are met
  4. Speeding up the approval process to minimise its impact on responsiveness to market
  5. Inform risk based decision making and prioritising

To combat the limited budget and resources the Secure coding tool attempts to fill the shoes of the first line of defence



<p> Please note
It's important to note that the secure coding tool is part of a system of components to secure software development.
Other components of the system include governance, human support and vulnerability management<b>.
I've detailed these components in a different article that will be published in the Nov/Dec issue of the ISC2 magazine, I will add a link here after publication. </p>

Description

This is where you need to add your more robust project description. A project description should outline the purpose of the project, how it is used, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, so project leaders should ensure that the description is meaningful.

The Tool Project Template is simply a sample project that was developed for instructional purposes that can be used to create default project pages for a Tool project. After copying this template to your new project, all you have to do is follow the instructions in red, replace the sample text with text suited for your project, and then delete the sections in red. Doing so should make it clearer to both consumers of this project, as well as OWASP reviewers who are trying to determine if the project can be promoted to the next category. The information requested is also intended to help Project Leaders think about the roadmap and feature priorities, and give guidance to the reviews as a result of that effort.

Creating a new set of project pages from scratch can be a challenging task. By providing a sample layout, with instructional text and examples, the OWASP Tool Project Template makes it easier for Project Leaders to create effective security projects and hence helps promote security.

Contextual custom dictionary builder with character substitution and word variations for pen-testers

Licensing

A project must be licensed under a community friendly or open source license.  For more information on OWASP recommended licenses, please see OWASP Licenses. While OWASP does not promote any particular license over another, the vast majority of projects have chosen a Creative Commons license variant for documentation projects, or a GNU General Public License variant for tools and code projects. This example assumes that you want to use the AGPL 3.0 license.

This program is free software: you can redistribute it and/or modify it under the terms of the link GNU Affero General Public License 3.0 as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. OWASP XXX and any contributions are Copyright © by {the Project Leader(s) or OWASP} {Year(s)}.

Roadmap

As of November, 2013, the highest priorities for the next 6 months are:

  • Complete the first draft of the Tool Project Template
  • Get other people to review the Tool Project Template and provide feedback
  • Incorporate feedback into changes in the Tool Project Template
  • Finalize the Tool Project template and have it reviewed to be promoted from an Incubator Project to a Lab Project

Subsequent Releases will add

  • Internationalization Support
  • Additional Unit Tests
  • Automated Regression tests

Getting Involved

Involvement in the development and promotion of Tool Project Template is actively encouraged! You do not have to be a security expert or a programmer to contribute. Some of the ways you can help are as follows:

Project Resources

This is where you can link to the key locations for project files, including setup programs, the source code repository, online documentation, a Wiki Home Page, threaded discussions about the project, and Issue Tracking system, etc.

Installation Package

Source Code

What's New (Revision History)

Documentation

Wiki Home Page

Issue Tracker

Slide Presentation

Video

Project Leader

A project leader is the individual who decides to lead the project throughout its lifecycle. The project leader is responsible for communicating the project’s progress to the OWASP Foundation, and he/she is ultimately responsible for the project’s deliverables. The project leader must provide OWASP with his/her real name and contact e-mail address for his/her project application to be accepted, as OWASP prides itself on the openness of its products, operations, and members.

Michael Bergman

Related Projects

This is where you can link to other OWASP Projects that are similar to yours.

Classifications

Project Type Files TOOL.jpg
Incubator Project
Owasp-defenders-small.png
Affero General Public License 3.0

Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Security_Integration_System&oldid=253677"