This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Security Integration System"

From OWASP
Jump to: navigation, search
(Promoting compliance to security requirements)
(Minimising the impact of audit and assurance)
Line 217: Line 217:
  
 
<br>
 
<br>
 
 
<div style="background-color:#F2F0F0; padding-left:5pt; padding-bottom:5pt">
 
=== Minimising the impact of audit and assurance===
 
</div>
 
<ul>
 
<li>In the testing and approval phase SCAT allows testers to stores testing evidence against the critical application function and its associated risk.  Providing traceability through requirements and centrally storing and publishing test evidence</li>
 
</ul>
 
  
  

Revision as of 08:43, 7 October 2019

OWASP Project Header.jpg

What is the Secure code assurance tool (SCAT)

What is the SCAT

  • SCAT is a process integrity tool, implementing a consistent, authorized and auditable software development process
  • SCAT is used by development teams to build, verify and assure secure software
    • Build: uses a combination of code level guidance, on demand training and DAST tools to train, guide and verify correct implementation
    • Verify: uses a combination of manual test plans and SATS tools to guide and verify correct implementation
    • Assure: centrally stores and publishes evidence of secure development and testing as an audit trail. Providing traceability through requirements and proving that security controls operate efficiently over a period of time
  • SCAT is not a point in time security verification tool for detecting vulnerabilities after development

Process integrity and point in time in the SDLC

Process integrity VS point in time without check

Without further complicating development environment

  • SCAT is a simple 5 screen MVC, C# web application with a small footprint that can be deployed without further complicating development environment
  • Integrates with Jira and runs ZAP and SonarQube in docker containers
  • SCAT is part of three domains to consider when securing software development. I've detailed the other domains in an article that will be published in the Nov/Dec issue of the ISC2 magazine, I will add a link here after publication.

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 to control and coordinate development and testing effort

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

Sprint planning phase

Objective: Ensures security requirements are understood

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

Development phase

Objective: Ensure correct implementation of security requirements

Secure code review phase

Objective: Ensure correct implementation of security requirements

Testing phase

Objective: Ensure valid security testing

Approval phase

Objective: Streamline the approval and audit process

Risk management

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

  • Risk managers use the Application risk exposure screen to
    1. View each application critical function and the associated risks
    2. Identify where mitigation effort is required by viewing which risks require security requirements
    3. Identify where development effort is required by viewing which security requirements need secure code blocks
    4. Identify where extra testing effort is required by viewing which risks require security test plans
    5.                See how the Application landscape overview screen informs risk based decision making
      



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

Standard secure code requirements

  • SCAT comes out the box with a standard OWASP secure code requirements map. This mapping need to be modified to the specific organisation requirements

  • Information security and development team use the Internal mapping screen to
    1. Map the security requirements to OWASP risks
    2. Map organisation approved secure code blocks to security requirements
    3. Map security test plans to OWASP risks
    4.                See how to setup the SCAT's internal mapping
      

Client specific architectural requirements

  • To generate these requirements we perform a risk assessment on client application landscape and identify
    1. Critical applications and functions
    2. Risk associated with each critical application function
    3. Architectural security requirements to secure each critical application functions
    4. Client specific secure code blocks to implement security requirements
    5. Secure test plans to verify risk has been mitigated


  • Tool administrators use the Internal mapping screen to
    1. Create json files of the organisation specific risks, security requirements, secure code blocks and tests
    2. Import these into the SCAT
    3.     See how to import organisations specific risks, security requirements, secure code blocks and tests
      



SCAT has the following governance objectives implemented by the following “first line of defense” functions

SCATGovObj.png

Benefits realisation: Enabling development teams to deliver at speed

  1. Promoting compliance to security requirements
  2. Minimising the impact of audit and assurance

Risk optimisation: Minimise the negative and maximise the positive consequences

  1. Informing risk based decision making

Resource optimisation: Predictable, repeatable and consistent level of security across all teams

  1. Integrating security into the software development process



Informing risk based decision making

  • For each application critical function, SCAT shows
    1. The risks that impact that application critical function
    2. Security requirements and secure code block to protect against the risk
    3. Test evidence proving risk has been mitigated to within tolerance
  • 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


Integrating security into the software development process

Integrate security
  • 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
  • Plotting security screens to specific software development phases provides development teams with concise information when and how they need it







Licensing

This program is free software: you can redistribute it and/or modify it under the terms of the link GNU Affero General Public License 3.0 as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

Project Resources

[Installation Package]

[Source Code]

Project Leader

Michael Bergman

Classifications

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