Difference between revisions of "OWASP Security Integration System"

From OWASP
Jump to: navigation, search
(Producing secure software requires the input of a number of teams)
(What does SCAT do)
 
(258 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>
 
 
 
==<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>
 
+
=== Resource optimisation: Predictable, repeatable and consistent level of security across all teams ===
<br>
 
<br>
 
 
 
=== <b>Why is producing secure software so hard and how does the Secure software assurance tool help?</b><br>===
 
 
<ol>
 
<ol>
<li><b>Huge body of security knowledge</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 apply it to critical application functions</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>  
    <ul>
 
        <li><i>Solution</i>: A tool that centrally stores environment relevant GDPR, ISO, risk tolerance level, OWASP ASVS, security testing, JAVA and .Net security requirements</li>
 
        <li><i>Benefit</i>: Centrally storing the security information will be a big once of effort that needs periodic review, but will speed up the requirements generation process make it consistent and repeatable. The more dev teams you have the bigger the benefit </li>
 
    </ul>
 
<li><b>Complex environments</b>: Most organisational IT environments consist of many moving parts, e.g. rapidly evolving development languages, cloud vs on premise. These require continuous security effort and strains already scares security resources</li>
 
    <ul>
 
        <li><i>Solution</i>: A tool that maintains an internal mapping of which security requirements apply to which risks, technologies and application critical functions</li>
 
        <li><i>Benefit</i>: Creating this mapping is again a big once of effort that needs periodic review, but will result in a filtered list of security requirements, giving clear and consistent security guidance across the various technical environment components</li>
 
    </ul>
 
<li><b>Huge number of complex security requirements</b>: Development teams do not understand the complicated security requirements, let alone know how to implement these in code and test them after.  Also, the flexibility of development languages and different experience levels of developers almost guarantee that every dev team will implement the security requirement differently</li>
 
    <ul>
 
        <li><i>Solution</i>: A tool that stores a language specific and approved secure code building block against each security requirement, guiding the developers on how to implement the security requirement constantly</li>
 
        <li><i>Benefit</i>: Developing these secure code blocks will be a big once of effort that needs periodic review, but will help with the consistent implementation of security requirements across teams, technologies and critical application functions</li>
 
        <li><i>Solution</i>: A tool that 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><i>Benefit</i>: Developing scripts for these tests will be a big once of effort that needs periodic review,  but will help with maintaining a consistent quality of risk testing across teams, technologies and critical application functions</li>
 
        <li><i>Solution</i>: A tool that allows developers to run an "on demand" OWASP ZAP basic scan on their code to verify they have correctly implemented the security requirements</li>
 
        <li><i>Benefit</i>: Immediate feedback loop</li>
 
        <li><i>Solution</i>: A tool that allows developers to open an "on demand" risk training sandbox environment.  Allowing developers to learn how to exploit and defend against the risk</li>
 
        <li><i>Benefit</i>: On demand, hands on environment specific training</li>
 
    </ul>
 
<li><b>Lengthy and cumbersome approval process</b>: Once development has been completed, the approvers need to wade their way through hundreds of automated test results looking for the results relevant to the the functional requirement.  This is a lengthy process and blocks the release which almost nullifies the benefit of CI\CD</li>
 
    <ul>
 
        <li><i>Solution</i>: A tool that centrally stores testing evidence alongside the risk and application critical function</li>
 
        <li><i>Benefit</i>: Approvers can see at a glance whether or not the application critical function and its associated risks have been tested and mitigated according to risk tolerance.  Speeding up the approval process and maximising the benefit of CI\CD efforts</li>
 
    </ul>
 
<li><b>Risk management of the application landscape</b>: Risk managers have difficulty assessing the highest risk across the various technologies and and development languages in their environment.  Therefore cannot prioritise their efforts and track mitigation efforts</li>
 
    <ul>
 
        <li><i>Solution</i>: A tool that provides a dashboard view of applications, the associated critical functions and the risks exposed by those critical functions.  Then shows the number of secure code block and tests to mitigate the risk of exploitation</li>
 
        <li><i>Benefit</i>: Risk managers can easily see which application critical function and which risk needs extra secure code blocks and testing effort.  And see how that effort will impact the entire application landscape</li>
 
    </ul>
 
 
</ol>
 
</ol>
 
<br>
 
<br>
<span style="color:blue">
+
<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>
<b>The secure coding tool provides the functionality listed above.  Helping stakeholders firstly define and include their security requirements and secondly helping them realise and monitor it.  In summary the secure coding tool attempts to fill the shoes of a first line of defence for the secure software development process</b>
+
<li>SCAT is part of three domains to consider when securing software development</li>
</span>
+
<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>
==Description==
+
<br>
<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>
 
 
 
 
 
 
<br>
 
<br>
  
== How does the Secure coding tool work?==
+
== <b>See how developers use SCAT</b>==
 +
See below how the Secure code assurance tool integrates security into software development phases
 
<ul>
 
<ul>
      <li>It is a light weight piece of software designed to be accessed from the developers box</li>
+
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
      <li>Guides the development team towards meeting stakeholder requirements<br>
+
=== <li>Sprint planning phase</li> ===
      <li>See below how the secure coding tool supports the development team through the software development phases<br>
 
    </ul>
 
  
== Secure software development procedure ==
+
<b>Objective</b>: Enabling developers to generate security requirements before development begins <br>
<ul>
+
<b>How</b><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>
=== <li>Sprint planning phase</li> ===
+
</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>Developers</b> use the <b>Application risk</b> screen<br>
+
         <li><b>Risk managers</b> use the <b>Application risk exposure</b> screen to<br>
 
             <ol>
 
             <ol>
                 <li>To see the number of security tests for each risk, and the percentage that have test results.  This allows risk team to determine where extra testing effort is required</li>
+
                 <li>View each application critical function and the associated risks</li>
                 <li>To see the number of security requirements for each risk, and which of those requirements have secure code block associated to guide developers towards correct implementation</li>
+
                <li>Identify where mitigation effort is required by viewing which risks require security requirements</li>
                 [https://youtu.be/8pKxorPSq_M Overview of application landscape and test coverage]
+
                 <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>
 
             </ol>
 
       </li>
 
       </li>
 
     </ul>
 
     </ul>
 +
<br>
 +
<br>
  
</ul>
+
== <b>Preparation phase</b>==
 +
When developing secure software we need to consider both standard secure code and client specific architectural requirements
  
== Tool setup==
+
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 +
=== <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>
[[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>
 +
        <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>
 +
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
  
 
+
=== <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>
 
<br>
<b>What does the Secure coding tool do?</b><br>
+
    <li><b>Tool administrators</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>
 
The Secure coding tool is written in MVC \ MySQL and consists of 5 screens each serving a specific stakeholder
 
 
 
[[File:OWASP data flow.png|thumb]]
 
 
<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]
+
[Installation Package]
  
[https://github.com/SamanthaGroves Source Code]
+
[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]
 
 
 
[https://github.com/SamanthaGroves Video]
 
  
 
== 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