Recently, we partnered with DevOps.com and Enterprise Management Associates to host a webinar called, “Continuous Compliance and DevSecOps in Times of GDPR, HIPAA and SOX.” As compliance and security requirements remain critical to DevOps success, the current reality is that security enforcement can have a negative impact on the release schedule - especially when there are variances among teams and processes along the DevOps pipeline. Torsten Volk , managing research director at Enterprise Management Associates (EMA), and Anders Wallgren , CTO at CloudBees, joined up to address the current state of DevSecOps, the current realities at most organizations, and challenges that need to be solved to ensure continuous compliance. They also discussed key metrics for security and DevOps success. Below are the key takeaways from their discussion
State of Security for DevOps
First, Volk and Wallgren addressed the importance of baking security into the DevOps Pipeline from the very beginning. They also identified several challenges that enterprises face with GDPR, HIPAA, and SOX. Wallgren started the conversation by pointing out the big technology challenge: “I think the only thing worse than the cost of keeping up with changes in technology is the cost of not keeping up with changes in technology. One of the things that we see on a regular basis is the fact that companies are unable to retire technologies...Every year or month or week, we're adding new technologies to the stack that we need to understand and manage and secure. That's difficult and expensive. There's absolutely no quibble with that.” Volk referenced recent EMA research to further explain these challenges for the enterprise: “We do a lot of research reports like that. They all come to the same conclusion: security and compliance is the number one pain point. It’s the number one thing that lets the guys who are in charge, the guys with the business responsibility, not sleep at night.” Wallgren added the importance of baking security in from the beginning: “Security, quality, performance - all of these things need to be baked in from the beginning. They need to be treated as features of the product, not afterthoughts, runtime or deployment trade-offs, or operational issues. Security certainly is an operational issue, and things need to be monitored on all of those things once they're in production. But you can't just add security on in the last week before you release the product.”
Current Realities
Volk and Wallgren also highlighted the current realities seen in enterprise IT. The challenges that often impact release schedules, such as the variances in DevOps and Agile methods, lead to security challenges. Further, the impact of differing cloud languages, DSL overkill, and Kubernetes also heavily impact the modernization of security. So, what needs to happen to overcome these current challenges? Volk sees these current realities that impact DevOps: “We still see a lot of variance in terms of how individual teams, even within the same organization, implement their DevOps pipeline.” The cloud plays a role in these variances, according to Volk: “What makes this situation even more interesting is that every cloud speaks their own language. To control that centrally - the configurations, the deployment processes, and how everything is set up - is even more difficult, especially when you see that almost half of enterprises are using all three hyperscale clouds. A lot of them have more than just one account. Often, we see dozens or maybe even hundreds of AWS or Azure accounts within the same organization, all set up slightly differently.” As the conversation shifted towards YAML and DSL overkill, Wallgren added his favorable view of DSL. However, he warned about the importance of understanding it: “You have to understand what you're doing. From a security perspective, if you're copy-pasting your way into things and not really understanding the content that you're modifying, why you're modifying it, and how then somebody else should modify it, you're going to have problems.” The construction of the pipeline and orchestration are also critically important to continuous compliance, according to Wallgren : “If you have a properly constructed software delivery pipeline, which is essentially your supply chain for your software, then doing updates for these kinds of things are far less disruptive than they are when everything is done ad-hoc and manually, because you have the ability to run everything through your entire pipeline with orchestration. You make sure that everything works before you flip the switch and do the deployment into staging and production in the higher environments.” Wallgren emphasized the importance of the software delivery pipeline’s flexibility: “It's as equally important to have security and quality built in as it is to have a flexible software delivery pipeline that allows you to very easily run new scans and tests and very quickly put those into place.”
The Keys to Successful Compliance
The requirements for a DevSecOps supply chain that supports continuous compliance can be successfully achieved through modeling and automation. Wallgren and Volk shed light on the important points for continuous compliance, including who is responsible and the key metrics for success. Wallgren highlighted the importance of taking responsibility for security and vulnerabilities: “In reality, developers, QA people, product managers, product owners, etc. are all responsible for the security of applications. Unless we take that seriously in all of our jobs, well then we see what happens.” Volk added that the key ingredients of compliance all boil down to one critical factor: “As an IT organization, never accept exceptions of the rules of governance, otherwise technology, operations, and development teams could create issues that impact the critical path to delivery and ultimately slow the creation of business value. Whenever you make an exception, you basically let people get away with cutting the corners to compliance, and then your audit dashboard means nothing - and that's a problem. So it's best to start small and build in checks and balances along the way.” "Abstraction is good for security," said Wallgren. "When security becomes the department of ‘No,’ is when everything is coupled together. We can’t make a decision independently; we all have to make decisions together before any of us can move forward - that's when we get mired in the depths, and that's why we don't upgrade or apply patches for years at a time. We can't move anything until we move everything . The layers of abstraction allow us to decouple pieces of the architecture, which is increasingly important for security. But it doesn't absolve anyone from running those things properly at each level of the abstraction.” Volk added that metrics can ultimately help lead to success: “We still see recurring security issues, and in different teams across the enterprise it’s always the same root cause. But, the root causes aren’t always addressed consistently across the enterprise. So picking some of those factors which hurt you right now and starting to institutionalize the measurement of these factors without any excuses, is a good starting point towards measuring the baseline and improvement against that baseline in the future.