Revision as of 04:14, 18 August 2019

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.

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.

The secure software development process: .......

Developing secure code: Helping the development team build secure software

Continuous improvement:..........

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

Secure software development has a number of stakeholders.

Each of these stakeholders contribute to developing secure code.

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

Development teams: Need to implement the technology, test it and record evidence proving the security requirements are met and

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

Compliance and Assurance: Need to review the testing evidence collected by the development teams and verify its consistency, traceability and quality

IT risk: Needs to manage and monitor risk mitigation efforts

Meeting these stakeholder requirements slow down the software development process.

Why is it so hard to meet these stakeholder requirements? and how does the Secure software assurance tool help?

Benefit: Centrally storing the security information will be a big once of effort that needs periodic review, but will speed up the requirements generation process make it consistent and repeatable. The more dev teams you have the bigger the benefit

Solution: A tool that maintains an internal mapping of which security requirements apply to which risks, technologies and application critical functions

Benefit: Creating this mapping is again a big once of effort that needs periodic review, but will result in a filtered list of security requirements, giving clear and consistent security guidance across the various technical environment components

Huge number of complex security requirements: Development teams do not understand the complicated security requirements, let alone know how to implement these in code and test them after. Also, the flexibility of development languages and different experience levels of developers almost guarantee that every dev team will implement the security requirement differently

Solution: A tool that stores a language specific and approved secure code building block against each security requirement, guiding the developers on how to implement the security requirement constantly

Benefit: Developing these secure code blocks will be a big once of effort that needs periodic review, but will help with the consistent implementation of security requirements across teams, technologies and critical application functions

Solution: A tool that stores a set of OWASP tests against each risk, guiding the testing team on how to correctly validate the security requirement has been met

Benefit: Developing scripts for these tests will be a big once of effort that needs periodic review, but will help with maintaining a consistent quality of risk testing across teams, technologies and critical application functions

Solution: A tool that allows developers to run an "on demand" OWASP ZAP basic scan on their code to verify they have correctly implemented the security requirements

Benefit: Immediate feedback loop

Solution: A tool that allows developers to open an "on demand" risk training sandbox environment. Allowing developers to learn how to exploit and defend against the risk

Benefit: On demand, hands on environment specific training

Lengthy and cumbersome approval process: Once development has been completed, the approvers need to wade their way through hundreds of automated test results looking for the results relevant to the the functional requirement. This is a lengthy process and blocks the release which almost nullifies the benefit of CI\CD

Benefit: Approvers can see at a glance whether or not the application critical function and its associated risks have been tested and mitigated according to risk tolerance. Speeding up the approval process and maximising the benefit of CI\CD efforts

Risk management of the application landscape: Risk managers have difficulty assessing the highest risk across the various technologies and and development languages in their environment. Therefore cannot prioritise their efforts and track mitigation efforts

Solution: A tool that provides a dashboard view of applications, the associated critical functions and the risks exposed by those critical functions. Then shows the number of secure code block and tests to mitigate the risk of exploitation

Benefit: Risk managers can easily see which application critical function and which risk needs extra secure code blocks and testing effort. And see how that effort will impact the entire application landscape

The secure coding tool provides the functionality listed above. Helping stakeholders firstly define and include their security requirements and secondly helping them realise and monitor it. In summary the secure coding tool attempts to fill the shoes of a first line of defence for the secure software development process

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 Secure coding tool work?

It is a light weight piece of software designed to be accessed from the developers box

Guides the development team towards meeting stakeholder requirements

See below how the secure coding tool supports the development team through the software development phases

Secure software development procedure

Sprint planning phase

Developers use the Application risk screen

To identify the technologies used to implement this application critical function

The secure coding tools internal mapping will automatically list the security requirements associated with using this technology

Tool setup

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.

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

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

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

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

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

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.

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.