Continuous Compliance and DevOps
Continuous Compliance and DevOps
To avoid being caught with your pants down by an auditor, consider implementing continuous compliance measures in your pipeline.
Join the DZone community and get the full member experience.Join For Free
Security, Compliance, and DevOps Walk Into a Pipeline...
Okay, I don't have a joke that starts out that way. But, then again, this isn't a joke — this is reality and something DevOps organizations need to embrace. Tools like InSpec help organizations fully automate testing, security, and compliance into Continuous Integration/Continuous Delivery pipelines.
Christoph Hartmann (@chri_hartmann) is a lead engineer at Chef and the creator of InSpec, an open source project at Chef to automate security and compliance as Infrastructure-as-Code. Christoph introduced the reasons for InSpec and what it can do at the 2017 AllDayDevOps conference in his talk, Continuous Patch and Security Assessment with InSpec.
Christoph's session is worth revisiting as we prepare for the next All Day DevOps conference.
Why Automate Compliance and Security?
Christoph answers the question many ask: "Why do I need to automate compliance and security?" Almost anyone in an organization subject to compliance has, at some point, run up against the Compliance Wall, halting progress. Compliance is important, but organizations need to build their infrastructure so that developers and operations partner with compliance and make the job easier for both the DevOps team and the compliance team. This ensures greater compliance, and, hopefully, greater security.
By fully automating compliance and security testing, developers can show — with an auditable record — that they have met the requirements. This makes it easier on the DevOps team, which makes it more likely they will comply. This makes for a healthier, more productive development because there is no need for developers to find ways around the system in order to do what they need to get done.
InSpec, in particular, focuses its efforts on two of the OWASP Top 10 Web Application Security Risks:
A5 — Security Misconfiguration
A9 — Using Known Vulnerable Components
These contribute and exacerbate to the vicious cycle we see in security: someone finds a loophole, exploits it, new regulations are implemented to stop it, and repeat. Minimizing them will go a long way towards being more secure.
How can you minimize them? Best practice hardening seems obvious, but it can be difficult to implement and it doesn't show auditors what they need to see. Automation brings clarity to your compliance and security implementations because it shows everything, exactly as it was done, and it helps ensure organizations that they are meeting compliance regulations to increase security and decrease liability.
Getting over the hurdle of agreeing to automate compliance is a big challenge, but we all know it doesn't stop there. Getting DevOps, Security, and Compliance to work together is another hurdle towards the finish line.
How can we bring DevOps, Security, and Compliance together to build compliance-drive infrastructure? Hint: Look at a trade-off of speed vs. risk.
Can We Do It Faster?
Christoph asks, "How can we accelerate speed but improve test coverage so that we grow in a good manner?" As he says: when you put a faster engine in your car, you better make sure you have better brakes.
What are solutions (the better brakes)?
You need something that does deep analysis. Christoph notes that most compliance activity tends to degrade over time and resume when auditors come by. Instead, it needs to be constantly checking and improving.
Christoph walks through specific InSpec examples, including some live demos, and looks at its capabilities, extendability, and outlook for integrations into more cloud environments in the near future. He highlights two resources for further study: inspec.io and dev-sec.io.
Watch Christoph's full talk below, including his live demos of InSpec.
Published at DZone with permission of Derek Weeks , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.