OWASP - User contributions [en]

OWASP Security Integration System

2019-10-14T18:33:42Z

MB netblue4: /* What is the Secure code assurance tool (SCAT) */

OWASP Security Integration System

2019-10-14T18:32:44Z

MB netblue4: /* Process integrity and point in time tools: How they work in the SDLC */

OWASP Security Integration System

2019-10-14T18:32:08Z

MB netblue4: /* Inconsistent implementation */

OWASP Security Integration System

2019-10-14T18:31:58Z

MB netblue4: /* Compliance and assurance blocks release */

OWASP Security Integration System

2019-10-14T18:31:48Z

MB netblue4: /* Developers don’t understand security */

OWASP Security Integration System

2019-10-14T18:31:41Z

MB netblue4: /* Organisations loose security knowledge */

OWASP Security Integration System

2019-10-14T18:29:55Z

MB netblue4: /* What is the SCAT */

OWASP Security Integration System

2019-10-10T08:05:59Z

MB netblue4: /* Interested in contributing */

OWASP Security Integration System

2019-10-10T08:04:50Z

MB netblue4: /* Project Leader */

OWASP Security Integration System

2019-10-10T07:57:37Z

MB netblue4: /* Licensing */

OWASP Security Integration System

2019-10-10T07:55:24Z

MB netblue4: /* Licensing */

OWASP Security Integration System

2019-10-10T07:55:07Z

MB netblue4: /* Interested in contributing */

OWASP Security Integration System

2019-10-10T07:53:17Z

MB netblue4: /* Interested in contributing */

OWASP Security Integration System

2019-10-10T07:51:04Z

MB netblue4: /* Project Leader */

OWASP Security Integration System

2019-10-10T05:26:47Z

MB netblue4: /* Process integrity and point in time in the SDLC */

OWASP Security Integration System

2019-10-07T09:03:29Z

MB netblue4: /* Compliance and assurance block release */

OWASP Security Integration System

2019-10-07T09:03:03Z

MB netblue4:

OWASP Security Integration System

2019-10-07T09:02:30Z

MB netblue4:

OWASP Security Integration System

2019-10-07T09:00:16Z

MB netblue4: /* Compliance and assurance seen as blockers */

OWASP Security Integration System

2019-10-07T08:59:10Z

MB netblue4: /* Low levels of compliance */

OWASP Security Integration System

2019-10-07T08:58:57Z

MB netblue4: /* Retaining security knowledge */

OWASP Security Integration System

2019-10-07T08:56:49Z

MB netblue4: /* Low levels of compliance */

OWASP Security Integration System

2019-10-07T08:54:06Z

MB netblue4: /* Duplication of effort and inconsistent implementation */

OWASP Security Integration System

2019-10-07T08:49:54Z

MB netblue4: /* Without further complicating development environment */

OWASP Security Integration System

2019-10-07T08:48:58Z

MB netblue4: /* Duplication of effort and inconsistent implementation */

OWASP Security Integration System

2019-10-07T08:48:44Z

MB netblue4: /* Without further complicating development environment */

OWASP Security Integration System

2019-10-07T08:48:28Z

MB netblue4: /* Duplication of effort and inconsistent implementation */

OWASP Security Integration System

2019-10-07T08:47:40Z

MB netblue4: /* Without further complicating development environment */

OWASP Security Integration System

2019-10-07T08:47:04Z

MB netblue4: /* Process integrity and point in time in the SDLC */

OWASP Security Integration System

2019-10-07T08:46:29Z

MB netblue4: /* Duplication of effort and inconsistent implementation */

OWASP Security Integration System

2019-10-07T08:46:11Z

MB netblue4: /* Without further complicating development environment */

OWASP Security Integration System

2019-10-07T08:45:31Z

MB netblue4: /* Client specific architectural requirements */

OWASP Security Integration System

2019-10-07T08:44:51Z

MB netblue4: /* Resource optimisation: Predictable, repeatable and consistent level of security across all teams */

