OWASP Security Integration System



{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 * valign="top" style="border-right: 1px dotted ;padding-right:25px;" |

What is the Secure code assurance tool (SCAT)
What is the SCAT

What is the SCAT


SCAT is a process integrity tool, implementing a consistent, authorized and auditable software development process

SCAT is used by development teams to build, verify and assure secure software   Build : uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation  Verify : uses a combination of manual test plans and SATS tools to guide and verify correct implementation  Assure : centrally stores and publishes evidence of secure development and testing as an audit trail. Providing traceability through requirements and proving that security controls operate efficiently over a period of time  

SCAT is not a point in time security verification tool for detecting vulnerabilities after development 

Process integrity and point in time in the SDLC


Problems the tool address

Retaining security knowledge
  Developers come and go, experience developers leave with their security knowledge and experience leaving new developers to learn and make the same mistakes </ul>

Low levels of compliance
  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
 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>

Inconsistent implementation
 Complex application landscapes with multiple dev teams, application and technologies make it difficult to ensure all dev teams are using the correct and best fix.</li> </ul>

Technical Description

Without further complicating development environment


SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment

Integrates with Jira and runs ZAP and SonarQube in docker containers

SCAT is part of three domains to consider when securing software development. I've detailed the other domains in an article that will be published in the Nov/Dec issue of the ISC2 magazine, I will add a link here after publication.

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

Sprint planning phase
Objective: Ensures security requirements are understood

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

Development phase
Objective: Ensure correct implementation of security requirements <ul> <li>Developers use the Secure development screen to            <ol> <li>View and understand how to attack and prevent the risk</li> <li>View the secure code requirements</li> <li>View the secure code block to implement the security requirement</li> <li>Manage development effort in Jira</li> <li>After development run a ZAP basic scan to verify security requirements have been correctly implemented</li> See how the tool helps developers understand security requirements and write secure code </ol> </li> </ul>

Secure code review phase
Objective: Ensure correct implementation of security requirements

<ul> <li>Code reviewers use the Secure code review  screen to            <ol> <li>Guide manually secure code review</li> <li>After manual secure code review run a Sonarqube scan to verify security requirements have been correctly implemented</li> See how the tool verifies correct security requirements implementation </ol> </li> </ul>

Testing phase
Objective: Ensure valid security testing <ul> <li>Testers use the Secure testing screen to            <ol> <li>View the test plans required to test the risk</li> <li>Manage testing effort in Jira</li> See how the tool helps testers test risk mitigation efforts </ol> </li> </ul>

Approval phase
Objective: Streamline the approval and audit process

<ul> <li>Approvers use the Assurance evidence  screen to            <ol> <li>View relevant testing evidence alongside the risk, reducing the time assurance teams need to examine and approve releases</li> <li>View verified development effort and whether it falls within risk tolerance levels</li> See how the tool streamlines the approval process with centrally stored testing evidence </ol> </li> </ul>

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

<ul> <li>Risk managers use the Application risk exposure screen to            <ol> <li>View each application critical function and the associated risks</li> <li>Identify where mitigation effort is required by viewing which risks require security requirements</li> <li>Identify where development effort is required by viewing which security requirements need secure code blocks</li> <li>Identify where extra testing effort is required by viewing which risks require security test plans</li> See how the Application landscape overview screen informs risk based decision making </ol> </li> </ul>

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

Standard secure code requirements
<ul> <li>SCAT comes out the box with a standard OWASP secure code requirements map. This mapping need to be modified to the specific organisation requirements</li> <li>Information security and development team use the Internal mapping  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> See how to setup the SCAT's internal mapping </ol> </li> </ul>

Client specific architectural requirements
<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> <li>Tool administrators use the Internal mapping  screen to <ol> <li>Create json files of the organisation specific risks, security requirements, secure code blocks and tests</li> <li>Import these into the SCAT</li> See how to import organisations specific risks, security requirements, secure code blocks and tests </ol> </ul>

Project information

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

 * }