The Science of Compliance: Early Code to Secure Your Node

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.

We can sum up why DevOps matters in four basic points:

• Cooperation
• Communication
• Repeatability/Consistency
• Efficiency

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.

What Is DevSecOps?

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.

Is The “Sec” in DevSecOps Really Needed?

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.

What Is Compliance? How Does It Differ From Security?

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.

Why Do We Need Compliance?

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:

• Improve security
• Implement security concepts in a provable way
• Maintain Trust/Integrity
• Maintain Consistency (process management)
• Keep Control

Ensuring Your Systems Are Compliant

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.

Testing and Correction

When you’re adding compliance to testing, you also have several tools at your disposal:

• Acceptance tests – Beaker/VM/Container tests
• Chef’s Inspec
• Manual Testing
• Static code analysis tools

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.

Summary

Before we part ways, here’s a quick summary of all we’ve just seen:

• A secure OS on development and all other platforms allows you to start with an advantage.
• Compliance testing can—and should—be done at all stages of your CI process. Watch your test tool – there can be false positives as well as false negatives.
• A tool such as Puppet or Cron can run (or run scripts) at regular time increments to check your compliance, and alert you if something needs correction.
• Corrections can be done with an automated tool or manually.
• Ensure that security is integrated into your team and process