In the past year, devastating cloud security breaches have dominated technology headlines. These big news stories are only the tip of the iceberg in cybercrime—we don’t hear about the thousands of successful attacks that cripple worldwide businesses every day.
The victims are financial institutions, governments, businesses, and other organizations who have seemingly thorough security policies in place. But these policies fail to protect them. Let’s explore why.
In most organizations, security policy is a written document. The Security team works long and hard to develop a policy that will protect the organization’s assets. The result is a curated description of standardized practices and procedures meant to keep data and other assets safe from bad actors.
And what does this carefully crafted policy do?
It sits passively.
The written policy waits for someone to use it. Sure, there’s probably a meeting to review the policy when it’s first completed. (And let’s face it, most DevOps team members avoid that meeting, expecting it to be long, dull, and only vaguely applicable to the work they do.)
The Security team shares the policy (sometimes in a video training format) with the organization, who is required to review and sign it. But most people only skim it. Perhaps curious and cautious individuals reference it now and again. So the written security policy lies, isolated and passive, like a sad, dusty book on a back shelf.
Meanwhile, DevOps is a hotbed where growth and change abound. An approach designed to fit in a world of fast scaling and agility, DevOps quickly reacts to changing requirements and organizational needs. Deployments are frequent, or even constant. DevOps teams embrace the concept of failing early, addressing problems through testing, automation, and small deployments.
Where does the written security policy fit in such a system optimized for constant growth and change?
It doesn’t.
Few DevOps engineers absorb security policy as something that applies to their everyday work. We hear again and again, “Security writes these policies and comes up with findings, but they don’t have any engineers. They have no idea how the infrastructure really operates.” There is a wide gap between security policy and those who would implement it. DevOps understands how implementing security requirements would affect the organization’s ability to reach its goals and budget.
The traditional, static security policy is too often seen as abstract and inapplicable in a fast, complex, and dynamic space. Security, in a DevOps environment, needs to be flexible.
Cloud computing, by nature, is complex. Think about how we’ve evolved from the original computing environment of just one server, an operating system, and an application. Adding and combining more servers, virtualization (such as VMware), and containerization (such as Kubernetes) introduced great complexity. Moving all of this to the cloud and distributing our infrastructure makes computing even more complex than we ever might have imagined.
There are more moving parts, and those parts are integrated so they depend on one another. Building, testing, release, deployment, and monitoring are all elements in a single, intricate system.
Continuous integration and continuous deployment (CI/CD) introduce more complexity. CI/CD principles (automation of integration, testing, and deployment; test as early in the process as possible; standardize and codify processes to remove dependency from specific individuals; and so on) aim to reduce cost and time and consistently deliver changes to production. Often, acting on these principles requires a broad patchwork of tools, introducing new complications.
This complexity doesn’t simplify over time. In fact, it grows. Data expands and transforms, tools change, and the organization’s needs evolve. Not to mention that DevOps teams are infamous for living on the bleeding edge and adopting the latest patterns and tools. All of these changes are capable of introducing new risks.
Security can’t keep up with infrastructure changes. And often, but the time new policy is in place, it’s already inapplicable. But DevOps is expected to act on policy. This introduces its own difficulties.
Security policy must be able to grow and adapt as an organization’s infrastructure grows and adapts. And it must do so at a speed that matches the infrastructure changes, or it will leave the organization’s assets at increasing risk.
DevOps and Security teams must work together to achieve these goals:
A key aspect of the DevOps system development life cycle (SDLC) is constant motion. In DevOps, everything is continuous. No one part of the process waits for another. This helps teams streamline software and infrastructure changes, improve code quality, and deliver new experiences to market more reliably.
Security policy needs to be a part of this constantly moving system in order to have any impact. How can a static policy fit in?
The most obvious answer is to translate policy into security checks. But, as mentioned above, this can be challenging for many reasons. And the classic DevOps team reaction is to find existing tools and services and hope that those solutions cover their organization’s policy.
The security tools that DevOps teams use are designed to be consumed by DevOps teams. Yet, even when DevOps teams do the work and share the output of these tools, Security teams (and the business structure above them) don't gain insight into whether the infrastructure is actually more secure.
Runtime security checks are important. But testing security in production has serious shortcomings:
Runtime scanning is necessary, but it should be among the last lines of defense. It's important to start testing much earlier in the development cycle and to integrate security verification throughout the SDLC.
Many organizations have embraced DevOps but continue to practice security according to the old ways: a siloed Security team, and either no security testing or testing that comes too late.
To ensure the security of an organization’s data and assets, it’s important to:
The ideal is to reach continuous compliance: security policy and validation tightly integrated into the continuous system lifecycle. Mondoo helps organizations achieve this ideal by continuously running policies against every change, in any CI/CD workflow, on all environments.