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)
(→‎What is the Secure code assurance tool (SCAT))
 
(492 intermediate revisions by the same user not shown)
Line 2: Line 2:
  
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
−
| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
+
| valign="top"  style="border-right: 1px dotted ;padding-right:25px;" |
  
−
<span style="color:#ff0000">
+
==What is the Secure code assurance tool (SCAT)==
−
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.
+
<h1><b>What is the SCAT</b></h1>
−
</span>
 
−
==Project About==
 
−
<span style="color:#ff0000">
 
−
{{Template:Project_About
 
−
  | project_name=Software Integration System
 
−
  | leader_name1=Michael Bergman
 
− 
−
}}
 
  
 +
[https://www.linkedin.com/pulse/secure-code-assurance-tool-scat-version-20-michael-bergman/ For more information on the <b>why</b> behind the SCAT, read my linkedIn Article here]
  
−
==OWASP Tool Project Template==
+
==What is the SCAT==
−
<span style="color:#ff0000">
 
−
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. Some readers may be discouraged from looking further at the project if they do not understand the significance of the security concern that is being addressed, so provide enough context so the average reader will continue on with reading the description. You shouldn't assume the reader will understand the objective by providing security terminology, e.g. this project builds cryptographic algorithms, but should also endeavor to explain what they are used for.
 
−
</span>
 
  
−
The OWASP Tool Template Project is a template designed to help Project Leaders create suitable project pages for OWASP Projects.  By following the instructional text in red (and then deleting it) it should be easier to understand what information OWASP and the project users are looking for.  And it's easy to get started by simply creating a new project from the appropriate project template.
+
<ul>
  
−
<b>Introduction</b>
+
<li>SCAT is a <span style="text-decoration:underline;">process integrity tool</span>, implementing a consistent, authorized and auditable software development process
−
Secure coding is an umbrella term that covers the requirements of IT risk, assurance, Information security and compliance. 
 
−
This means that when the development team codes a functional requirement they must not only consider the functional requirement and getting it to market before competitors but also the risks that functionality exposes the organisation too.
 
  
−
<b>What is the problem the secure coding tool is tying to fixing?</b>
+
<li>SCAT is used by development teams to build, verify and assure secure software
−
<p>
+
<ul>
−
When the development team codes, for example, a functionality that requires a ASW RDS.
+
−
1. 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><strong>Build</strong>: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation
−
2. 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
+
   
−
3. 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><strong>Verify</strong>: uses a combination of manual test plans and SATS tools to guide and verify correct implementation
−
4. Fourthly the dev teams need to select an appropriate and approved technical implementation for the selected security control
+
−
5. An only then begin development
+
<li><strong>Assure</strong>: centrally stores and publishes evidence of secure development and testing as an audit trail. Providing traceability through requirements and proving that security <span style="text-decoration:underline;">controls operate efficiently over a period of time</span>
−
<b>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 </b>
+
</li>  
−
</p>
+
</ul>
  
−
<b>The solution(s)</b>
+
<li>SCAT is <span style="text-decoration:underline;">not a point in time security verification tool </span>for detecting vulnerabilities after development</li>  
−
<p>
+
</ul>
−
There are 2 ways to ensure development teams meet these varied requirements.
 
−
1.  <b>Without control integration</b>: 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.
 
−
<p>This usually results in dev teams being referred to 50 page policy documents and told "Please implement this and we will check it after"</p>
 
−
2. <b>With a planned control integration effort</b>:
 
−
<p>We write a very simple tool that
 
−
1. <i>Filters the security requirements according to the functional requirement</i>:  Streamlining security requirements generation
 
−
2. Provides secure code blocks to implement the security requirement:  Guiding developers towards correctly implementing security requirements
 
−
3. Provides security test plans to testing the security requirements: Guiding testers towards correctly verifying security requirements are met
 
−
4. 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
 
−
5. Provides IT risk with an overview of each applications exposure to OWASP TOP 10 risks:  landscape and how each aand gives them to development teams when they need it and in a format they need it.</p>
 
  
−
The secure coding tool is an attempt to follow the second way.  Before we summerise what the tool does its important to know that the tool is part of a system of components to secure software development. Other components of the system include governance and vulnerability management. I've detailed these components in a different article that will be published in the Nov/Dec issue of the ISC2 magazine.
+
==Process integrity and point in time tools: How they work in the SDLC==
−
</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:
+
[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]
−
Developers
 
−
Testers
 
−
Approvers \Assurance
 
−
IT risk
 
  
−
==Description==
+
<h1><b>Technical Description</b></h1>
−
<span style="color:#ff0000">
 
−
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. 
 
−
</span>
 
  
−
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.
+
==Without further complicating development environment==
 +
<ul>
  
−
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.
+
<li>SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment
  
−
Contextual custom dictionary builder with character substitution and word variations for pen-testers
+
<li>Integrates with Jira and runs ZAP and SonarQube in docker containers
  
−
==Licensing==
+
<li>SCAT is part of three domains to consider when securing software development.  <em>I've detailed the other domains in an article that will be published in the Nov/Dec issue of the ISC2 magazine, I will add a link here after publication.</em>
−
<span style="color:#ff0000">
+
 
−
A project must be licensed under a community friendly or open source license.  For more information on OWASP recommended licenses, please see [https://www.owasp.org/index.php/OWASP_Licenses 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.
+
 
−
</span>
+
 
 +
<h1><b>See how developers use SCAT</b></h1>
 +
See below how the Secure code assurance tool integrates security into software development phases
 +
 
 +
==Sprint planning phase ==
 +
<b>Objective</b>: Ensures security requirements are understood <br>
 +
 
 +
    <ul>
 +
        <li><b>Developers</b> use the <b>Identify risks</b> screen to<br>
 +
            <ol>
 +
                <li>Select the critical function to developing/changing</li>
 +
                <li>Identify the technologies used</li>
 +
                <li>Automatically generate the security requirements and tests</li>
 +
                [https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
 +
            </ol>
 +
        <li><b>Product owners</b> use the <b>Secure code requirements</b> screen to<br>
 +
            <ol>
 +
              <li>Create an audit trail to store evidence of secure development</li>
 +
                <li>Create Jira tickets for requirements and tests to manage work</li>
 +
            </ol>
 +
      </li>
 +
    </ul>
 +
 
 +
== Development phase ==
 +
 
 +
<b>Objective</b>: Ensure correct implementation of security requirements<br>
 +
    <ul>
 +
        <li><b>Developers</b> use the <b>Secure development</b> screen to<br>
 +
            <ol>
 +
                <li>View and understand how to attack and prevent the risk</li>
 +
                <li>View the secure code requirements</li>
 +
                <li>View the secure code block to implement the security requirement</li>
 +
                <li>Manage development effort in Jira</li>
 +
                <li>After development run a ZAP basic scan to verify security requirements have been correctly implemented</li>
 +
                [https://youtu.be/1pSatE_7mEs See how the tool helps developers understand security requirements and write secure code]
 +
            </ol>
 +
      </li>
 +
  </ul>
 +
 
 +
== Secure code review phase ==
 +
 
 +
<b>Objective</b>: Ensure correct implementation of security requirements<br>
 +
 
 +
    <ul>
 +
        <li><b>Code reviewers</b> use the <b>Secure code review </b> screen to<br>
 +
            <ol>
 +
                <li>Guide manually secure code review</li>
 +
                <li>After manual secure code review run a Sonarqube scan to verify security requirements have been correctly implemented</li>
 +
                [https://youtu.be/ygre0SrWxD4 See how the tool verifies correct security requirements implementation]
 +
            </ol>
 +
      </li>
 +
    </ul>
 +
 
 +
== Testing phase==
  
−
This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.gnu.org/licenses/agpl-3.0.html 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 &copy; by {the Project Leader(s) or OWASP} {Year(s)}. 
+
<b>Objective</b>: Ensure valid security testing<br>
 +
    <ul>
 +
        <li><b>Testers</b> use the <b>Secure testing</b> screen to<br>
 +
            <ol>
 +
                <li>View the test plans required to test the risk</li>
 +
                <li>Manage testing effort in Jira</li>
 +
                [https://youtu.be/QdbCzheceUw See how the tool helps testers test risk mitigation efforts]
 +
            </ol>
 +
      </li>
 +
    </ul>
 +
== Approval phase ==
  
−
==Roadmap==
+
<b>Objective</b>: Streamline the approval and audit process<br>
−
<span style="color:#ff0000">
 
−
As of <strong>November, 2013, the highest priorities for the next 6 months</strong> are:
 
−
<strong>
 
−
* 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
 
−
</strong>
 
  
−
Subsequent Releases will add
+
<ul>
−
<strong>
+
        <li><b>Approvers</b> use the <b>Assurance evidence </b> screen to<br>
−
* Internationalization Support
+
            <ol>
−
* Additional Unit Tests
+
                <li>View relevant testing evidence alongside the risk, reducing the time assurance teams need to examine and approve releases</li>
−
* Automated Regression tests
+
                <li>View verified development effort and whether it falls within risk tolerance levels</li>
−
</strong>
+
                [https://youtu.be/oyKK3Mq13B4 See how the tool streamlines the approval process with centrally stored testing evidence]
 +
            </ol>
 +
      </li>
 +
    </ul>
 +
== Risk management ==
 +
<b>Objective</b>: Enable risk managers to prioritise, plan and monitor mitigation efforts<br>
  
−
==Getting Involved==
+
    <ul>
−
<span style="color:#ff0000">
+
        <li><b>Risk managers</b> use the <b>Application risk exposure</b> screen to<br>
−
Involvement in the development and promotion of <strong>Tool Project Template</strong> is actively encouraged!
+
            <ol>
−
You do not have to be a security expert or a programmer to contribute.
+
                <li>View each application critical function and the associated risks</li>
−
Some of the ways you can help are as follows:
+
                <li>Identify where mitigation effort is required by viewing which risks require security requirements</li>
 +
                <li>Identify where development effort is required by viewing which security requirements need secure code blocks</li>
 +
                <li>Identify where extra testing effort is required by viewing which risks require security test plans</li>
 +
                [https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
 +
            </ol>
 +
      </li>
 +
    </ul>
 +
<br>
 +
<br>
  
−
| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
+
<h1> <b>Preparation phase</b></h1>
 +
When developing secure software we need to consider both standard secure code and client specific architectural requirements
  
−
== Project Resources ==
+
== Standard secure code requirements==
−
<span style="color:#ff0000">
 
−
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.
 
−
</span>
 
  
−
[https://github.com/SamanthaGroves Installation Package]
+
<ul>
 +
        <li>SCAT comes out the box with a standard OWASP secure code requirements map. This mapping need to be modified to the specific organisation requirements</li>
 +
<br>
 +
        <li><b>Information security and development team</b> use the <b>Internal mapping </b> screen to
 +
            <ol>
 +
                <li>Map the security requirements to OWASP risks</li>
 +
                <li>Map organisation approved secure code blocks to security requirements</li>
 +
                <li>Map security test plans to OWASP risks</li>
 +
                [https://youtu.be/EkWdAC1sbkE See how to setup the SCAT's internal mapping]
 +
            </ol>
 +
      </li>
 +
</ul>
  
−
[https://github.com/SamanthaGroves Source Code]
+
== Client specific architectural requirements==
  
−
[https://github.com/SamanthaGroves What's New (Revision History)]
+
<ul>
 +
    <li>To generate these requirements we perform a risk assessment on client application landscape and identify</li>
 +
<ol>
 +
    <li>Critical applications and functions</li>
 +
    <li>Risk associated with each critical application function</li>
 +
    <li>Architectural security requirements to secure each critical application functions</li>
 +
    <li>Client specific secure code blocks to implement security requirements</li>
 +
    <li>Secure test plans to verify risk has been mitigated</li>
 +
</ol>
 +
<br>
 +
    <li><b>Tool administrators</b> use the <b>Internal mapping </b> screen to
 +
<ol>
 +
    <li>Create json files of the organisation specific risks, security requirements, secure code blocks and tests</li>
 +
    <li>Import these into the SCAT</li>
 +
    [https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
 +
</ol>
 +
</ul>
  
−
[https://github.com/SamanthaGroves Documentation]
+
<br>
 +
<br>
  
−
[https://github.com/SamanthaGroves Wiki Home Page]
+
<h1>Project information</h1>
  
−
[https://github.com/SamanthaGroves Issue Tracker]
+
==Licensing==
 +
This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.gnu.org/licenses/agpl-3.0.html 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.
  
−
[https://github.com/SamanthaGroves Slide Presentation]
+
== Interested in contributing==
 +
[https://www.linkedin.com/in/michael-bergman-99826212a/ Please send a connect request with subject SCAT]
  
−
[https://github.com/SamanthaGroves Video]
+
== Project Resources ==
  
−
== Project Leader ==
+
[Installation Package]
−
<span style="color:#ff0000">
 
−
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.
 
−
</span>
 
  
−
[mailto://[email protected] Michael Bergman]
+
[Source Code]
  
−
== Related Projects ==
+
== Project Leader ==
−
<span style="color:#ff0000">
+
[https://www.linkedin.com/in/michael-bergman-99826212a/ Michael Bergman LinkedIn]
−
This is where you can link to other OWASP Projects that are similar to yours.  
 
−
</span>
 
−
* [[OWASP_Code_Project_Template]]
 
−
* [[OWASP_Documentation_Project_Template]]
 
  
 
==Classifications==
 
==Classifications==

Latest revision as of 18:33, 14 October 2019

OWASP Project Header.jpg

What is the Secure code assurance tool (SCAT)

For more information on the why behind the SCAT, read my linkedIn Article here

What is the SCAT

  • SCAT is a process integrity tool, implementing a consistent, authorized and auditable software development process
  • SCAT is used by development teams to build, verify and assure secure software
    • Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation
    • Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation
    • Assure: centrally stores and publishes evidence of secure development and testing as an audit trail. Providing traceability through requirements and proving that security controls operate efficiently over a period of time
  • SCAT is not a point in time security verification tool for detecting vulnerabilities after development

Process integrity and point in time tools: How they work in the SDLC

Process integrity VS point in time without check

Without further complicating development environment

  • SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment
  • Integrates with Jira and runs ZAP and SonarQube in docker containers
  • SCAT is part of three domains to consider when securing software development. I've detailed the other domains in an article that will be published in the Nov/Dec issue of the ISC2 magazine, I will add a link here after publication.

See below how the Secure code assurance tool integrates security into software development phases

Sprint planning phase

Objective: Ensures security requirements are understood

  • Developers use the Identify risks screen to
    1. Select the critical function to developing/changing
    2. Identify the technologies used
    3. Automatically generate the security requirements and tests
      4.                See how to use the tools and its internal mapping to generate security requirements
  • Product owners use the Secure code requirements screen to
    1. Create an audit trail to store evidence of secure development
    2. Create Jira tickets for requirements and tests to manage work

Development phase

Objective: Ensure correct implementation of security requirements

Secure code review phase

Objective: Ensure correct implementation of security requirements

Testing phase

Objective: Ensure valid security testing

Approval phase

Objective: Streamline the approval and audit process

Risk management

Objective: Enable risk managers to prioritise, plan and monitor mitigation efforts

  • Risk managers use the Application risk exposure screen to
    1. View each application critical function and the associated risks
    2. Identify where mitigation effort is required by viewing which risks require security requirements
    3. Identify where development effort is required by viewing which security requirements need secure code blocks
    4. Identify where extra testing effort is required by viewing which risks require security test plans
      5.                See how the Application landscape overview screen informs risk based decision making



When developing secure software we need to consider both standard secure code and client specific architectural requirements

Standard secure code requirements

  • SCAT comes out the box with a standard OWASP secure code requirements map. This mapping need to be modified to the specific organisation requirements


  • Information security and development team use the Internal mapping screen to
    1. Map the security requirements to OWASP risks
    2. Map organisation approved secure code blocks to security requirements
    3. Map security test plans to OWASP risks
      4.                See how to setup the SCAT's internal mapping

Client specific architectural requirements

  • To generate these requirements we perform a risk assessment on client application landscape and identify
    1. Critical applications and functions
    2. Risk associated with each critical application function
    3. Architectural security requirements to secure each critical application functions
    4. Client specific secure code blocks to implement security requirements
    5. Secure test plans to verify risk has been mitigated


  • Tool administrators use the Internal mapping screen to
    1. Create json files of the organisation specific risks, security requirements, secure code blocks and tests
    2. Import these into the SCAT
      3.     See how to import organisations specific risks, security requirements, secure code blocks and tests



Licensing

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.

Interested in contributing

Please send a connect request with subject SCAT

Project Resources

[Installation Package]

[Source Code]

Project Leader

Michael Bergman LinkedIn

Classifications

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