OWASP Security Integration System

2019-10-07T08:44:41Z

MB netblue4: /* Benefits realisation: Enabling development teams to deliver at speed */

OWASP Security Integration System

2019-10-07T08:44:27Z

MB netblue4: /* Risk optimisation: Minimise the negative and maximise the positive consequences */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==Process integrity and point in time in the SDLC==

[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]

<h1>Technical Description</h1>



==Without further complicating development environment==
<ul>

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

<li>Integrates with Jira and runs ZAP and SonarQube in docker containers

<li>SCAT is part of three domains to consider when securing software development. 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.

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>
=== 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>

 

<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">

<h1>Project information</h1>

==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:44:15Z

MB netblue4: /* Integrating security into the software development process */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==Process integrity and point in time in the SDLC==

[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]

<h1>Technical Description</h1>



==Without further complicating development environment==
<ul>

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

<li>Integrates with Jira and runs ZAP and SonarQube in docker containers

<li>SCAT is part of three domains to consider when securing software development. 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.

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">

<h1>Project information</h1>

==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:44:02Z

MB netblue4: /* Informing risk based decision making */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==Process integrity and point in time in the SDLC==

[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]

<h1>Technical Description</h1>



==Without further complicating development environment==
<ul>

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

<li>Integrates with Jira and runs ZAP and SonarQube in docker containers

<li>SCAT is part of three domains to consider when securing software development. 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.

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:43:50Z

MB netblue4: /* Minimising the impact of audit and assurance */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==Process integrity and point in time in the SDLC==

[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]

<h1>Technical Description</h1>



==Without further complicating development environment==
<ul>

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

<li>Integrates with Jira and runs ZAP and SonarQube in docker containers

<li>SCAT is part of three domains to consider when securing software development. 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.

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:43:24Z

MB netblue4: /* Promoting compliance to security requirements */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==Process integrity and point in time in the SDLC==

[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]

<h1>Technical Description</h1>



==Without further complicating development environment==
<ul>

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

<li>Integrates with Jira and runs ZAP and SonarQube in docker containers

<li>SCAT is part of three domains to consider when securing software development. 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.

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:38:51Z

MB netblue4: /* Point in time security verification */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==Process integrity and point in time in the SDLC==

[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]

<h1>Technical Description</h1>



==Without further complicating development environment==
<ul>

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

<li>Integrates with Jira and runs ZAP and SonarQube in docker containers

<li>SCAT is part of three domains to consider when securing software development. 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.

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:38:29Z

MB netblue4: /* Process integrity and point in time in the SDLC */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==Process integrity and point in time in the SDLC==

[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]

<h1>Technical Description</h1>



==Without further complicating development environment==
<ul>

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

<li>Integrates with Jira and runs ZAP and SonarQube in docker containers

<li>SCAT is part of three domains to consider when securing software development. 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.

==Point in time security verification==


Answers the question: How many vulnerabilities do we have in production at this moment in time?


Point in time tools

<ul>

<li>Very good at periodically checking if vulnerabilities have been fixed with a low upfront setup cost

<li>Clearly instructs as to what needs to be fixed, but gives little guidance on how to fix vulnerabilities

<li>Without guidance and only periodic checking, dev teams learn to fix vulnerabilities through trial and error and rely on individual knowledge and experience

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:38:09Z

MB netblue4: /* Process integrity */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==Process integrity and point in time in the SDLC==

[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]

<h1>Process integrity VS point in time</h1>



==Without further complicating development environment==
<ul>

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

<li>Integrates with Jira and runs ZAP and SonarQube in docker containers

<li>SCAT is part of three domains to consider when securing software development. 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.

==Point in time security verification==


Answers the question: How many vulnerabilities do we have in production at this moment in time?


Point in time tools

<ul>

<li>Very good at periodically checking if vulnerabilities have been fixed with a low upfront setup cost

<li>Clearly instructs as to what needs to be fixed, but gives little guidance on how to fix vulnerabilities

