You’re doing DevSecOps, and that’s a good thing. But have you taken it to the next level yet? Are you doing DevSecOps 2.0?
DevSecOps: Don’t Leave Home Without It.
But before we go on, let’s take care of another point. We said that doing DevSecOps is a good thing, but that’s really an understatement. These days, DevSecOps is more than just a good thing—It’s a necessity. If your organization hasn’t implemented at least basic DevSecOps practices by now, it’s time to catch up, and do so very, very quickly.
At its core, DevSecOps is what naturally happens when you merge DevOps and SecOps. We say “naturally” because it reflects the basic nature of both DevOps and SecOps. As with all forms of DevOps, it is not siloed—The security elements of DevSecOps are built in at every stage of your continuous delivery pipeline. And like SecOps, it is strongly focused on security— not simply as an afterthought, but as an intrinsic part of your application and your delivery process.
Security the Old-Fashioned Way
Consider the traditional position of security in the software development cycle: design, code, test, integrate, analyze for vulnerabilities (near the end of the test-and-integrate phase), then eliminate or patch vulnerabilities and add security features to compensate for the vulnerabilities that can’t be eliminated without wholesale redesign.
In the days when most software ran on desktop systems or local networks with limited outside connectivity, and development proceeded at a more or less leisurely pace, the inefficiency and limited coverage of this kind of after-the-fact security was generally acceptable.
Basic DevSecOps
Needless to say, in a world where everything is online and continuous delivery is the norm, such a late-in-the-day approach to security doesn’t even meet the minimum requirements for practicality, let alone efficiency or adequate coverage. To a considerable degree, security in DevOps has to fit the basic requirements of DevSecOps if it’s going to be anything at all. Basic DevSecOps means building in security, starting with design, and addressing security concerns as an intrinsic part of coding, including security in all stages of testing, and of course, making security a top priority in deployment and operations. (If you’re not doing these things already, you need to formulate a basic DevSecOps plan ASAP.)
Beyond the Basic
If that is basic DevSecOps, what is DevSecOps 2.0?
The starting point (and it is only the starting point) for DevSecOps 2.0 is that point at which the culture of your DevOps team and the culture of your security team merge into a true DevSecOps culture. In order for this to happen, the DevOps team needs to understand security not only as a necessary part of the operating environment and as a set of modifications which must be made to the application code, but as a fundamental functional and performance requirement of the software itself.
At the same time, the Security team needs to develop a full appreciation of the application, the development and test environments, the deployment and monitoring tools, and the overall infrastructure as entities made up of code, rather than black (or white) boxes to be probed, tested, monitored, and evaluated. The world of DevOps and the world of security must become completely visible to each other.
Security As Design
What does this mean in practice?
Ultimately, it has the effect of shifting security left, into the design of the code itself (and not just as a set of high-level design requirements to be applied post-development). This shift typically plays out in a variety of ways along the full length of the continuous delivery chain. The key features of DevSecOps 2.0 include (but are hardly limited to):
Security as a Design Requirement
Shifting security into design at the code level means that fundamental security considerations need to be explicitly addressed as a part of the process of code design at all levels, from the overall application framework to individual programs and components, and down to the lowest functional units.
What kind of security considerations? Depending on the actual design level, they might include:
- What targets could be accessed or compromised by means of this code?
- What potential vulnerabilities could an attacker exploit?
- What resources does it require, and what are their vulnerabilities?
- Are these vulnerabilities addressed elsewhere, and if they are, should they also be addressed by the code in question?
These questions need to be a part of the design process for all elements of the application code, even if the code in question has no obvious connection with known targets or attack surfaces.
Target Identification During the Design Phase
If potential access to attack targets is a major consideration in secure code design, you need to identify the targets—and not surprisingly, you also need to know what those same targets are when you build security in at the testing, deployment, and infrastructure levels.
You can separate targets into two general (although often overlapping) groups:
Primary Targets
These are typically assets which are valuable to potential attackers in and of themselves (information which can be extracted and exploited outside of your application). This includes financial and medical records, trade secrets and other proprietary data, classified documents, personal user information—basically, any type of data that can be used to advantage by malicious parties if they gain access to it.
Secondary Targets
These are targets which provide access to other targets (either primary or secondary). They are of value within the scope of your application, but not outside of it; typically, they are potential vulnerabilities which ultimately can be used to gain access to primary targets.
Note that user ID and password lists fall into both categories—They can provide access to your application and, since many people reuse passwords, potentially to other applications. This means that as long as your software requires password logins, you should treat the password list as a high-value primary target, even if no other sensitive data is involved.
Build Security Into Test Design
In many ways, this is a basic part of DevSecOps 1.0, but it bears repeating: You should be testing for vulnerabilities at all stages of your continuous delivery chain, from code and unit testing all the way to the post-deployment phase. Vulnerability testing should be included in your standard test regime, along with functional and performance tests, not as a substitute for ongoing testing and monitoring by the security team, of course, but in addition to it.
Build Security In at the Infrastructure Level
DevSecOps is (as are most other elements of DevOps) a work in progress, and this is as true at the infrastructure level as it is throughout the continuous delivery process. In many ways, DevSecOps has always been about infrastructure—about integrating security tools into cloud-based infrastructure, and integrating cloud providers’ own security tools into development and deployment infrastructure.
The future of DevSecOps at the infrastructure level is likely to include more security built into infrastructure code (i.e., within containers and VMs), and perhaps more importantly, building full-dashboard security monitoring and analytics service integration in at the code design level, in effect shifting key infrastructure security features left into application code.
Ultimately, perhaps, DevSecOps 2.0 is simply the recognition (put into practice) that in a cloud-based software environment, security can no longer be separated from development and operations in any meaningful way.
Today, DevSecOps isn’t a choice. It’s a fact.
Relevant:
How DevSecOps Can Help Manage Meltdown and Spectre:
