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
(→‎Description)
(→‎What is the Secure code assurance tool (SCAT))
 
(145 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;" |
  
−
==<b>Table of content</b> ==
+
==What is the Secure code assurance tool (SCAT)==
−
<ol>
+
<h1><b>What is the SCAT</b></h1>
−
<li>[https://www.owasp.org/index.php?title=OWASP_Security_Integration_System#Description Description of the Secure code assurance tool (SCAT) and how it builds, verifies and assures secure software]</li>
+
 
−
<li>[https://www.owasp.org/index.php?title=OWASP_Security_Integration_System#See_how_developers_use_SCAT See how the SCAT single purpose screens integrate security into each of the SDLC phases]</li>
+
[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]
−
<li>[https://www.owasp.org/index.php?title=OWASP_Security_Integration_System#Preparation_phase How to import client specific risks, security requirements and tests]</li>
 
−
</ol>
 
  
−
==<b>What is the Secure code assurance tool (SCAT)</b> ==
+
==What is the SCAT==
  
 
<ul>
 
<ul>
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:0pt">
 
−
SCAT is used by inhouse and third party development teams to build, verify and assure secure software
 
−
</div>
 
−
=== Build ===
 
−
<ul>
 
−
<li>
 
−
SCAT uses code level guidance to clearly instructs developers on how to correctly implement security requirements
 
−
</li>
 
−
</ul>
 
  
−
==<b>Description</b> ==
+
<li>SCAT is a <span style="text-decoration:underline;">process integrity tool</span>, implementing a consistent, authorized and auditable software development process
  
 +
<li>SCAT is used by development teams to build, verify and assure secure software
 
<ul>
 
<ul>
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:0pt">
+
−
SCAT is used by inhouse and third party development teams to build, verify and assure secure software
+
<li><strong>Build</strong>: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation
−
</div>
+
−
=== Build ===
+
<li><strong>Verify</strong>: uses a combination of manual test plans and SATS tools to guide and verify correct implementation
−
<ul>
+
−
<li>
+
<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>
−
SCAT uses code level guidance to clearly instructs developers on how to correctly implement security requirements
+
</li>  
−
</li>
 
 
</ul>
 
</ul>
−
=== Verify ===
+
 
−
<ul>
+
<li>SCAT is <span style="text-decoration:underline;">not a point in time security verification tool </span>for detecting vulnerabilities after development</li>  
−
<li>SCAT uses a combination of ZAP basic scans and security test plans to verify correct implementation of security requirements</li>
 
 
</ul>
 
</ul>
−
=== Assure ===
+
 
 +
==Process integrity and point in time tools: How they work in the SDLC==
 +
 
 +
[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]
 +
 
 +
<h1><b>Technical Description</b></h1>
 +
 
 +
==Without further complicating development environment==
 
<ul>
 
<ul>
−
<li>SCAT centrally stores and publishes test results.  Providing traceability through requirements and assurance evidence of correct implementation</li>
+
 
−
</ul>
+
<li>SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment
 +
 
 +
<li>Integrates with Jira and runs ZAP and SonarQube in docker containers
 +
 
 +
<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>
  
  
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:0pt">
 
−
SCAT has the following governance objectives implemented by the following “first line of defense” functions
 
−
</div>
 
−
[[File:SCATGovObj.png|thumb]]
 
−
=== Benefits realisation: Enabling development teams to deliver at speed===
 
−
<ol>
 
−
<li>[https://www.owasp.org/index.php?title=OWASP_Security_Integration_System#Promoting_compliance_to_security_requirements Promoting compliance to security requirements]</li>
 
−
<li>[https://www.owasp.org/index.php?title=OWASP_Security_Integration_System#Minimising_the_impact_of_audit_and_assurance Minimising the impact of audit and assurance]</li>
 
−
</ol>
 
−
=== Risk optimisation: Minimise the negative and maximise the positive consequences===
 
−
<ol>
 
−
<li>[https://www.owasp.org/index.php?title=OWASP_Security_Integration_System#Informing_risk_based_decision_making Informing risk based decision making]</li>
 
−
</ol>
 
−
=== Resource optimisation: Predictable, repeatable and consistent level of security across all teams ===
 
−
<ol>
 
−
<li>[https://www.owasp.org/index.php?title=OWASP_Security_Integration_System#Integrating_security_into_the_software_development_process Integrating security into the software development process]</li>
 
−
</ol>
 
−
<br>
 
−
<li>SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment</li>
 
−
<li>SCAT is part of three domains to consider when securing software development</li>
 
−
<i>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.</i>
 
−
</ul>
 
−
<br>
 
−
<br>
 
  
−
== <b>See how developers use SCAT</b>==
+
<h1><b>See how developers use SCAT</b></h1>
 
See below how the Secure code assurance tool integrates security into software development phases
 
See below how the Secure code assurance tool integrates security into software development phases
−
<ul>
 
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
−
=== <li>Sprint planning phase</li> ===
 
  
−
<b>Objective</b>: Enabling developers to generate security requirements before development begins <br>
+
==Sprint planning phase ==
−
<b>How</b><br>
+
<b>Objective</b>: Ensures security requirements are understood <br>
−
<ol>
+
 
−
    <li>Link security risk and requirements to specific technologies</li>
 
−
    <li>Developers select technologies and get the lit of associated risks and security requirements</li>
 
−
</ol>
 
−
</div>
 
 
     <ul>
 
     <ul>
 
         <li><b>Developers</b> use the <b>Identify risks</b> screen to<br>
 
         <li><b>Developers</b> use the <b>Identify risks</b> screen to<br>
 
             <ol>
 
             <ol>
−
                 <li>Select the application critical function they are developing/changing</li>
+
                 <li>Select the critical function to developing/changing</li>
−
                 <li>Identify the technologies they are using to develop/change the application critical function</li>
+
                 <li>Identify the technologies used</li>
−
                 <li>The Secure code assurance tools uses its internal mapping to automatically generate the security requirements associated with using this technology</li>
+
                 <li>Automatically generate the security requirements and tests</li>
−
                 [https://youtu.be/WQVzthyGL4U See how to use the tools and its internal mapping to generate security requirements]
+
                 [https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
 
             </ol>
 
             </ol>
 
         <li><b>Product owners</b> use the <b>Secure code requirements</b> screen to<br>
 
         <li><b>Product owners</b> use the <b>Secure code requirements</b> screen to<br>
 
             <ol>
 
             <ol>
−
                 <li>Export security requirements for import into backlog management tools</li>
+
              <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>
 
             </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
−
=== <li>Development phase</li> ===
 
  
−
<b>Objective</b>: Consistent and correct implementation of security requirements across all teams<br>
+
== Development phase ==
−
<b>How</b><br>
+
 
−
<ol>
+
<b>Objective</b>: Ensure correct implementation of security requirements<br>
−
    <li>Organisation approved secure code blocks for each security requirement</li>
 
−
    <li>ZAP basic vulnerability scan to verify understanding</li>
 
−
</ol>
 
−
</div>
 
 
     <ul>
 
     <ul>
 
         <li><b>Developers</b> use the <b>Secure development</b> screen to<br>
 
         <li><b>Developers</b> use the <b>Secure development</b> screen to<br>
 
             <ol>
 
             <ol>
−
                 <li>View and understand how to attack and prevent the risks associated with the critical function</li>
+
                 <li>View and understand how to attack and prevent the risk</li>
−
                 <li>View the secure code requirements to protect against exploitation</li>
+
                 <li>View the secure code requirements</li>
 
                 <li>View the secure code block to implement the security requirement</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>
 
                 <li>After development run a ZAP basic scan to verify security requirements have been correctly implemented</li>
−
                 [https://youtu.be/_YnNjCB5sC8 See how the tool helps developers understand security requirements and write secure code]
+
                 [https://youtu.be/1pSatE_7mEs See how the tool helps developers understand security requirements and write secure code]
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
   </ul>
 
   </ul>
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
  
−
=== <li>Testing phase</li> ===
+
== 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==
  
−
<b>Objective</b>: Guide the secure testing process<br>
+
<b>Objective</b>: Ensure valid security testing<br>
−
<b>How</b><br>
 
−
<ol>
 
−
    <li>Providing secure tests plans to test risk/li>
 
−
    <li>Successful test results from organisational test suite is centrally stored against each risk</li>
 
−
</ol>
 
−
</div>
 
 
     <ul>
 
     <ul>
 
         <li><b>Testers</b> use the <b>Secure testing</b> screen to<br>
 
         <li><b>Testers</b> use the <b>Secure testing</b> screen to<br>
 
             <ol>
 
             <ol>
 
                 <li>View the test plans required to test the risk</li>
 
                 <li>View the test plans required to test the risk</li>
−
                 <li>Attach testing result to the test plan as control assurance evidence proving the risk has been mitigated</li>
+
                 <li>Manage testing effort in Jira</li>
−
                <li>The Secure code assurance tool does not integrate with any testing tools other than OWASP ZAP.  Testing results generated outside of the secure code assurance tool is manually uploaded and stored</li>
+
                 [https://youtu.be/QdbCzheceUw See how the tool helps testers test risk mitigation efforts]
−
                 [https://youtu.be/VixapzUB_ts See how the tool helps testers test risk mitigation efforts and store testing evidence]
 
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
+
== Approval phase ==
−
=== <li>Approval phase</li> ===
 
  
 
<b>Objective</b>: Streamline the approval and audit process<br>
 
<b>Objective</b>: Streamline the approval and audit process<br>
−
<b>How</b><br>
+
 
−
<ol>
 
−
    <li>Providing traceability through requirements by centrally publishing the risk alongside its secure test plan and test results/li>
 
−
    <li>Giving approvers and auditors all the information they require for their assessment</li>
 
−
</ol>
 
−
</div>
 
 
<ul>
 
<ul>
 
         <li><b>Approvers</b> use the <b>Assurance evidence </b> screen to<br>
 
         <li><b>Approvers</b> use the <b>Assurance evidence </b> screen to<br>
 
             <ol>
 
             <ol>
 
                 <li>View relevant testing evidence alongside the risk, reducing the time assurance teams need to examine and approve releases</li>
 
                 <li>View relevant testing evidence alongside the risk, reducing the time assurance teams need to examine and approve releases</li>
−
                 <li>View how many of the tests have test results and whether it falls within risk tolerance levels</li>
+
                 <li>View verified development effort and whether it falls within risk tolerance levels</li>
−
                 [https://youtu.be/uXKp8ZhZ4mQ See how the tool streamlines the approval process with centrally stored testing evidence]
+
                 [https://youtu.be/oyKK3Mq13B4 See how the tool streamlines the approval process with centrally stored testing evidence]
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
+
== Risk management ==
 +
<b>Objective</b>: Enable risk managers to prioritise, plan and monitor mitigation efforts<br>
  
−
=== <li>Risk management</li> ===
 
−
 
−
 
−
<b>Objective</b>: Enable risk managers to prioritise, plan and monitor mitigation efforts<br>
 
−
</div>
 
 
     <ul>
 
     <ul>
 
         <li><b>Risk managers</b> use the <b>Application risk exposure</b> screen to<br>
 
         <li><b>Risk managers</b> use the <b>Application risk exposure</b> screen to<br>
Line 180: Line 140:
 
<br>
 
<br>
  
−
== <b>Preparation phase</b>==
+
<h1> <b>Preparation phase</b></h1>
 
When developing secure software we need to consider both standard secure code and client specific architectural requirements
 
When developing secure software we need to consider both standard secure code and client specific architectural requirements
  
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
+
== Standard secure code requirements==
−
=== <b>Standard secure code requirements</b>===
+
 
−
</div>
 
 
<ul>
 
<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>
 
         <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>
Line 198: Line 157:
 
       </li>
 
       </li>
 
  </ul>
 
  </ul>
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
  
−
=== <b>Client specific architectural requirements</b>===
+
== Client specific architectural requirements==
−
</div>
+
 
 
<ul>
 
<ul>
 
     <li>To generate these requirements we perform a risk assessment on client application landscape and identify</li>
 
     <li>To generate these requirements we perform a risk assessment on client application landscape and identify</li>
Line 223: Line 181:
 
<br>
 
<br>
  
−
== How does the SCAT implement first line of defence==
+
<h1>Project information</h1>
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
−
=== Promoting compliance to security requirements===
 
−
</div>
 
−
[[File:Internal mapping.png|thumb]]
 
−
<ul>
 
−
    <li>Understand the security requirement: The tool maintains the following internal mapping allowing organisations to translate complex security requirements into code level and testing guidance</li>
 
−
        <ol>
 
−
            <li>Risks mapped to technologies and secure code requirements</li>
 
−
            <li>Secure code requirements (OWASP ASVS) mapped to secure code building block</li>
 
−
            <li>Secure test plans (OWASP testing guide) mapped to risks</li>
 
−
            <li>The second mapping is lifted from [[OWASP_Security_Knowledge_Framework|OWASP secure knowledge framework]] and duplicated in the SCAT. I hope to link with the SKF and remove the duplicate functionality from the SCAT tool</li>
 
−
        </ol>
 
−
    <li>Verify understanding: The tool also makes use of OWASP ZAP basic scan to scan localhost for vulnerabilities, confirming the correct implementation of security requirements
 
−
</li>
 
−
</ul>
 
−
<br>
 
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
−
=== Minimising the impact of audit and assurance===
 
−
</div>
 
−
<ul>
 
−
<li>In the testing and approval phase SCAT allows testers to stores testing evidence against the critical application function and its associated risk.  Providing traceability through requirements and centrally storing and publishing test evidence</li>
 
−
</ul>
 
−
 
 
−
 
 
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
−
=== Informing risk based decision making===
 
−
</div>
 
−
<ul>
 
−
<li>For each application critical function, SCAT shows</li>
 
−
<ol>
 
−
<li>The risks that impact that application critical function</li>
 
−
<li>Security requirements and secure code block to protect against the risk</li>
 
−
<li>Test evidence proving risk has been mitigated to within tolerance</li>
 
−
</ol>
 
−
<li>Allowing risk teams see levels of exposure, easily compare it to tolerance levels.  And prioritise and coordinate mitigation activities across teams and the whole application landscape</li>
 
−
</ul>
 
−
<br>
 
−
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
−
 
 
−
=== Integrating security into the software development process===
 
−
</div>
 
−
[[File:Integrate security.png|thumb|Integrate security]]
 
−
<ul>
 
−
<li>SCAT wraps security theory, best practices and requirements into set of single purpose security screens. Then plots each of those screens to a specific software development phase</li>
 
−
<li>Plotting security screens to specific software development phases provides development teams with concise information when and how they need it</li>
 
−
</ul>
 
−
<br>
 
−
<br>
 
−
<br>
 
−
<br>
 
−
<br>
 
−
<br>
 
  
 
==Licensing==
 
==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.
 
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.
 +
 +
== Interested in contributing==
 +
[https://www.linkedin.com/in/michael-bergman-99826212a/ Please send a connect request with subject SCAT]
  
 
== Project Resources ==
 
== Project Resources ==
Line 287: Line 196:
  
 
== Project Leader ==
 
== Project Leader ==
−
[mailto://netblue4@googlemail.com Michael Bergman]
+
[https://www.linkedin.com/in/michael-bergman-99826212a/ Michael Bergman LinkedIn]
  
 
==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