This week, the annual Puppet State of DevOps Report was released (download your copy here). This report aggregates data from thousands of DevOps leaders and practitioners to identify trends in software development, cloud, security, and more.
NOTE: Anitian is proud to sponsor the 2019 State of DevOps Report.
This year’s report focuses on the importance of security in the DevOps lifecycle. Which has been on our minds at Anitian for quite some time. Many of the insights and conclusions from this report align with Anitian’s experience.
While I do not want to restate the report’s conclusions, one of the report’s insights resonated with me. The report describes how organizations often get “stuck in the middle” with security and DevOps integration. Or in other words, when organizations begin integrating security into the DevOps lifecycle, they experience immediate improvements, yet as these efforts progress, they become more difficult and often stall out. The report shows that this is why many organizations never fully integrated security into the DevOps teams and practices.
We see this frequently among our customers. This issue becomes especially noticeable when an organization begins automating security configuration. Configuring security controls, especially nuanced ones like intrusion detection, requires a healthy set of both security expertise and automation expertise.
How do you break through the middle and fully integrate security and DevOps? This is something we work at regularly at Anitian. It is a key dimension of our Compliance Automation platform. There are many ways to break through this middle barrier. First, we need to explore this barrier a little more deeply.
Complementary in Concept, Contradictory in Execution
In information security, when you do your job correctly, nothing happens: the app does not get hacked, the identity is not stolen, or a breach does not cause the company to lose billions. In contrast, when DevOps does its job correctly, something happens: the app works, customers are served, billions are made.
While both teams are united under the goal of building and maintaining a stable, secure environment, they have different ways to achieve this end. DevOps and security are complementary in concept but contradictory in execution.
The clearest example of this divergence of execution is how each team approaches an automation task. DevOps elevates and enshrines trial and error to automate. Design an automation, sling together some basic code, try it out, and optimize the process as you go. Eventually, after many iterations, the configuration is automated. Once it works, mark it as complete in Jira and move on to the next item in the backlog.
Security abhors this kind of trial and error. Error means vulnerability, breach, loss, theft, and all those things we are desperately trying to NOT happen. Security teams are more concerned with the configuration than the automation. The configuration is what defines the effectiveness of the control.
As such, while DevOps values the automation of configuration, security values the configuration of the automation. Again, they want the same end state, but value different aspects of it. This is where tension, complexity, and difficulty arises.
The way around this conundrum is to elevate security to earlier in the development process. This is more commonly referred to as “Shift Left” as in moving security to the “left” side of a development timeframe.
Shift Left
The State of DevOps report highlights how organizations are moving security to earlier stages in development. The idea is that if security is moved to the beginning (thus the “left” side of a timeline) of development, then security can be more involved in designing the automation. The State of DevOps report also notes that this gives security the chance to work on threat models with developers early in the lifecycle.
We agree that Shifting Left has a lot of benefits, but it does not necessarily solve the “stuck in the middle” problem. In fact, shifting left may slow down integration at first. The report makes a number of suggestions, but we have some of our own as well.
1. Separate Corporate and Application Security
A common mistake we see in organizations is attempting to unify the organization’s corporate security, like email filtering or desktop encryption, with security for application environments. These are two different disciplines. They do not need to be done together. Bring Shift Left to application environments first, where DevOps practices are already in use. Let the concepts trickle down to corporate information security later.
2. Adopt Agile/Scrum Methods to Security
One of the simplest ways for security and DevOps to align is for security to adopt development project management methods. Layout security tasks in a project management tool, like Jira. Organize work and goals in sprints and epics. Hold daily standups. At the end of each epic, perform a reflection. The discipline of these processes helps better align DevOps and security.
3. Do Not Skimp on Test Automation
Automating deployment and configuration is important, but so is automating testing. It’s not enough to deploy some control, you must design an automated way to evaluate it being deployed, configured, and secured correctly.
4.Think Guardrails
Build automations (guardrails) that continuously monitor configurations and activity for security. In a secure environment, everything should operate within defined parameters. There cannot be any discretionary access or random changes.
5. Compliance Can Be Security
Here is where I would depart from the advice of the State of DevOps Report. The report continues to perpetuate the idea that compliance is not security. I have written on this very topic in my blog The Problem with Compliance. What the report does not consider is how compliance frameworks, like PCI or FedRAMP provide a well-documented set of security best practices that can focus automation efforts. (Yes, that is exactly what our Compliance Automation platform does.) We believe compliance can help focus automation efforts and eliminate debate.
6. Do Not Put Much Into Technology Rankings
The best endpoint security solution is the one that is consistently configured, properly monitored, and automatically adjusted to an organization’s size. The brand used is largely irrelevant. Do not get bogged down in tech shoot outs and stack rankings.
7. Do Not Ignore the API
While tech rankings may be less relevant, one feature that is not is application programming interfaces (APIs). Not all security technologies have APIs (or well-developed ones). When it comes to automating a security control, you need a robust API. Automating without an API is possible, but generally, it is much easier to automate when there is an API. When you are considering security tech, make a robust API a requirement.
8. Never Stop Pentesting
Security testing is an effective way to identify security weaknesses. Pentesting an environment once a year is woefully insufficient. Environments should be tested continuously. Empower internal security teams to conduct weekly tests, and external vendors to validate those tests on a monthly or quarterly basis. Also, any significant change to an environment, like adding a new service or changing the architecture should prompt a top to bottom security test.
Conclusion
The Puppet State of DevOps report is one of our favorites at Anitian. While the various security annual reports, like Verizon’s, are always validating as a security professional, Puppets’ report takes a different approach. That of the daily grind of building secure and compliant architectures. As a company that has always placed defending businesses ahead of analyzing breaches, this report is more satisfying and practical.
It is not easy to build a secure, automated environment and the report absolutely confirms that. However, when you look at the sheer complexity of today’s threat landscape, there really is no other way.
