|
|
(66 intermediate revisions by the same user not shown) |
Line 7: |
Line 7: |
| <h1><b>What is the SCAT</b></h1> | | <h1><b>What is the SCAT</b></h1> |
| | | |
− | ==What SCAT does not do ==
| + | [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] |
− | <ul>
| |
− | <li>SCAT is <strong><span style="text-decoration:underline;">not</span></strong> a point in time security verification tool for <strong><span style="text-decoration:underline;">detecting</span></strong> vulnerabilities after development</li>
| |
− | </ul>
| |
| | | |
− | ==What SCAT does do== | + | ==What is the SCAT== |
− | <ul>
| |
− | <li>SCAT is a process integrity tool which implements a consistent, authorized and auditable software development process</li>
| |
− | <li>SCAT’s primary objective is proving security controls operate efficiently over a period of time</li>
| |
− | </ul>
| |
| | | |
− | ==Process integrity tool vs point in time security verification tool==
| |
− | [[File:SOC tools Point in time.png|thumb|SOCTools]]
| |
| <ul> | | <ul> |
− | <li>Point in time security verification tools relate to SOC2 Type 1 and assesses the design of security processes at a specific point in time</li>
| |
− | <li>Process integrity tools relate to SOC2 Type 2 and assesses how effective those controls are over time</li>
| |
− | <li>Both types of tools are important and some applications have functionality that crosses the line</li>
| |
− | </ul>
| |
| | | |
| + | <li>SCAT is a <span style="text-decoration:underline;">process integrity tool</span>, implementing a consistent, authorized and auditable software development process |
| | | |
− | ==Tools and SDLC==
| + | <li>SCAT is used by development teams to build, verify and assure secure software |
− | | |
− | | |
− | | |
− | <table border="1px">
| |
− | <tr>
| |
− | <td>SDLC phase</td>
| |
− | <td>SCAT Process integrity tool</td>
| |
− | <td>Point in time security verification tool</td>
| |
− | </tr>
| |
− | <tr>
| |
− | <td>Sprint planning</td>
| |
− | <td><strong>Ensures security requirements are understood </strong>
| |
| <ul> | | <ul> |
− | <li>Security requirements are enriched with environment specific contextual information and guidance <span style="text-decoration:underline;">before development begins</span> </li> | + | |
| + | <li><strong>Build</strong>: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation |
| + | |
| + | <li><strong>Verify</strong>: uses a combination of manual test plans and SATS tools to guide and verify correct implementation |
| + | |
| + | <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> |
| + | </li> |
| </ul> | | </ul> |
− | </td>
| |
− | <td><strong>Relevant security requirements </strong>
| |
− | <ul>
| |
| | | |
− | <li>Automatic scans generate security requirements to fix existing vulnerabilities | + | <li>SCAT is <span style="text-decoration:underline;">not a point in time security verification tool </span>for detecting vulnerabilities after development</li> |
− | </li> | |
| </ul> | | </ul> |
− | </td>
| |
− | </tr>
| |
− | <tr>
| |
− | <td>Develop
| |
− | </td>
| |
− | <td><strong>Ensures correct implementation of security requirements</strong>
| |
− | <ul>
| |
| | | |
− | <li>Code level guidance and automatic DAST tool scans to verify correct implementation
| + | ==Process integrity and point in time tools: How they work in the SDLC== |
− | </li>
| + | |
− | </ul>
| + | [[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]] |
− | </td>
| |
− | <td>
| |
− | </td>
| |
− | </tr>
| |
− | <tr>
| |
− | <td>Secure code review
| |
− | </td>
| |
− | <td><strong>Ensures correct implementation of security requirements</strong>
| |
− | <ul>
| |
| | | |
− | <li>Manually review guidance and automatic SAST tool scans to verify manual review | + | <h1><b>Technical Description</b></h1> |
− | </li> | |
− | </ul> | |
− | </td>
| |
− | <td>
| |
− | </td>
| |
− | </tr>
| |
− | <tr>
| |
− | <td>Testing
| |
− | </td>
| |
− | <td><strong>Ensures valid security testing</strong>
| |
− | <ul>
| |
| | | |
− | <li>Secure test plans to guide correct implementation of security requirements
| + | ==Without further complicating development environment== |
− | </li>
| |
− | </ul>
| |
− | </td>
| |
− | <td>
| |
− | </td>
| |
− | </tr>
| |
− | <tr>
| |
− | <td>Approval
| |
− | </td>
| |
− | <td><strong>Streamline audit/approval process </strong>
| |
− | <ul>
| |
− | <li>Providing one click traceability through requirements as evidence of secure development and testing
| |
− | </li>
| |
− | </ul>
| |
− | </td>
| |
− | <td>
| |
− | </td>
| |
− | </tr>
| |
− | </table>
| |
| <ul> | | <ul> |
− | <li>Using only point in time vulnerability detection tools will teach developers to fix vulnerabilities through trial and error. But when experienced developers leave the team, new developers have to learn by making the same costly mistakes again</li>
| |
− | <li>Process integrity tools fix this problem by guiding and verifying correct implementation at each stage of the SDLC. Making security part of the process of building software and reducing the reliance on individuals</li>
| |
| | | |
| + | <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 |
| | | |
− | <h1><b>Description</b></h1>
| |
− |
| |
− | ==Build, Verify Assure==
| |
− | <ul>
| |
− | <li>SCAT is used by development teams to build, verify and assure secure software</li>
| |
− | <li><strong>Build</strong>: SCAT uses code level guidance to clearly instructs developers on how to correctly implement security requirements</li>
| |
− | <li><strong>Verify</strong>: SCAT uses a combination of ZAP basic scans and security test plans to verify correct implementation of security requirements</li>
| |
− | <li><strong>Assure</strong>: SCAT centrally stores and publishes evidence of secure development and testing as an audit trail. Providing traceability through requirements and proving a secure development process</li>
| |
− | </ul>
| |
− | <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>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> | | <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> |
− | </li>
| |
− | </ul>
| |
| | | |
− | <h1><b>Problems the tool address</b></h1>
| |
− | ==Low levels of compliance==
| |
− | <ul>
| |
− | <li> Development teams don’t have the time to study and understand the complex security requirements and don’t know how to write code or test code that implements it</li>
| |
− | </ul>
| |
| | | |
− | ==Compliance and assurance seen as blockers==
| |
− | <ul>
| |
− | <li>Approvers and assurance teams delay release while development teams do a post development, blind scramble for evidence to prove they have met security requirements</li>
| |
− | </ul>
| |
− | ==Duplication of effort and inconsistent implementation==
| |
− | <ul>
| |
− | <li>Complex application landscapes with multiple dev teams, application and technologies make it difficult to control and coordinate development and testing effort</li>
| |
− | </ul>
| |
| | | |
| <h1><b>See how developers use SCAT</b></h1> | | <h1><b>See how developers use SCAT</b></h1> |
Line 275: |
Line 181: |
| <br> | | <br> |
| | | |
− | <h1><b> Governance, first line of defence and SCAT</b></h1> | + | <h1>Project information</h1> |
− | | |
− | SCAT has the following governance objectives implemented by the following “first line of defense” functions
| |
| | | |
− | [[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>
| |
− |
| |
− |
| |
− | <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>
| |
− |
| |
− | <h1>Project information</h1>
| |
| ==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 361: |
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== |