<li>Without guidance and only periodic checking, dev teams learn to fix vulnerabilities through trial and error and rely on individual knowledge and experience

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:34:01Z

MB netblue4: /* Process integrity and point in time in the SDLC */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==Process integrity and point in time in the SDLC==

[[File:Process integrity VS point in time without check.png|800px|center|Process integrity VS point in time without check]]

<h1>Process integrity VS point in time</h1>



==Process integrity==


Answers the questions: When a vulnerability is detected

<ul>

<li>Do developers consistently uses and approved fixes?

<li>Do testers consistently write valid test?

<li>Can dev teams consistently produce evidence they have done it securely?
</li>
</ul>

Consistency is important: It means that when a vulnerability is detected it is fixed and will not reoccur in the next sprint or when a new developer joins the team. Only when consistency is in place can organisations begin improving and maturing the process


Process integrity tools 

<ul>

<li>Vulnerability fixes are translated into security controls and built into the process of developing software. These are verified and each phase and evidence collected proving they was implemented correctly

<li>What do we mean by “translated into security controls”?: Detected vulnerabilities are enriched with organisational specifice secure code blocks, trained, verified, evidence collected and monitored for compliance. Translating vulnerabilities into security controls has a higher upfront setup cost
</li>
</ul>

==Point in time security verification==


Answers the question: How many vulnerabilities do we have in production at this moment in time?


Point in time tools

<ul>

<li>Very good at periodically checking if vulnerabilities have been fixed with a low upfront setup cost

<li>Clearly instructs as to what needs to be fixed, but gives little guidance on how to fix vulnerabilities

<li>Without guidance and only periodic checking, dev teams learn to fix vulnerabilities through trial and error and rely on individual knowledge and experience

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

File:Process integrity VS point in time without check.png

2019-10-07T08:32:51Z

MB netblue4:

Process integrity VS point in time without check

OWASP Security Integration System

2019-10-07T08:29:16Z

MB netblue4: /* How the tools work in the SDLC */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==Process integrity and point in time in the SDLC==

[[File:Process integrity vs point in time.png|800px|center|Process integrity vs point in time]]

<h1>Process integrity VS point in time</h1>



==Process integrity==


Answers the questions: When a vulnerability is detected

<ul>

<li>Do developers consistently uses and approved fixes?

<li>Do testers consistently write valid test?

<li>Can dev teams consistently produce evidence they have done it securely?
</li>
</ul>

Consistency is important: It means that when a vulnerability is detected it is fixed and will not reoccur in the next sprint or when a new developer joins the team. Only when consistency is in place can organisations begin improving and maturing the process


Process integrity tools 

<ul>

<li>Vulnerability fixes are translated into security controls and built into the process of developing software. These are verified and each phase and evidence collected proving they was implemented correctly

<li>What do we mean by “translated into security controls”?: Detected vulnerabilities are enriched with organisational specifice secure code blocks, trained, verified, evidence collected and monitored for compliance. Translating vulnerabilities into security controls has a higher upfront setup cost
</li>
</ul>

==Point in time security verification==


Answers the question: How many vulnerabilities do we have in production at this moment in time?


Point in time tools

<ul>

<li>Very good at periodically checking if vulnerabilities have been fixed with a low upfront setup cost

<li>Clearly instructs as to what needs to be fixed, but gives little guidance on how to fix vulnerabilities

<li>Without guidance and only periodic checking, dev teams learn to fix vulnerabilities through trial and error and rely on individual knowledge and experience

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:27:56Z

MB netblue4: /* How the tools work in the SDLC */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==How the tools work in the SDLC==

[[File:Process integrity vs point in time.png|800px|center|Process integrity vs point in time]]

<h1>Process integrity VS point in time</h1>



==Process integrity==


Answers the questions: When a vulnerability is detected

<ul>

<li>Do developers consistently uses and approved fixes?

<li>Do testers consistently write valid test?

<li>Can dev teams consistently produce evidence they have done it securely?
</li>
</ul>

Consistency is important: It means that when a vulnerability is detected it is fixed and will not reoccur in the next sprint or when a new developer joins the team. Only when consistency is in place can organisations begin improving and maturing the process


Process integrity tools 

<ul>

<li>Vulnerability fixes are translated into security controls and built into the process of developing software. These are verified and each phase and evidence collected proving they was implemented correctly

<li>What do we mean by “translated into security controls”?: Detected vulnerabilities are enriched with organisational specifice secure code blocks, trained, verified, evidence collected and monitored for compliance. Translating vulnerabilities into security controls has a higher upfront setup cost
</li>
</ul>

==Point in time security verification==


Answers the question: How many vulnerabilities do we have in production at this moment in time?


Point in time tools

<ul>

<li>Very good at periodically checking if vulnerabilities have been fixed with a low upfront setup cost

<li>Clearly instructs as to what needs to be fixed, but gives little guidance on how to fix vulnerabilities

<li>Without guidance and only periodic checking, dev teams learn to fix vulnerabilities through trial and error and rely on individual knowledge and experience

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:25:19Z

MB netblue4: /* What is the SCAT */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

==How the tools work in the SDLC==

[[File:Process integrity vs point in time.png|frame|center|Process integrity vs point in time]]

<h1>Process integrity VS point in time</h1>



==Process integrity==


Answers the questions: When a vulnerability is detected

<ul>

<li>Do developers consistently uses and approved fixes?

<li>Do testers consistently write valid test?

<li>Can dev teams consistently produce evidence they have done it securely?
</li>
</ul>

Consistency is important: It means that when a vulnerability is detected it is fixed and will not reoccur in the next sprint or when a new developer joins the team. Only when consistency is in place can organisations begin improving and maturing the process


Process integrity tools 

<ul>

<li>Vulnerability fixes are translated into security controls and built into the process of developing software. These are verified and each phase and evidence collected proving they was implemented correctly

<li>What do we mean by “translated into security controls”?: Detected vulnerabilities are enriched with organisational specifice secure code blocks, trained, verified, evidence collected and monitored for compliance. Translating vulnerabilities into security controls has a higher upfront setup cost
</li>
</ul>

==Point in time security verification==


Answers the question: How many vulnerabilities do we have in production at this moment in time?


Point in time tools

<ul>

<li>Very good at periodically checking if vulnerabilities have been fixed with a low upfront setup cost

<li>Clearly instructs as to what needs to be fixed, but gives little guidance on how to fix vulnerabilities

<li>Without guidance and only periodic checking, dev teams learn to fix vulnerabilities through trial and error and rely on individual knowledge and experience

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

File:Process integrity vs point in time.png

2019-10-07T08:24:44Z

MB netblue4:

Process integrity vs point in time

OWASP Security Integration System

2019-10-07T08:23:05Z

MB netblue4: /* What is the SCAT */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

<h1>Process integrity VS point in time</h1>


==Process integrity==


Answers the questions: When a vulnerability is detected

<ul>

<li>Do developers consistently uses and approved fixes?

<li>Do testers consistently write valid test?

<li>Can dev teams consistently produce evidence they have done it securely?
</li>
</ul>

Consistency is important: It means that when a vulnerability is detected it is fixed and will not reoccur in the next sprint or when a new developer joins the team. Only when consistency is in place can organisations begin improving and maturing the process


Process integrity tools 

<ul>

<li>Vulnerability fixes are translated into security controls and built into the process of developing software. These are verified and each phase and evidence collected proving they was implemented correctly

<li>What do we mean by “translated into security controls”?: Detected vulnerabilities are enriched with organisational specifice secure code blocks, trained, verified, evidence collected and monitored for compliance. Translating vulnerabilities into security controls has a higher upfront setup cost
</li>
</ul>

==Point in time security verification==


Answers the question: How many vulnerabilities do we have in production at this moment in time?


Point in time tools

<ul>

<li>Very good at periodically checking if vulnerabilities have been fixed with a low upfront setup cost

<li>Clearly instructs as to what needs to be fixed, but gives little guidance on how to fix vulnerabilities

<li>Without guidance and only periodic checking, dev teams learn to fix vulnerabilities through trial and error and rely on individual knowledge and experience

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]

OWASP Security Integration System

2019-10-07T08:17:26Z

MB netblue4: /* Process integrity VS point in time */

<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>

{| 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)==
<h1>What is the SCAT</h1>

==What is the SCAT==

<ul>

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

<li>SCAT is used by development teams to build, verify and assure secure software
<ul>

<li>Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation

<li>Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation

<li>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
</li>
</ul>

<li>SCAT is not a point in time security verification tool for detecting vulnerabilities after development</li>
</ul>

<h1>Process integrity VS point in time</h1>


Process integrity


Answers the questions: When a vulnerability is detected

<ul>

<li>Do developers consistently uses and approved fixes?

<li>Do testers consistently write valid test?

<li>Can dev teams consistently produce evidence they have done it securely?
</li>
</ul>

Consistency is important: It means that when a vulnerability is detected it is fixed and will not reoccur in the next sprint or when a new developer joins the team. Only when consistency is in place can organisations begin improving and maturing the process


Process integrity tools 

<ul>

<li>Vulnerability fixes are translated into security controls and built into the process of developing software. These are verified and each phase and evidence collected proving they was implemented correctly

<li>What do we mean by “translated into security controls”?: Detected vulnerabilities are enriched with organisational specifice secure code blocks, trained, verified, evidence collected and monitored for compliance. Translating vulnerabilities into security controls has a higher upfront setup cost
</li>
</ul>

Point in time security verification


Answers the question: How many vulnerabilities do we have in production at this moment in time?


Point in time tools

<ul>

<li>Very good at periodically checking if vulnerabilities have been fixed with a low upfront setup cost

<li>Clearly instructs as to what needs to be fixed, but gives little guidance on how to fix vulnerabilities

<li>Without guidance and only periodic checking, dev teams learn to fix vulnerabilities through trial and error and rely on individual knowledge and experience

<h1>Problems the tool address</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>See how developers use SCAT</h1>
See below how the Secure code assurance tool integrates security into software development phases

==Sprint planning phase ==
Objective: Ensures security requirements are understood 

<ul>
<li>Developers use the Identify risks screen to 
<ol>
<li>Select the critical function to developing/changing</li>
<li>Identify the technologies used</li>
<li>Automatically generate the security requirements and tests</li>
[https://youtu.be/Gpk4K5keLyw See how to use the tools and its internal mapping to generate security requirements]
</ol>
<li>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>
[https://youtu.be/1pSatE_7mEs 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>
[https://youtu.be/ygre0SrWxD4 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>
[https://youtu.be/QdbCzheceUw 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>
[https://youtu.be/oyKK3Mq13B4 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>
[https://youtu.be/8pKxorPSq_M See how the Application landscape overview screen informs risk based decision making]
</ol>
</li>
</ul>
 
 

<h1> Preparation phase</h1>
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>
[https://youtu.be/EkWdAC1sbkE 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>
[https://youtu.be/FD3O2ObYBQs See how to import organisations specific risks, security requirements, secure code blocks and tests]
</ol>
</ul>

 
 

<h1> Governance, first line of defence and SCAT</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>

 

<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>
 
<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>
 
<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>
 
 
 
 
 
 

<h1>Project information</h1>
==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.

== Project Resources ==

[Installation Package]

[Source Code]

== Project Leader ==
[mailto://netblue4@googlemail.com Michael Bergman]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects|Incubator Project]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[File:Agplv3-155x51.png|link=http://www.gnu.org/licenses/agpl-3.0.html|Affero General Public License 3.0]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]] [[Category:OWASP_Tool]]