VerSprite’s guide, Integrating Security into Code, introduced the high-level concepts behind Security as Code and how it can be integrated with your DevOps processes. If you are interested in a guide that as a starting point to understanding DevSecOps, you can download the guide here.
In this blog post we will take a deeper dive into exactly how to approach integrating security into your Software Development LifeCycle (SDLC). In addition, we will delve into one available resource that provides guidance on how to get started.
Integrating security into your SDLC will depend strongly on your organization, products covered, business risks, and compliance requirements. There is no one size that fits all, but there are specific fundamentals that all organizations that build applications can utilize and benefit from.
Let’s start by focusing on application security, which will steer us toward design and development end of the SDLC process. This kind of thinking is often referred to as “Shifting Your Security Program Left.”
At VerSprite, we have found that a large percentage of our clients already have security programs with their operations teams focused on system security. Therefore we are always having to configure firewalls, apply OS patches, install and maintain Intrusion Detection, etc.
The benefits of building application security in early in the SDLC not only include saving your organization time finding and fixing a defect, but also the expense of fixing any security defects found later in the SDLC.
Targeting application security and at the development level means we need to engage the Continuous Integration process and involve development teams.
Getting development teams to do something new can always be a challenge, but the benefits of building in application security into your security early in the SDLC is well worth the effort.
There are various OWASP Foundation projects which provide guidance and tooling to help incorporate security into a development and DevOps process.
More specifically, the OWASP Application Security Verification Standard (ASVS) provides a roadmap for incorporating security into several activities throughout your SDLC.
The current version of the Standard is 4.01 updated as of March 2019. The ASVS project has been running for over 10 years and is actively maintained. It is adjusted as needed as processes and technology changes.
The ASVS has two main goals, helping organizations develop and maintain secure applications and allowing security service and tool vendors to align their offerings.
To help better align guidance with business requirements the ASVS has three levels each with increasing security depth:
Level 1 – First step, automated, defend against vulnerabilities that are easy to discover and included in the OWASP Top 10 and similar list. Can verify with black box testing.
Level 2 – Most applications, defends against most of the risks facing software today.
Level 3 – High value, assurance and/or safe, e.g. military, health and safety, critical infrastructure, etc.
The scope of controls covered is broad and complete, so tailoring it for your organization and use cases will allow you to focus the guidance and prioritize based on impact.
• Detailed Security Architecture Guidance
• Secure coding checklist
• Guide for automated unit and integration tests
• Secure development training
• Driver for agile application security
• Framework for guiding procurement of secure software
We recommend that most organizations should start with level 1 and pursue the creation of a secure coding checklist and unit/integration test. The need to move to level 2 and 3 will be dictated later by business needs.
• V2: Authentication Verification Requirements
• V3: Session Management Verification Requirements
• V4: Access Control Verification Requirements
• V5: Validation, Sanitization and Encoding Verification Requirements
• V7: Error Handling and Logging Verification Requirements
• V8: Data Protection Verification Requirements
• V9: Communication Verification Requirements
• V12: File and Resources Verification Requirements
• V13: API and Web Service Verification Requirements
As of version 4.0 of the ASVS, all of the level 1 requirements covered by the various domains have matching Common Weakness Enumeration (CWEs).
For the V2: Authentication and V3: Session Management domains, each ASVS requirement has a matching NIST 800-63 requirement.
Although not specifically mapped for each requirement, the level 1 standard is intended to be a comprehensive superset of PCI DSS 3.2.1 Sections 6.5 for application design, coding, testing, secure code review, and penetration tests.
If you have PCI requirements, again the ASVS is a great starting point.
The ASVS is designed to be highly testable, with the sole exception of architectural and malicious code requirements.
It is often a struggle for development teams to create good security test cases from scratch as their mind set is around the functionality of the application and not on anything but the most obvious weaknesses and vulnerabilities.
By creating either unit or integration test for the ASVS control requirements and expanding those for relevant abuse cases for the application, the build becomes nearly self-verifying with every iteration.
There are several projects and publications available to help guide in your journey with Security as Code: