As published in the November/December 2019 edition of InfoSecurity Professional Magazine
By Michael Bergman, CISSP
An (ISC)2 member details a software security integration system that eliminates that ’50-page security policy’ for developers.
Unless your organization is gifted with resources, your software development teams do not have a dedicated first-line-of-defense function that integrates controls and makes it easier for developers to secure the products they build.
Instead developers, particularly those using Agile for project management, typically are handed a 50-page security policy document and told to “implement that along with your functional requirements, all within your two-week sprint cycle.” The result is frustrated developers who usually do not understand cybersecurity well enough to extract security requirements from that massive policy document, let alone write code that correctly meets those requirements.
This lack of control integration, lack of understanding, and inconsistent or incorrect control implementation of security requirements is referred to as the security integration gap.
Symptoms of a security integration gap include:
- 50-page documents sitting idle on developers’ desks.
- Slowdown in project management.
- Developers openly frustrated by security requirements.
- Incorrectly implemented security controls.
Failing to narrow and eventually eliminate such a gap not only stifles software development, it puts an entire company at greater risk of legal challenges and market failures when products get released late and/or with exploitable vulnerabilities.
Standing on the sidelines, or throwing resources at the issue without a clear plan, is not the proper response to this common business problem. Instead, information security teams need a structured and repeatable way to integrate the security policy and strategic direction of the organization into the software development process and help developers implement it in their code.
An integrated software security system uses a host of resources including OWASP, COBIT and ISO to build a system of proven, effective and essential tools and technical and administrative controls that secure your software development.
What does the software security integration system do?
It vertically cuts through all three lines of defense. First, by decomposing security policy into a security control system. Second, by making sure controls are integrated. And finally, by providing code-level guidance ensuring controls are correctly implemented.
Three domains within SSD
There are three domains to consider when securing software development (SSD).
- Secure software development process.
- Secure code development.
- Continuous improvement.
To integrate security into these three SSD domains, organizations must determine their IT risk exposure and then wed security policy with the organization’s strategic direction in a way that promotes software development without killing its responsiveness to market.
No one-size-fits-all when building such a system
Each organization implements its software development process differently, using different development languages, technologies and methodologies. Information security teams cannot build a silver bullet system to secure all of these.
Instead, what information security can do is develop an integration system around the aforementioned three areas within the software development process. The following are suggestions for how this can be done for each of the three domains.
The secure software development process
This domain focuses on SSD governance, which consists of three separate elements:
- SSD internal control system.
- Planned compliance and assurance effort.
- Written procedures.
SSD internal control system
This element manages IT risk by clearly defining what the organization expects from software development in terms of security.
To create the SSD internal control system, we use internal security policies, COBIT and ISO 27002 to define the security controls required to secure our software development process.
Above is an example of what an SSD internal control system will look like and represents the security controls mapped to example software development phases.
Planned compliance and assurance
This element involves designing security controls into the software development process where compliance to the controls has the least impact on market responsiveness.
Written procedures
Here we guide the development teams toward compliance and list the tasks they must perform to comply to the security controls set in the SSD internal control system.
Software development methodologies focus on rapid response to market; therefore, it’s important that a software development process reflects this responsiveness requirement.
To help information security teams define a process sensitive to the importance of market responsiveness, I’ve documented a series of articles (https://bit.ly/2kxqddC) about building trust and maximizing value delivery of the Agile software development process.
Secure code development
Both standard secure code and architectural requirements need to be considered when developing secure software. These considerations need to be relevant and available early in the development process—as well as being consistently and correctly as implemented across all development teams.
Standard secure code requirements ensure code cannot be exploited, such as by SQL injection or directory transversal attacks. Architectural security requirements ensure the software can be securely deployed into the organization’s environment and list, for example, the approved authentication mechanism to use. This domain holds two components: secure coding and basic vulnerability detection. Both are wrapped in the secure code assurance tool, which is aimed at making sure security requirements are defined, understood and implemented correctly.
Secure code assurance tool (SCAT)
The secure code assurance tool is an OWASP piece of software written in MVC C# with a MySQL database.
What does the tool do?
The secure code assurance tool (SCAT) is used by in-house and third-party development teams to build, verify and assure secure software.
- Build: SCAT uses code-level guidance to clearly instruct developers on how to correctly implement security requirements.
- Verify: SCAT uses a combination of ZAP basic scans and security test plans to verify
- correct implementation of security requirements.
- Assure: SCAT centrally stores and publishes successful test results as an audit trail. It provides evidence, traceable through requirements, of a secure development process.
The basic vulnerability detection component is a free, open source application called OWASP ZAP. This tool is installed on the developer’s machine to perform basic vulnerability scans of the developer’s code on localhost before committing it to the source code repository. The idea behind the tool is to use “hacker tools” to give developers an insight into the world of a hacker.
Working together with SCAT, which generates secure code requirements, it helps requirements and helps developers understand and implement these.
OWASP ZAP performs basic vulnerability scans to verify the developer’s understanding and control implementation. The two tools build on each other to ensure a consistent and repeatable level of security.
OWASP ZAP allows the developer to enter into a fix-and-rescan loop to test the effect code-level changes have on fixing their own vulnerabilities. This loop will increase their level of awareness, improve their basic vulnerability detection and result in a better quality of code reaching peer reviewer after check-in.
Continuous improvement
Red teams use pen testing and other advanced detection capabilities to ensure our security controls protect against known vulnerabilities. The continuous improvement domain holds two components: SSD vulnerability management (VM) and security competence team.
This component uses advanced detection capabilities like pen tests, code reviews and environment configuration tools like Nessus to detect more complex vulnerabilities. This element, supported by VM procedure, will guide the proper processing of the advanced teams’ findings. Together, these two elements build on each other, ensuring all controls are updated to protect against known vulnerabilities.
The team is made up of an interdisciplinary group of security champions selected from the Agile software development teams. This team is the human glue that binds together all these components across all domains.
The team’s functions include:
- Receiving and processing pen test report findings.
- Answering secure code questions.
- Updating the secure building blocks library.
- Updating the secure test scripts library.
- Managing the automation of security tests.
These activities ensure that complex vulnerabilities are detected and correctly processed to update all security controls. This, in turn, ensures that once a vulnerability is found and processed it will not reoccur when a different developer makes the same mistake in the following sprint, or two-week plan of work.
Conclusion
This software security integration system relies on proven, effective and essential tools, along with technical and administrative controls required for secure software development.
The components build on each other to bridge the gap between strategic direction and operational-level software development teams. The functionality vertically cuts through all three lines of defense by first decomposing security policy into a security control system, then making sure controls are integrated and, finally, providing code-level guidance ensuring controls are correctly implemented.
When done properly and done well, the result should be more secure products both in development and in markets.
MICHAEL BERGMAN, CISSP, CCSP, CRISC, was born in Cape Town, South Africa, but has called a good few countries across a couple of continents home. He has a passionate interest in protecting and controlling software development activities, managing its IT risk and making security an inherent part of software development.
INFOGRAPHICS BY ROBERT PIZZO