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.

‍

It’s often the role of the DevOps team alone to interpret written security policy and build it into practice. However, most DevOps team members aren’t security engineers. They’re seldom involved in creating policy. They’re expected to read it and figure out how it applies to the systems they create. This is problematic for a number of reasons:

• Many policies are not specific enough to provide clear direction; there can be many different interpretations of even the easiest-to-read security policies.
• There’s opportunity for human error.
• Written policy can encourage overthinking and analysis paralysis.
• Security policy often contains outdated standards and practices that aren’t applicable to the current infrastructure.

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:

• Define policy that applies directly to the infrastructure in place
• Ensure that policy is clear and actionable
• Understand how existing policy applies to system changes
• Establish new policy as infrastructure grows and transforms
• Translate policy into active practices
• Create security checks that ensure systems meet policy standards
• Develop understanding that security should be constantly improving

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.

• Continuous integration accelerates development while keeping code quality high. Teams quickly spot integration issues because build and test processes are automated. The team stays aligned and avoids code conflicts, which increases overall productivity.
• Continuous delivery refers to keeping code in a deployable state by automating the staging process. DevOps automatically deploys code to an acceptance environment. From there, the team can instantly release to production. Catching issues early is an essential part of continuous delivery.
• Continuous deployment represents a fully automated process from building to testing to staging and deployment. When automated tests pass, automation pushes new code to production without manual assistance. With end-to-end automation, DevOps teams can scale release cycles and accomplish more, faster.

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:

• Identifying security misconfigurations and bugs in runtime is simply too late. It essentially puts organizations in the difficult position of racing attackers to find vulnerabilities.
• Catching a security issue at runtime disrupts flow and wastes labor. Limiting testing to runtime scanning alone can cost the organization up to 30 times more than identifying issues during the development process.  
• When developers discover security issues at the very end of the SDLC, they’re under exceptional pressure to address them quickly. This can encourage flawed workarounds and sloppy solutions.

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:

• Make security a part of each step in the SDLC.
• Unite the DevOps and Security teams to collaborate on actionable policy.
• Position security policy to grow and adapt with the organization’s infrastructure.
• Automate security policy checks as much as possible to make them part of the CI/CD pipeline.

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.

‍