Difference between revisions of "OWASP Security Integration System"

From OWASP
Jump to: navigation, search
(Introduction)
(Why the Secure software assurance tool)
Line 36: Line 36:
 
<br>
 
<br>
  
==<b>Why the Secure software assurance tool</b>==
+
==<b>Why the Secure code assurance tool</b>==
  
 
=== Producing secure software requires the input of a number of teams===
 
=== Producing secure software requires the input of a number of teams===
Line 47: Line 47:
 
</ol>
 
</ol>
  
=== <b>Why is producing secure software so hard and how does the Secure software assurance tool help?</b><br>===
+
=== <b>Why is producing secure software so hard and how does the Secure code assurance tool help?</b><br>===
 
<ol>
 
<ol>
 
  <li><b>Complex environments</b>: Development, security, risk, compliance and assurance teams need to combine their GDPR, ISO, risk tolerances level, OWASP ASVS, security testing, JAVA and .Net knowledge, filter it, and generate security requirements for each critical application function.  The process of aligning the knowledge and efforts of these teams is time consuming and slows down the development process</li>
 
  <li><b>Complex environments</b>: Development, security, risk, compliance and assurance teams need to combine their GDPR, ISO, risk tolerances level, OWASP ASVS, security testing, JAVA and .Net knowledge, filter it, and generate security requirements for each critical application function.  The process of aligning the knowledge and efforts of these teams is time consuming and slows down the development process</li>
Line 63: Line 63:
 
         <li>Allows developers to open an "on demand" risk training sandbox environment.  Training developers how to exploit and defend against the risk</li>
 
         <li>Allows developers to open an "on demand" risk training sandbox environment.  Training developers how to exploit and defend against the risk</li>
 
     </ul>
 
     </ul>
  <li><b>Lengthy and cumbersome approval process</b>: Approvers need to review testing evidence to verify the risk has been mitigated to within tolerance. But finding the relevant testing evidence generated by testers or in CI\CD pipelines is a lengthy process that blocks the release</li>
+
  <li><b>Compliance</b>: Approvers review testing evidence to make sure development teams have complied to the ever increasing security and regulatory requirements. But finding the relevant testing evidence generated by testers or in CI\CD pipelines is a lengthy process that blocks the release</li>
 
How does the tool help<br>
 
How does the tool help<br>
 
     <ul>
 
     <ul>

Revision as of 06:14, 18 August 2019

OWASP Project Header.jpg

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.

Project About

PROJECT INFO
What does this OWASP project offer you?
RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: Secure code assurance tool (SCAT)
Purpose: N/A
License: N/A
who is working on this project?
Project Leader(s):
  • Michael Bergman @
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: N/A
Project Roadmap: Not Yet Created
Key Contacts
  • Contact Michael Bergman @ to contribute to this project
  • Contact Michael Bergman @ to review or sponsor this project
current release
Not Yet Published
last reviewed release
Not Yet Reviewed


other releases

OWASP Tool Project Template

This section should include an overview of what the project is, why the project was started, and what security issue is being addressed by the project deliverable.


Introduction

There are 3 domains to consider when securing software development.

  1. 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.
  2. Developing secure code: Helping the development team produce secure code. By supporting the development team at each phase of the software development process
  3. Continuous improvement:..........


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.

Why the Secure code assurance tool

Producing secure software requires the input of a number of teams

  1. Information security: Needs to understand the technology behind the functional requirement and its associated risks. Then generate a list of security requirements to protect the technology against exploitation
  2. Development teams: Need to implement the technology, test it and record evidence proving the security requirements are met and
  3. Approvers: Need to review testing evidence against the organisations risk tolerance levels. Then accept the risk associate with the functional requirement by approving the release
  4. Compliance and Assurance: Need to review the testing evidence collected by the development teams and verify its consistency, traceability and quality
  5. IT risk: Needs to manage and monitor risk mitigation efforts

Why is producing secure software so hard and how does the Secure code assurance tool help?

  1. Complex environments: Development, security, risk, compliance and assurance teams need to combine their GDPR, ISO, risk tolerances level, OWASP ASVS, security testing, JAVA and .Net knowledge, filter it, and generate security requirements for each critical application function. The process of aligning the knowledge and efforts of these teams is time consuming and slows down the development process
  2. How does the tool help

    • Centrally stores security requirements and links these to the technologies used in the organisation environment. Allowing developers to select the technology used to implement their functional requirement and automatically get a list of relevant security requirements
    • Benefit: Developers can generate the security requirements themselves, without waiting on the security, risk, compliance and assurance teams. This will speed up the requirements generation process make it consistent and repeatable across all teams
  3. Huge number of complex security requirements: Development teams do not understand the complicated security requirements therefore cannot correctly implement or test them. Also, the flexibility of development languages almost guarantee that every developer will implement the security requirement differently
  4. How does the tool help

    • Stores a language specific and approved secure code building block against each security requirement. These guide developers towards constantly implementing the security requirements
    • Stores a set of OWASP tests against each risk. Guiding the testing team on how to correctly validate the security requirement has been met
    • Allows developers to run an "on demand" OWASP ZAP basic scan on their code. Enabling an immediate feedback loop to verify they have correctly implemented the security requirements
    • Allows developers to open an "on demand" risk training sandbox environment. Training developers how to exploit and defend against the risk
  5. Compliance: Approvers review testing evidence to make sure development teams have complied to the ever increasing security and regulatory requirements. But finding the relevant testing evidence generated by testers or in CI\CD pipelines is a lengthy process that blocks the release
  6. How does the tool help

    • Centrally stores testing evidence alongside the risk and application critical function. Allowing approvers to quickly see if the critical application function has been tested and mitigated according to risk tolerance
  7. Risk management of the application landscape: Risk managers cannot
    1. see which security requirements do not have secure code blocks</il>
    2. see which risks need test plans or have not been tested
    3. see how a single security test can be re-used to test a different application risk
    4. see where mitigation efforts will have the most impact

    How does the tool help

    • Provides a dashboard view of application landscape giving risk managers the information they need to prioritise and manage risk efforts


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.



How does the Security assurance tool help generate secure code

See below how the Security assurance tool supports the phases of software development and contributes to producing secure software

  • Sprint planning phase
  • Development phase
    • Developers use the Secure development screen
      1. To see and understand how to attack and prevent the risks associated with the critical function
      2. To see the secure code requirements to protect against exploitation
      3. To see the secure code block to guide developers to implement security requirement
      4. After development run a ZAP basic scan to verify security requirements have been correctly implemented
      5.                 Secure development
        

  • Testing phase
    • Testers use the Secure testing screen
      1. To see the OWASP test plans required to test the risk mitigation efforts
      2. Associate an automated testing tool with the test plan. The secure coding tool allows testers to bulk update test results form the testing tool
      3. To attach testing result to the test as control assurance evidence proving the risk has been mitigated
      4. The secure coding tool does not integrate with any testing tools other than OWASP ZAP. Testing results are generated outside of the secure coding tool and manually stored
      5.                Secure testing
        

  • Approval phase
    • Approvers use the Assurance evidence screen
      1. To see relevant testing evidence alongside the risk, reducing time assurance teams need to examine and approve releases
      2. To see how many of the tests have test results
      3.                Streamline the approval process
        

  • Risk management
    • Risk managers use the Application risk exposure screen
      1. To see each application critical function and the associated risks
      2. 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 it required and monitors the progress of mitigation efforts
      3. 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
      4.                Overview of application landscape and test coverage
        

    Tool setup

      Internal mapping.png
    • Tool setup
      The tool lists all application critical functions.
      And for each critical function it maintains an internal mapping that details the technologies, risks, security requirements, secure code blocks and tests.
      A basic mapping exists in the tool but needs to be customised for your environment.
      1. InfoSec, testing and development teams: Use the tools OWASP data mapping screen to modify the internal mapping.





    What does the Secure coding tool do?
    The secure coding tool, goes beyond theory and procedure and attempts to implement a planned control integration effort.
    The Secure coding tool is written in MVC \ MySQL and consists of 5 screens each serving a specific stakeholder

    OWASP data flow.png
    1. Information security stakeholder: Filters the security requirements according to the functional requirement: Streamlining security requirements generation
    2. Dev team stakeholder: Provides secure code blocks to implement the security requirement: Providing code level guidance for developers towards correctly implementing security requirements
    3. Dev team stakeholder: Provides security test plans to testing the security requirements: Guiding testers towards correctly verifying security requirements are met
    4. Compliance and assurance stakeholder: Provides a central store for testing results: Promoting traceability through requirements and serving as a quick reference screen for assurance to view control assurance evidence, speeding up the approval process and minimising its impact on responsiveness to market
    5. IT risk stakeholder: Provides IT risk with an overview of each applications exposure to OWASP TOP 10 risks: Informing risk based decision making and prioritising




    How does the secure coding tool do it?
    The secure coding tool, goes beyond theory and procedure and attempts to implement a planned control integration effort.
    The Secure coding tool is written in MVC \ MySQL and consists of 5 screens each serving a specific stakeholder

    1. Information security stakeholder: Filters the security requirements according to the functional requirement: Streamlining security requirements generation
    2. Dev team stakeholder: Provides secure code blocks to implement the security requirement: Providing code level guidance for developers towards correctly implementing security requirements
    3. Dev team stakeholder: Provides security test plans to testing the security requirements: Guiding testers towards correctly verifying security requirements are met
    4. Compliance and assurance stakeholder: Provides a central store for testing results: Promoting traceability through requirements and serving as a quick reference screen for assurance to view control assurance evidence, speeding up the approval process and minimising its impact on responsiveness to market
    5. IT risk stakeholder: Provides IT risk with an overview of each applications exposure to OWASP TOP 10 risks: Informing risk based decision making and prioritising


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

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.

Classifications

Project Type Files TOOL.jpg
Incubator Project
Owasp-defenders-small.png
Affero General Public License 3.0