This is the third of a new five-part series of articles developed by TAG Cyber in conjunction with Sicura to offer insights and guidance into modern DevOps security using automated and integrated support.
The decision to secure the DevOps process is usually driven by a combination of objectives. On the one hand, the organizational security team, usually led by a Chief Information Security Officer (CISO), will recognize the importance of addressing threats that can arise during software development and the associated rapid deployment cycle. Security requirements generally emerge from this team, often as broad policy statements.
On the other hand, the engineering team, often led by either a head of DevOps or by an IT operations manager with software responsibility, will also recognize the need for cybersecurity attention. These requirements, however, often diverge somewhat from those of the security team. DevOps teams tend to be more practical and focused on securing day-to-day tasks.
An additional pressure on DevOps security often emerges from the compliance teams, which can include regulatory goals if the organization exists in a regulated industry. These groups tend to focus on either checklists, frameworks, or compliance targets as their guide, and the resulting requirements can be somewhat rigid, requiring interpretation to adjust to the DevOps context.
In this brief article, we propose a set of reasonable DevOps security requirements that include focus on the needs of all three organizational groups. The goal is to offer these requirements as a base for DevOps teams to begin driving their process toward highly secured approaches that will satisfy security, IT operations, software process, organizational compliance, and regulatory audit requirements.
One challenge that has existed in the establishment of good DevOps security requirements is the granularity gulf that exists between engineers who want detailed, day-to-day specifics, and security leaders who want broad policy directives that will cover a range of different use-cases. Both perspectives are reasonable, and any requirements adopted by an enterprise team must account for both perspectives.
Our view here is that a pipeline model offers the best means for accounting for both detailed guidance for engineers and a high-level roadmap for security professionals. The familiar OWASP group, in our estimation, has done the best job addressing both interests and their work will serve as the basis for our proposals here. Their model for DevSecOps (the moniker established for DevOps plus security) is driven by the view shown in Figure 3-1 below.
Figure 3-1. DevSecOps Pipeline Model from OWASP
As should be evident from Figure 3-1, the DevOps pipeline for security involves an interleaved combination of scanning and testing activities – all leading toward the goal of optimizing both threat prevention and also compliance support. These pipeline tasks provide an excellent basis for creation of a requirements framework for DevOps security. The salient aspects of each requirement are briefly outlined below.
The task to scan DevOps repositories for evidence of secrets has emerged as one of the most important and powerful security controls in the modern software development process. Typical secrets found during this task include common passwords, recycled storage keys, API keys, and other forms of validation used in day-to-day DevOps activities.
Now that Software Bill of Materials (SBOM) has become regularly referenced in major documents (including the recent Biden Executive Order), Software Compositional Analysis (SCA) has become a more important method for software security engineers. The best SCA solutions tend to be well-integrated into DevOps processes versus existing as a stand-alone tool.
Perhaps the most mature aspect of software security is the familiar static process of reviewing software code for evidence of poor programming practice or sloppy design. The resulting Static Application Security Testing (SAST) control is now found in virtually all software development process designs – and it continues to provide excellent threat mitigation, usually finding obvious errors before they can become more subtle and nagging.
Development of Infrastructure as Code (IaC) methods is one of the more welcome advances in modern DevOps process design. The goal for IaC is to specify and manage data center, storage, and network infrastructure to support high scaling and repeatability of design. Errors in IaC are common, however, so just as software must be scanner for vulnerabilities, the task now exists to do the same for IaC.
The use of containers such as Docker and associated orchestration tools such as Kubernetes in DevOps is a step toward more modular, scalable, and segmented cloud design. As one would expect, the need arises to scan these containers for evidence of vulnerabilities, just as earlier generation system administrators did the same for applications hosted in conventional data center configurations.
SAST methods can be complemented by more run-time testing solutions, and this includes both Dynamic Application Security Testing (DAST) and Interactive Application Security Testing (IAST). The best security results emerge when static and dynamic runtime methods are integrated to find vulnerabilities. Leaving out dynamic tests increases the possibility that subtle runtime errors could remain in deployed code.
Modern applications operate in highly virtualized infrastructure that provides context, functions, support, and many other assets necessary for the software to run properly. As one would expect, this supporting infrastructure must also be scanned for evidence of exploitable vulnerabilities. This task might be performed in conjunction with a public cloud hosting provider such as Microsoft or Amazon.
A major final step in the process is to ensure that every administrative requirement is met for any compliances that are demanded for the software being deployed. This can include technical tasks such as generation of data, or it can include mundane activities such as providing documentation on how a given DevOps process and its artifacts match up against the requirements of a desired framework.
By Edward Amoroso, TAG Cyber CEO
About TAG Cyber
TAG Cyber is a trusted cyber security research analyst firm, providing unbiased industry insights and recommendations to security solution providers and Fortune 100 enterprises. Founded in 2016 by Dr. Edward Amoroso, former SVP/CSO of AT&T, the company bucks the trend of pay-for-play research by offering in-depth research, market analysis, consulting, and personalized content based on hundreds of engagements with clients and non-clients alike—all from a former practitioner perspective.
Copyright © 2022 TAG Cyber LLC. This report may not be reproduced, distributed, or shared without TAG Cyber’s written permission. The material in this report is comprised of the opinions of the TAG Cyber analysts and is not to be interpreted as consisting of factual assertions. All warranties regarding the correctness, usefulness, accuracy, or completeness of this report are disclaimed herein.
Next week we'll be back with Part 4 of the TAG Cyber Sicura series. Interested in learning how can Sicura can make your environment more secure and your DevOps team more efficient? Get in touch.
Ready to maintain secure and compliant infrastructure focused on cost, automation, and consistency?