If you’re in IT, the pressure to deliver new products and features is a reality. But how then do you manage security and compliance when it comes to DevOps?
According to Symantec, a new Zero Day exploit was discovered every week in 2015, and nearly 75% of websites had unpatched vulnerabilities. In the modern world of DevOps, the idea of Acceptable Risk is being taken to new extremes, which often means sacrificing security for even a small amount of velocity.
It seems that compliance and velocity can only be at odds with each other. But is this true? Is it possible to achieve compliance without sacrificing velocity?
In this, and the following two articles I will share my approach on how this can be done.
An Intro to STIGs
Before explaining my approach to compliance at speed, I want to first set the stage with STIGs.
In government, compliance standards are documented in the form of a STIG (Security Technical Implementation Guides). STIGs contain all the rules and settings that IT systems should have in order to be considered secure by the Department of Defense’s standards.
Some say the STIGs are so impressive that they can secure entire systems through osmosis, but in reality the STIGs are a thorough set of systems-related criteria that cover anything from maintenance processes such as software updates and vulnerability patching to systems architecture such as the configurations of routers, firewalls, servers, and switches.
The Defense Information Systems Agency (DISA) maintains over 400 different STIGs. They cover the rules and settings for everything from Linux operating systems to Google’s Chrome browser. In addition to a large number of STIGs given your IT setup, individual STIGs can contain as many as nine different security levels, making implementing STIGs in your organization an overwhelming and daunting task.
Which brings me to the reality of the Information Assurance (IA) team. If you are in IA, what do you do? How can you maintain security given the rapid change in technology, the frequent updates of STIGs and the uniqueness of your organization?
I’m glad you asked. Let’s talk about loops.
OODA – Observe, Orient, Decide, Act.
Colonel John Boyd’s approach to combat operations favored agility over raw power. By observing and reacting to unfolding events more rapidly than your competitors you have gained a massive advantage. The same advantage with agility holds true when it comes to DevOps.
DevOps is said to use a continuous feedback loop, both to inform how the next iteration proceeds and as a litmus test for whether or not you are doing the “right” thing. If you’re an IA, you can achieve compliance at velocity by breaking your process down into a similar iterative structure.
In this and the next two articles, I will share with you a three loop approach to security and compliance that will enable your organization to gain the advantage over would be attackers. I call the loop IDV, which stands for Ingest, Develop, and Validate. Let’s start with Ingest.
The Ingest Loop
The Ingest loop is the first of three loops and it contains three processes. The purpose of the Ingest loop is to gather and process information such as STIGs so that you can create a compliance specification specifically for your organization. Here’s how it works.
Ingest is the process by which we obtain, import, and format data for use in a system. It is also the starting point of the first loop. The first loop deals with the answers to many important questions such as:
- What data should we consider and how often should we collect it?
- How do we determine what rules apply to us?
- How do we distribute our findings?
The DISA STIG’s are released quarterly and are hosted at the Information Systems Support Environment. Here, one can find STIG definitions and Security Content Automation Protocol (SCAP) data. Both STIG’s and SCAP data can be downloaded directly from the web in PDF or HTML format.
But what good are hundreds of rules if they may be at odds with our organization?
The second process in the loop is Triage. Triage is the process of determining the validity and importance of the STIG definitions. The Triage process involves going through each individual rule to determine whether or not it applies to your systems. You must also determine HOW it applies.
For example, rules requiring that the permissions on an application’s installation directory be set a certain way may work, unless your program needs to install that application into a non-standard directory. This is why it is vital to meet with the stakeholders in your program to ensure that you are adhering to the spirit of the rule. This is also the part where using pure SCAP data to enforce your standards falls apart. It has to be adapted to your organization.
What then, should you use to define compliance standards for your organization?
The last part of the Ingest Loop is the process of Specification. A specification is an act of describing or identifying something precisely, or of stating a precise requirement. For our purpose, Specification is the result of Ingesting STIG’s, Triaging the definitions within our program, and then producing a document that will be used as the source of truth for compliance.
In keeping with DevOps practices, this document will also function as executable code allowing us to scan for compliance – something I doubt we could accomplish with an Excel spreadsheet.
What is Chef Compliance? Well, that’s the topic for next time when we cover the Development Loop.