OWASP Security Integration System



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

Instructions are in RED text and should be removed from your document by deleting the text with the span tags. This document is intended to serve as an example of what is required of an OWASP project wiki page. The text in red serves as instructions, while the text in black serves as an example. Text in black is expected to be replaced entirely with information specific to your OWASP project.

Who uses SCAT
 Information security, risk, assurance and compliance teams define strategic direction in security policies and requirements Software development teams need to implement strategic direction in code. But don't always have time to study and understand huge security policy documents or complex requirements SCAT is the integration layer between strategic direction and implementation and translates strategic security direction into code level and testing guidance  SCAT uses guidance, training, validation and integration to secure software and promote compliance, rather than costly post development policing 

Why: Problems the tool address
 Low levels of compliance: Development teams don’t have the time to study and understand the complex security requirements and don’t know how to write code or test code that implements it Compliance and assurance seen as blockers: Approvers and assurance teams delay release while development teams do a post development, blind scramble for evidence to prove they have met security requirements Duplication of effort and inconsistent implementation: Complex application landscapes with multiple dev teams, application and technologies make it difficult for risk managers to answer basic questions like “what is the highest priority risk across our application landscape” and effectively assign resources</li> </ul>

What: First line of defense for the software development process
 SCAT is a secure code assurance tool for both inhouse and third party development teams</li> SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment</li> SCAT is designed to be the “first line of defense” for the software development processes. And performs the following functions</li> <ol> Promoting compliance to security requirements</li> Integrating security into the software development process</li> Minimising the impact of audit and assurance</li> Informing risk based decision making</li> </ol> </ul>

Promoting compliance to security requirements
 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> Risks mapped to secure code requirements</li> Secure code requirements (OWASP ASVS) mapped to secure code building block</li> Secure test plans (OWASP testing guide) mapped to risks</li> </ol> The second mapping is lifted from SKF and duplicated in the SCAT. I hope to link with the SKF and remove the duplicate functionality from the SCAT tool</li> </ul>

Integrating security into the software development process
 <li>SCAT wraps security theory, best practices and requirements into set of single purpose security screens. Then maps those screens to a specific SDLC phase</li> <li>In the sprint planning phase SCAT implements “shift left” and uses its internal mapping to generate security requirements before development begins</li> <li>In the Development phase SCAT implements “best practices” that explain security requirements, guides to correctly implement and basic automatic security tooling to verify understanding and correct implementation</li> </ul>

Minimising the impact of audit and assurance
<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>

Informing risk based decision making
<ul> <li>For each application critical function, SCAT shows</li> <ol> <li>The risks that impact that application critical function</li> <li>Test plans to test that risk and how many test plans have test evidence</li> <li>Security requirements to protect against the risk</li> <li>How many security requirements have secure code blocks to guide implementation</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>

How to use the Secure code assurance tool
See below how the Security code assurance tool integrates security into the phases of software development <ul>

<li>Sprint planning phase</li>
<ul> <li>Developers use the Identify risks screen <ol> <li>To Select the application critical function they are developing/changing</li> <li>To identify the technologies they are using to develop/change the application critical function</li> <li>The Secure code assurance tools uses its internal mapping to automatically generate the security requirements associated with using this technology</li> See how to use the tools and its internal mapping to generate security requirements </ol> </li> </ul>

<li>Development phase</li>
<ul> <li>Developers use the Secure development screen <ol> <li>To see and understand how to attack and prevent the risks associated with the critical function</li> <li>To see the secure code requirements to protect against exploitation</li> <li>To see the secure code block to guide developers to implement security requirement</li> <li>After development run a ZAP basic scan to verify security requirements have been correctly implemented </li> See how the tool helps developers understand security requirements and write secure code </ol> </li> </ul>

<li>Testing phase</li>
<ul> <li>Testers use the Secure testing screen <ol> <li>To see the OWASP test plans required to test the risk mitigation efforts</li> <li>To attach testing result to the test plan as control assurance evidence proving the risk has been mitigated</li> <li>The Secure code assurance tool does not integrate with any testing tools other than OWASP ZAP. Testing results generated outside of the secure code assurance tool is manually uploaded and stored</li> See how the tool helps testers test risk mitigation efforts and strore testing evidence </ol> </li> </ul>

<li>Approval phase</li>
<ul> <li>Approvers use the Assurance evidence  screen <ol> <li>To see relevant testing evidence alongside the risk, reducing the time assurance teams need to examine and approve releases</li> <li>To see how many of the tests have test results</li> See how the tool streamlines the approval process with centrally stored testing evidence </ol> </li> </ul>

<li>Risk management</li>
<ul> <li>Risk managers use the Application risk exposure screen <ol> <li>To see each application critical function and the associated risks</li> <li>To see the number of security requirements for each risk, and which of those requirements have secure code block. Allowing risk team to define where mitigation effort is required and monitors the progress of mitigation efforts</li> <li>To see the number of security tests for each risk. Allowing risk team to determine where extra testing effort is required and monitor test coverage and quality</li> See how the Application landscape overview screen informs risk based decision making </ol> </li> </ul>

Tool setup
<ul> <li>Information security and development team use the OWASP data map  screen <ol> <li>To map the security requirements to OWASP risks</li> <li>To map organisation approved secure code blocks to security requirements</li> <li>To map security test plans to OWASP risks</li> [https://youtu.be/VixapzUB_ts See how to setup the tools internal mapping. This mapping will be used to integrate security into the SDLC] </ol> </li> </ul> <ul> <li>Information security and development team can also <ol> <li>Define new organisation specific risks and security requirements</li> <li>Link additional scanning tools</li> </ol> </li> </ul>

Security integration system
There are 3 domains to consider when securing software development. <ol> <li>The secure software development process: Involves securing the way an organisation develops software. So any development change dropped into the process comes out secure on the other end.</li> <li>Developing secure code: Helping the development team produce secure code. By supporting the development team at each phase of the software development process</li> <li>Continuous improvement:..........</li> </ol>

This OWASP project focuses on the Developing secure code domain and details the why and how behind the Secure code assurance tool. 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.

Description
This is where you need to add your more robust project description. A project description should outline the purpose of the project, how it is used, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, so project leaders should ensure that the description is meaningful.

For a more detailed look at the inner workings of the tool and a brief instructional video please take a look at my linkedIn article Secure coding tool

Licensing
A project must be licensed under a community friendly or open source license. For more information on OWASP recommended licenses, please see OWASP Licenses. While OWASP does not promote any particular license over another, the vast majority of projects have chosen a Creative Commons license variant for documentation projects, or a GNU General Public License variant for tools and code projects. This example assumes that you want to use the AGPL 3.0 license.

This program is free software: you can redistribute it and/or modify it under the terms of the link GNU Affero General Public License 3.0 as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. OWASP XXX and any contributions are Copyright &copy; by {the Project Leader(s) or OWASP} {Year(s)}.

Roadmap
As of November, 2013, the highest priorities for the next 6 months are:
 * Complete the first draft of the Tool Project Template
 * Get other people to review the Tool Project Template and provide feedback
 * Incorporate feedback into changes in the Tool Project Template
 * Finalize the Tool Project template and have it reviewed to be promoted from an Incubator Project to a Lab Project

Subsequent Releases will add
 * Internationalization Support
 * Additional Unit Tests
 * Automated Regression tests

Getting Involved
Involvement in the development and promotion of Tool Project Template is actively encouraged! You do not have to be a security expert or a programmer to contribute. Some of the ways you can help are as follows:


 * valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

Project Resources
This is where you can link to the key locations for project files, including setup programs, the source code repository, online documentation, a Wiki Home Page, threaded discussions about the project, and Issue Tracking system, etc.

Installation Package

Source Code

What's New (Revision History)

Documentation

Wiki Home Page

Issue Tracker

Slide Presentation

Video

Project Leader
A project leader is the individual who decides to lead the project throughout its lifecycle. The project leader is responsible for communicating the project’s progress to the OWASP Foundation, and he/she is ultimately responsible for the project’s deliverables. The project leader must provide OWASP with his/her real name and contact e-mail address for his/her project application to be accepted, as OWASP prides itself on the openness of its products, operations, and members.

Michael Bergman

Related Projects
This is where you can link to other OWASP Projects that are similar to yours.
 * OWASP_Code_Project_Template
 * OWASP_Documentation_Project_Template

Classifications

 * }