Difference between revisions of "OWASP Security Integration System"

From OWASP
Jump to: navigation, search
(Why is producing secure software so hard and how does the Secure software assurance tool help?)
(What does SCAT do)
 
(249 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
 
| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
  
<span style="color:#ff0000">
+
==<b>Table of content</b> ==
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.
+
<ol>
</span>
+
<li>[https://www.owasp.org/index.php?title=OWASP_Security_Integration_System#What_is_the_Secure_code_assurance_tool What is the Secure code assurance tool]</li>
==Project About==
+
<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>
<span style="color:#ff0000">
+
<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>
{{Template:Project_About
+
<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>
  | project_name=Software Integration System
+
</ol>
  | leader_name1=Michael Bergman
 
  | leader_email1=netblue4@googlemail.com
 
}}
 
  
 +
==<b>What is the Secure code assurance tool</b> ==
 +
<ul>
 +
<li>Secure code assurance tool (SCAT) is a mechanism for implementing a secure software development process</li>
 +
<li>SCAT, guided by COBIT, identifies IT risk, assurance, InfoSec, business and developers as being stakeholders in the software development process</li>
 +
<li>SCAT is a developer tool that helps development teams meet these stakeholder requirements and generate an audit trail as evidence of a secure development process</li>
 +
===<b>What does SCAT do</b>===
 +
<li>SCAT is a process integrity tool delivering a consistent, authorised and auditable software development process, proving security controls operate efficiently over a period of time.  Preventing vulnerabilities from reaching or recurring in production</li>
  
==OWASP Tool Project Template==
+
===<b>What does SCAT not do</b>===
<span style="color:#ff0000">
+
<li>SCAT is <b><u>not</u></b> a point in time security verification tool for <b><u>detecting</u></b> vulnerabilities in production</li>
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.  
+
</ul>
</span>
+
 
 +
==<b>Description</b> ==
 +
 
 +
<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>
 +
=== Verify ===
 +
<ul>
 +
<li>SCAT uses a combination of ZAP basic scans and security test plans to verify correct implementation of security requirements</li>
 +
</ul>
 +
=== Assure ===
 +
<ul>
 +
<li>SCAT centrally stores and publishes test results. Providing traceability through requirements and assurance evidence of correct implementation</li>
 +
</ul>
  
  
<p>
+
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:0pt">
== <b>Introduction</b>==
+
SCAT has the following governance objectives implemented by the following “first line of defense” functions
There are 3 domains to consider when securing software development.
+
</div>
 +
[[File:SCATGovObj.png|thumb]]
 +
=== Benefits realisation: Enabling development teams to deliver at speed===
 
<ol>
 
<ol>
<li><b>The secure software development process</b>: .......</li>
+
<li>[https://www.owasp.org/index.php?title=OWASP_Security_Integration_System#Promoting_compliance_to_security_requirements Promoting compliance to security requirements]</li>
<li><b>Developing secure code</b>: Helping the development team build secure software</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>
<li><b>Continuous improvement</b>:..........</li>
 
 
</ol>
 
</ol>
 
+
=== Risk optimisation: Minimise the negative and maximise the positive consequences===
<br>
 
This OWASP project focuses on the Developing secure code domain and details the why and how behind the Secure software assurance tool.<br>
 
<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>
 
<br>
 
<br>
 
 
 
==<b>Why the Secure software assurance tool</b>==
 
 
 
=== Producing secure software requires the input of a number of teams===
 
 
<ol>
 
<ol>
<li><b>Information security</b>: Needs to understand the technology behind the functional requirement and its associated risks.  Then <b>generate a list of security requirements</b> to protect the technology against exploitation</li>
+
<li>[https://www.owasp.org/index.php?title=OWASP_Security_Integration_System#Informing_risk_based_decision_making Informing risk based decision making]</li>
<li><b>Development teams</b>: Need to <b>implement</b> the technology, <b>test it and record evidence</b> proving the security requirements are met and </li>
 
<li><b>Approvers</b>:  Need to review testing evidence against the organisations risk tolerance levels. Then <b>accept the risk associate with the functional requirement</b> by approving the release</li>
 
<li><b>Compliance and Assurance</b>: Need to review the testing evidence collected by the development teams and <b>verify its consistency, traceability and quality</b></li>
 
<li><b>IT risk</b>: Needs to <b>manage and monitor</b> risk mitigation efforts </li>
 
 
</ol>
 
</ol>
<br>
+
=== Resource optimisation: Predictable, repeatable and consistent level of security across all teams ===
 
 
=== <b>Why is producing secure software so hard and how does the Secure software assurance tool help?</b><br>===
 
 
<ol>
 
<ol>
<li><b>Complex environments</b>: Development, security, risk, compliance and assurance teams need to combine their GDPR, ISO, risk tolerances level, OWASP ASVS, security testing, JAVA and .Net knowledge, filter it, and generate security requirements for each critical application function.  The process of aligning the knowledge and efforts of these teams is time consuming and slows down the development process</li>
+
<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>  
How does the tool help<br>
 
    <ul>
 
        <li>Centrally stores security requirements and links these to the technologies used in the organisation environment.  Allowing developers to select the technology used to implement their functional requirement and automatically get a list of relevant security requirements</li>
 
        <li><i>Benefit</i>: Developers can generate the security requirements themselves, without waiting on the security, risk, compliance and assurance teams.  This will speed up the requirements generation process make it consistent and repeatable across all teams</li>
 
    </ul>
 
<li><b>Huge number of complex security requirements</b>: Development teams do not understand the complicated security requirements therefore cannot correctly implement or test them. Also, the flexibility of development languages almost guarantee that every developer will implement the security requirement differently</li>
 
How does the tool help<br>
 
    <ul>
 
        <li>Stores a language specific and approved secure code building block against each security requirement. These guide developers towards constantly implementing the security requirements</li>
 
        <li>Stores a set of OWASP tests against each risk. Guiding the testing team on how to correctly validate the security requirement has been met</li>
 
        <li>Allows developers to run an "on demand" OWASP ZAP basic scan on their code. Enabling an immediate feedback loop to verify they have correctly implemented the security requirements</li>
 
        <li>Allows developers to open an "on demand" risk training sandbox environment.  Training developers how to exploit and defend against the risk</li>
 
    </ul>
 
<li><b>Lengthy and cumbersome approval process</b>: Approvers need to review testing evidence to verify the risk has been mitigated to within tolerance. But finding the relevant testing evidence generated by testers or in CI\CD pipelines is a lengthy process that blocks the release</li>
 
How does the tool help<br>
 
    <ul>
 
        <li>Centrally stores testing evidence alongside the risk and application critical function.  Allowing approvers to quickly see if the critical application function has been tested and mitigated according to risk tolerance</li>
 
    </ul>
 
<li><b>Risk management of the application landscape</b>: Risk managers cannot</li>
 
    <ol>
 
        <li>see which security requirements do not have secure code blocks</il>
 
        <li>see which risks need test plans or have not been tested</li>
 
        <li>see how a single security test can be re-used to test a different application risk</li>
 
        <li>see where mitigation efforts will have the most impact</li>
 
    </ol>
 
How does the tool help<br>
 
    <ul>
 
        <li>Provides a dashboard view of application landscape giving risk managers the information they need to prioritise and manage risk efforts </li>
 
    </ul>
 
 
</ol>
 
</ol>
 
<br>
 
<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>
==Description==
+
<li>SCAT is part of three domains to consider when securing software development</li>
<span style="color:#ff0000">
+
<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>
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.
+
</ul>
</span>
+
<br>
 
 
 
 
 
<br>
 
<br>
  
== <b>How does the Secure software assurance tool help generate secure code </b>==
+
== <b>See how developers use SCAT</b>==
 +
See below how the Secure code assurance tool integrates security into software development phases
 
<ul>
 
<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>
 
+
<b>How</b><br>
 
+
<ol>
=== <li>Sprint planning phase</li> ===
+
    <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>Application risk</b> screen<br>
+
         <li><b>Developers</b> use the <b>Identify risks</b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To identify the technologies used to implement this application critical function</li>
+
                 <li>Select the application critical function they are developing/changing</li>
                 <li>The secure coding tools internal mapping will automatically list the security requirements associated with using this technology</li>
+
                <li>Identify the technologies they are using to develop/change the application critical function</li>
                 [https://youtu.be/WQVzthyGL4U Identify technologies associated with application critical function]
+
                 <li>The Secure code assurance tools uses its internal mapping to automatically generate the security requirements associated with using this technology</li>
 +
                 [https://youtu.be/WQVzthyGL4U 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>
 +
            <ol>
 +
                <li>Export security requirements for import into backlog management tools</li>
 +
            </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
 +
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
=== <li>Development phase</li> ===
 
=== <li>Development phase</li> ===
 +
 +
<b>Objective</b>: Consistent and correct implementation of security requirements across all teams<br>
 +
<b>How</b><br>
 +
<ol>
 +
    <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 <br>
+
         <li><b>Developers</b> use the <b>Secure development</b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To see and understand how to attach and prevent the risks associated with the critical function</li>
+
                 <li>View and understand how to attack and prevent the risks associated with the critical function</li>
                 <li>To do some basic exploitation train (example)</li>
+
                 <li>View the secure code requirements to protect against exploitation</li>
                  <li>To see the secure code requirements to protect against exploitation</li>
+
                <li>View the secure code block to implement the security requirement</li>
                  <li>To see the secure code block to guide developers to implement security requirement</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/Rp5Tr_vBxB0 Secure development]
 
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
   </ul>
 
   </ul>
 +
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
  
 
=== <li>Testing phase</li> ===
 
=== <li>Testing phase</li> ===
 +
 +
<b>Objective</b>: Guide the secure testing process<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<br>
+
         <li><b>Testers</b> use the <b>Secure testing</b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To see the OWASP test plans required to test the risk mitigation efforts</li>
+
                 <li>View the test plans required to test the risk</li>
                 <li>Associate an automated testing tool with the test plan.  The secure coding tool allows testers to bulk update test results form the testing tool</li>
+
                 <li>Attach testing result to the test plan as control assurance evidence proving the risk has been mitigated</li>
                <li>To attach testing result to the test as control assurance evidence proving the risk has been mitigated</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>
                 <li>The secure coding tool does not integrate with any testing tools other than OWASP ZAP.  Testing results are generated outside of the secure coding tool and manually stored</li>
+
                 [https://youtu.be/VixapzUB_ts See how the tool helps testers test risk mitigation efforts and store testing evidence]
                 [https://youtu.be/VixapzUB_ts Secure testing]
 
 
             </ol>
 
             </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
 +
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
=== <li>Approval phase</li> ===
 
=== <li>Approval phase</li> ===
 +
 +
<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<br>
+
         <li><b>Approvers</b> use the <b>Assurance evidence </b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To see relevant testing evidence alongside the risk, reducing 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>To see how many of the tests have test results</li>
+
                 <li>View how many of the tests have test results and whether it falls within risk tolerance levels</li>
                 [https://youtu.be/VixapzUB_ts Streamline the approval process]
+
                 [https://youtu.be/uXKp8ZhZ4mQ 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">
  
 
=== <li>Risk management</li> ===
 
=== <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<br>
+
         <li><b>Risk managers</b> use the <b>Application risk exposure</b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To see each application critical function and the associated risks</li>
+
                 <li>View each application critical function and the associated risks</li>
                 <li>To see the number of <b>security requirements </b>for each risk, and which of those requirements have secure code block.  Allowing risk team to define where mitigation effort it required and monitors the progress of mitigation efforts</li>
+
                 <li>Identify where mitigation effort is required by viewing which risks require security requirements</li>
                 <li>To see the number of <b>security tests</b> for each risk.  Allowing risk team to determine where extra testing effort is required and monitor test coverage and quality</li>
+
                <li>Identify where development effort is required by viewing which security requirements need secure code blocks</li>
                 [https://youtu.be/8pKxorPSq_M Overview of application landscape and test coverage]
+
                 <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>
 
             </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
 
== Tool setup==
 
<ul>
 
 
[[File:Internal mapping.png|thumb]]
 
<li>Tool setup<br>  The tool lists all application critical functions.  <br>
 
And for each critical function it maintains an internal mapping that details the technologies, risks, security requirements, secure code blocks and tests.  <br>
 
A basic mapping exists in the tool but needs to be customised for your environment.</li>
 
    <ol>
 
        <li><b>InfoSec, testing and development teams</b>: Use the tools OWASP data mapping screen to modify the internal mapping.  </li>
 
    </ol>
 
</ul>
 
 
<br>
 
<br>
 
<br>
 
<br>
  
 +
== <b>Preparation phase</b>==
 +
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">
 +
=== <b>Standard secure code requirements</b>===
 +
</div>
 +
<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>
 
<br>
<b>What does the Secure coding tool do?</b><br>
+
        <li><b>Information security and development team</b> use the <b>Internal mapping </b> screen to
The secure coding tool, goes beyond theory and procedure and attempts to implement a planned control integration effort.<br>
+
            <ol>
The Secure coding tool is written in MVC \ MySQL and consists of 5 screens each serving a specific stakeholder
+
                <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>
 +
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
  
[[File:OWASP data flow.png|thumb]]
+
=== <b>Client specific architectural requirements</b>===
 +
</div>
 +
<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>
 
<ol>
<li><b>Information security stakeholder</b>: Filters the security requirements according to the functional requirement:  Streamlining security requirements generation </li>
+
    <li>Create json files of the organisation specific risks, security requirements, secure code blocks and tests</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>Import these into the SCAT</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>
+
    [https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
<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>
 
</ol>
 +
</ul>
  
 +
<br>
 +
<br>
  
 +
== How does the SCAT implement first line of defence==
 +
<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>
  
  
<br>
+
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
<b>How does the secure coding tool do it?</b><br>
+
=== Informing risk based decision making===
The secure coding tool, goes beyond theory and procedure and attempts to implement a planned control integration effort.<br>
+
</div>
The Secure coding tool is written in MVC \ MySQL and consists of 5 screens each serving a specific stakeholder
+
<ul>
 +
<li>For each application critical function, SCAT shows</li>
 
<ol>
 
<ol>
<li><b>Information security stakeholder</b>: Filters the security requirements according to the functional requirement:  Streamlining security requirements generation </li>
+
<li>The risks that impact that application critical function</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>Security requirements and secure code block to protect against the risk</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>Test evidence proving risk has been mitigated to within tolerance</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>
 
</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>
 
<br>
For a more detailed look at the inner workings of the tool and a brief instructional video please take a look at my linkedIn article<br>
 
<b>[https://www.linkedin.com/pulse/secure-coding-tool-michael-bergman/ Secure coding tool]</b>
 
  
 
==Licensing==
 
==Licensing==
<span style="color:#ff0000">
+
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.
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>
 
 
 
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)}. 
 
 
 
==Roadmap==
 
<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
 
<strong>
 
* Internationalization Support
 
* Additional Unit Tests
 
* Automated Regression tests
 
</strong>
 
 
 
==Getting Involved==
 
<span style="color:#ff0000">
 
Involvement in the development and promotion of <strong>Tool Project Template</strong> 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:
 
 
 
| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
 
  
 
== Project Resources ==
 
== Project Resources ==
<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]
 
 
[https://github.com/SamanthaGroves Source Code]
 
 
[https://github.com/SamanthaGroves What's New (Revision History)]
 
 
[https://github.com/SamanthaGroves Documentation]
 
 
[https://github.com/SamanthaGroves Wiki Home Page]
 
 
[https://github.com/SamanthaGroves Issue Tracker]
 
  
[https://github.com/SamanthaGroves Slide Presentation]
+
[Installation Package]
  
[https://github.com/SamanthaGroves Video]
+
[Source Code]
  
 
== Project Leader ==
 
== Project Leader ==
<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://netblue4@googlemail.com Michael Bergman]
 
[mailto://netblue4@googlemail.com Michael Bergman]
 
== Related Projects ==
 
<span style="color:#ff0000">
 
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 03:39, 12 September 2019

OWASP Project Header.jpg

Table of content

  1. What is the Secure code assurance tool
  2. Description of the Secure code assurance tool (SCAT) and how it builds, verifies and assures secure software
  3. See how the SCAT single purpose screens integrate security into each of the SDLC phases
  4. How to import client specific risks, security requirements and tests

What is the Secure code assurance tool

  • Secure code assurance tool (SCAT) is a mechanism for implementing a secure software development process
  • SCAT, guided by COBIT, identifies IT risk, assurance, InfoSec, business and developers as being stakeholders in the software development process
  • SCAT is a developer tool that helps development teams meet these stakeholder requirements and generate an audit trail as evidence of a secure development process
  • What does SCAT do

  • SCAT is a process integrity tool delivering a consistent, authorised and auditable software development process, proving security controls operate efficiently over a period of time. Preventing vulnerabilities from reaching or recurring in production
  • What does SCAT not do

  • SCAT is not a point in time security verification tool for detecting vulnerabilities in production

Description

    SCAT is used by inhouse and third party development teams to build, verify and assure secure software

    Build

    • SCAT uses code level guidance to clearly instructs developers on how to correctly implement security requirements

    Verify

    • SCAT uses a combination of ZAP basic scans and security test plans to verify correct implementation of security requirements

    Assure

    • SCAT centrally stores and publishes test results. Providing traceability through requirements and assurance evidence of correct implementation


    SCAT has the following governance objectives implemented by the following “first line of defense” functions

    SCATGovObj.png

    Benefits realisation: Enabling development teams to deliver at speed

    1. Promoting compliance to security requirements
    2. Minimising the impact of audit and assurance

    Risk optimisation: Minimise the negative and maximise the positive consequences

    1. Informing risk based decision making

    Resource optimisation: Predictable, repeatable and consistent level of security across all teams

    1. Integrating security into the software development process


  • SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment
  • 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 how developers use SCAT

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

  • Sprint planning phase
  • Objective: Enabling developers to generate security requirements before development begins
    How

    1. Link security risk and requirements to specific technologies
    2. Developers select technologies and get the lit of associated risks and security requirements
    • Developers use the Identify risks screen to
      1. Select the application critical function they are developing/changing
      2. Identify the technologies they are using to develop/change the application critical function
      3. The Secure code assurance tools uses its internal mapping to automatically generate the security requirements associated with using this technology
      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. Export security requirements for import into backlog management tools

  • Development phase
  • Objective: Consistent and correct implementation of security requirements across all teams
    How

    1. Organisation approved secure code blocks for each security requirement
    2. ZAP basic vulnerability scan to verify understanding
    • Developers use the Secure development screen to
      1. View and understand how to attack and prevent the risks associated with the critical function
      2. View the secure code requirements to protect against exploitation
      3. View the secure code block to implement the security requirement
      4. After development run a ZAP basic scan to verify security requirements have been correctly implemented
      5.                 See how the tool helps developers understand security requirements and write secure code
        

  • Testing phase
  • Objective: Guide the secure testing process
    How

    1. Providing secure tests plans to test risk/li>
    2. Successful test results from organisational test suite is centrally stored against each risk
    • Testers use the Secure testing screen to
      1. View the test plans required to test the risk
      2. Attach testing result to the test plan as control assurance evidence proving the risk has been mitigated
      3. 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
      4.                See how the tool helps testers test risk mitigation efforts and store testing evidence
        

  • Approval phase
  • Objective: Streamline the approval and audit process
    How

    1. Providing traceability through requirements by centrally publishing the risk alongside its secure test plan and test results/li>
    2. Giving approvers and auditors all the information they require for their assessment

  • 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
        



    Preparation phase

    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
        



    How does the SCAT implement first line of defence

    Promoting compliance to security requirements

    Internal mapping.png
    • Understand the security requirement: The tool maintains the following internal mapping allowing organisations to translate complex security requirements into code level and testing guidance
      1. Risks mapped to technologies and secure code requirements
      2. Secure code requirements (OWASP ASVS) mapped to secure code building block
      3. Secure test plans (OWASP testing guide) mapped to risks
      4. The second mapping is lifted from 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
    • Verify understanding: The tool also makes use of OWASP ZAP basic scan to scan localhost for vulnerabilities, confirming the correct implementation of security requirements


    Minimising the impact of audit and assurance

    • 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


    Informing risk based decision making

    • For each application critical function, SCAT shows
      1. The risks that impact that application critical function
      2. Security requirements and secure code block to protect against the risk
      3. Test evidence proving risk has been mitigated to within tolerance
    • 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


    Integrating security into the software development process

    Integrate security
    • 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
    • Plotting security screens to specific software development phases provides development teams with concise information when and how they need it







    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.

    Project Resources

    [Installation Package]

    [Source Code]

    Project Leader

    Michael Bergman

    Classifications

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