Securing DevOps through evidence, analytics and proactivity
Thu 26 Sep 2019 | Benny Van de Sompele
Sweagle CTO Benny Van de Sompele describes three “stacks” that can help firms do DevOps securely
The shift towards cloud native architectures and micro services has accelerated the need to integrate security into DevOps environments.
I’ve seen first-hand how modern architectures have given agile DevOps teams a new and unparalleled velocity to create, release and deploy. But with that boost in speed comes the need to bolster processes and secure application estates.
The traditional handovers for software development are now obsolete. DevOps teams can do them autonomously and are encouraged to do so. Whilst that’s all well and good, as technical leaders we’re obliged to inspect our operations and introduce new methods to ensure pipelines remain secure. Modern checks and balances should automatically detect and reject forbidden changes before they are even applied.
The new age of DevOps
With our DevOps teams on overdrive, our processes are open to brand new risks. What would you do if malicious changes made their way into your production environments? As scary as it might seem, one of the biggest threats to DevOps today comes from within.
Security integration is vital to the secure running of every DevOps function. There are recent headlines to prove it, with several high-profile organisations admitting config data violations that have impacted their end users and reputations.
We need to integrate the right level of security, whilst safeguarding our pipelines and continuing to deliver better quality, error-free and secure applications. In order to make this transition more practical, I’ve developed three “stacks” which you can implement to integrate security into DevOps.
Stack 1: Evidence
Most of us will fall short of a robust, unmodifiable evidence repository that would stand up to an external audit. I’m talking about the automation and intelligent gathering of unalterable audit trails for config data changes throughout your application estate. Something I call an “evidence repository.”
Ask yourself if you can:
- Prove that you’re fully in control and know exactly how every application is running in any environment, any infrastructure, and at any point in time.
- Understand the config data state before and after a change. What was added, removed and changed.
- Tell where the changes came from, who applied them and for what reason.
- Apply RBAC for business and customer sensitive data.
- Review expected and actual configuration data so that appropriate action is taken when there are gaps or deviations.
- Provide a singular view on compliance regulations.
If you can’t, you need an automated platform to manage it for you.
If you want to integrate security into your DevOps, a full picture of all infrastructure, environments and application configuration is a must. Automation is the only way to do it without tripping over yourself. This “unparalleled velocity” can be sustained… but you’ll need a secure and automated way to control config data changes and compare them over time.
Stack 2: Analytics
Evidence doesn’t solve any problems on its own. We need to put that information to work and create value through analytics and automation. Imagine your team tells you there’s a problem with a particular application. You know that problem wasn’t there before. So, the first thing you need to find out is what’s changed.
You’ll want to know about those changes from all angles. First the application: Were there new or canary deployments, or any feature flags activated? Second, the environment: What new resources were provisioned and were any operations scaled up or down? Lastly, the infrastructure: Were there any load balancer, firewall or certificate changes?
Ask yourself: How long does it take you to gather that kind of information at the moment? When you apply that to multiple teams, applications and projects with numerous releases a day, it’s too costly and time consuming to troubleshoot manually.
However, an agnostic repository of config data with smart root cause analysis through automated analytics, can instantly tell you what’s changed and which config data settings are to blame. That involves zero effort on your part, especially if you bring machine learning algorithms into play.
Stack 3: Proactivity
If you’re seeking to integrate security into DevOps, the final stack is “proactivity.” Your ability to prevent the train from derailing. There a range of practices you need to employ.
First you must ensure you can catch anomalies in config data changes before they are applied, even when your DevOps teams are working with a high level of automation at breakneck speed.
Next, you must be able to automate validation changes in a way that doesn’t break any technical, functional or compliancy regulation.
Lastly, ask yourself if you can automatically stop a conflict or incomplete config data setting being introduced that would cause an application problem or downtime.
If you can proactively prevent config data anomalies through automated testing and validation, you can rest easy and enjoy increased release velocity. With a constant eye on all the changes – whether they are technical, functional or sensitive – you can have your cake and eat it. You’ll also improve release deployment predictability and allow your DevOps teams to get it right first time.
Security and automation are the way forward
The only way to integrate security into DevOps is to handle config data with the same agile methodologies and processes we use to handle source code. Config data needs to be consolidated into an agnostic repository with full change control. If you have a fully compiled view of how all the config data hangs together, with constant validation checks, then your DevOps future is boundless.
With the three stacks in place and a single source of config data, you can consider dynamic provisioning, release centric deployments and faster, error-free onboarding of new teams. That’s the future of truly integrated DevSecOps and something that’s completely within our reach.
- Image Credit: Sweagle
DevOps Thu 26 Sep 2019DevOps is not just an excuse for the firing of developers