Introduction to DevSecOps Best Practices: Process (Part 2 of 3)
This is part two of a three-part series on DevSecOps best practices. Check out part 1 (people) here.
The word is sometimes spoken in hushed tones so as not to upset any engineers or developers: process.
Cue the groans, sighs and eye rolls.
But process doesn’t need to be a four letter word. It is a crucial enabler of the most challenging aspect of any DevSecOps transformation: your people.
As W. Edwards Deming (considered the grandfather of quality) once said: “A bad process will beat a good person every time.”
We strive to make sure that doesn’t happen. DevSecOps aims to align and implement common enterprise processes to facilitate cooperation and achieve more secure development processes.
Prior to implementing these processes, organizations would often respond too late and much too slowly to security issues. But when you step back, you realize that’s actually not surprising because, typically, processes are siloed within separate IT teams, which can lead to miscommunication, bottlenecks and, ultimately, delays. These bottlenecks and delays then increase your risk and will inevitably manifest as a lower bottom line.
DevSecOps, in contrast, makes it possible to create short, feedback-driven security loops that can quickly identify problems and react swiftly to them.
How does that work? Well, we compiled some useful excerpts of specific practices you can apply when designing the processes component of your transformation. These are taken from our broader whitepaper, Introduction to DevSecOps and Best Practices for Adoption.
Let’s get into it!
Integration of Processes
Integrating information security into agile development enables organizations to have a fully secure workstream through every single stage of the project development cycle.
In the agile world, the integration of security must start at the earliest possible stage, which in most cases is the ‘requirement definition’ stage. This methodology has been called ‘shifting security left’ and it strives to reduce the cost of implementing security.
Compliance
Implementing compliance doesn’t have to be a paper-based exercise. You can create metadata representing the compliance requirement and integrating it into your assets.
This can also be used by security policy automation by tagging assets that can implement the desired security architecture, for example, zoning. Imagine the ability to respond to a breach under the new GDPR rules in under 72 hours.
Version Control, Metadata, and Orchestration
Within an automated world, the only constant is change, and change needs to be both consistent and traceable. To track all changes, you must ensure that adequate and immutable versioning is in place.
To allow for quick recovery, every action needs a version, so that it can be managed in the same way that code is. Once turned into metadata, operations teams can efficiently track a change and measure it.
Orchestration software doesn’t only provide a repeatable way to deploy infrastructure, it also provides a huge amount of metadata regarding any task. This metadata can not only be used by the orchestration software itself, but as an authoritative source for integrated tooling. Once coupled with versioning, orchestration software becomes a powerful source of information for all operational teams.
Security Tooling in CI/CD
Security has fought against shadow IT for a while, although it created its own shadow IT by having separate tooling for security.
Wouldn’t it make more sense to let the operations teams run the security tooling as part of their pipeline?
If you take Vulnerability Management and hook it to your pipeline via APIs, you can then let the orchestration call them for every build. Security sets the requirements, then DevOps teams manage the frequency of scan occurrences according to the development practices.
Incident Management
Responding to security incidents should not be an improvised or non-scripted activity. Workflows and action plans should be created in advance to ensure the response to an incident is consistent, repeatable, and measurable.
In a DevSecOps world, proactive and preemptive threat hunting, as well as continuous detection and response to threats and vulnerabilities, means that there are fewer major incidents and more mitigations.
Red Teams, Blue Teams and Bug Bounties
The use of red teams, blue teams and bug bounties also mitigate against breaches. The purpose of red teams is to test the effectiveness of security programs. Blue teams defend against the red team’s attacks.
All companies should deploy a red team to hunt for threats as part of the DevSecOps methodology. Red teams are built from security team personnel and are usually virtual to facilitate their ad hoc nature. Instead of discussing what is wrong with an application, the red team demonstrates what is wrong and provides the solution.
All companies should have a clear process for security researchers to disclose vulnerabilities. Otherwise, many do not get reported for fear of legal repercussions. It is also important that this be a secure method of communication as some countries have laws that would still put the individual who disclosed the information at risk if the vulnerability is disclosed in a way that could be intercepted (e.g. by email). Publishing a PGP (Pretty Good Privacy) key along with the method of communication gives you the best hope of being informed of current vulnerabilities -- hopefully before they are exploited.
All companies should also, occasionally, implement bug bounty programs -- rewards given for finding and reporting a bug in a software product.
Agreed Upon and Repeatable
The aim of these processes is to create agreed upon and repeatable ways of working, which are clearly documented to ensure security transparency.
If these agreed ways of implementing security (sets of principles, playbooks, as defined above) are put in place, problems (faults, bugs, threats, etc.) can be automatically identified much sooner and responded to in an agile fashion.
Implementing proper processes in your organization is a big step in the DevSecOps transformation, but people and technology are incredibly important, as well. If you’d like to learn more about our vision for DevSecOps in the enterprise - across people, process and technology - check out our free guide: Introduction to DevSecOps & Best Practices for Adoption.
