This is a summary of Judy Johnson’s talk “The Science of Compliance: Early Code to Secure Your Node”. Watch the entire presentation below.
We’re here to talk about the science of compliance. We’re going to answer several important questions and, by the end of the post, you’ll understand what compliance is. You’ll know why it matters, and how to achieve it.
Why Does DevOps Matter?We can sum up why DevOps matters in four basic points:
Under DevOps, teams work together toward the same goal. With the help of automation and documentation, we can improve the way team members communicate. That leads to consistent and repeatable processes. Those processes, in turn, make the whole organization more efficient.
DevSecOps is basically DevOps plus security. This is how RedHat defines it:
DevSecOps means thinking about application and infrastructure security from the start. It also means automating some security gates to keep the DevOps workflow from slowing down. […] However, effective DevOps security requires more than new tools—it builds on the cultural changes of DevOps to integrate the work of security teams sooner rather than later.
Here’s another quote by Gene Kim:
In high-performing organizations, everyone within the team shares a common goal- quality, availability, and security aren’t the responsibility of individual departments, but are a part of everyone’s job, every day.
In other words, DevSecOps is just making security a priority from the start and the responsibility of everyone.
Should the “Sec” part be needed in DevSecOps? Shouldn’t it be implicit?
As far as I’m concerned, we should just call it “DevOps.” DevOps is DevOps, it just means “we’re working together, toward the same goal.” If we were to add every essential or important activity that happens during the SDLC, we might as well call it “DevSecCodeTestRunDeployEtcOps” or something to that effect.
People often ask “what’s the difference between security and compliance?”
Security is trying to make sure your system isn’t vulnerable. Security is disprovable, but it’s not provable. What does that mean?
It means that while you can’t prove that a given information system is secure, you can disprove it. After all, that’s what invaders do when they break into a system.
Compliance, on the other hand, is both provable and disprovable. It’s a checklist or set of rules, and you can go through your tests in order to prove you are compliant.
Both security and compliance are attempts to minimize risk.
We’ve just seen how compliance is different from security. But why do we need it?
The short answer would be “consistency.” When you have several parties working towards the same goal, it’s hard to remain consistent across the board. Having checklists, guidelines or rules for everyone to follow helps with that.
Once you accomplish consistency in a process, a number of other benefits follow. Below is a list with some of the most important reasons why an organization needs compliance:
To ensure your systems are compliant, you must focus on all environments: development, testing, and production.
When it comes to the development environment, the best course of action is to eliminate some of the threats—such as ports or encryption—right away. What about testing? Here, we’re talking mainly about your testing framework and platform (CI). Here are the tips: make sure you test under varying conditions, don’t forget to test all components together and finally, bear in mind that that’s your last chance to catch issues before code goes live.
Last but not least, production. Even though your code is already live, you still have options, such as “ChaosMonkey”-like tools that randomly test for various issues, and things like canary deployments, which allow you to deploy to a small portion of the userbase, so you can easily roll back if something goes wrong.
When you’re adding compliance to testing, you also have several tools at your disposal:
But the most important thing is to use the tools you already have, in order to make your testing easy and worthwhile.
Finally, for correction, there are several tools at your disposal, such as Puppet, Salt, Ansible or Chef. Additionally, you can use any programming language you already know, as well as performing correction manually.
Before we part ways, here’s a quick summary of all we’ve just seen: