Extend–don’t shift–left cloud security posture management (CSPM)
Cloud Security Posture Management (CSPM) is a category of security tools that helps to maintain a secure posture in your cloud environment. As cloud resources are created, operated, or reconfigured, the CSPM tool monitors the cloud environment to determine if security risks are being introduced into the environment. It’s obviously important to secure the cloud environment, but is CSPM being upended by the DevOps revolution?
What's wrong with Cloud Security Posture Management?
Historically, CSPM tools have been used by security and operational teams to monitor the cloud runtime environment as a way to prevent accidental and malicious misconfigurations. When problems are found, the CSPM tool often has the ability to trigger automated actions that fix the misconfiguration. It’s a convenient approach because security teams can protect against misconfigurations regardless of whether they come out of the development process, they are introduced by operators or SREs in runtime, or they are introduced through nefarious channels.
This is especially valuable for security and compliance teams because it continuously monitors the runtime and enables them to assure compliance. Moreover, the ability to automatically respond to problems means that teams can establish a secure configuration baseline which ensures non-compliant resources are automatically and more or less immediately rectified.
And that’s the first sign of trouble: before a problem or risk can be fixed, it must first be detected. The CSPM tool can detect the problem, but the fact that it can be detected at all belies the fact that it must be exposed. Just as the CSPM tool can find the problem, so can an attacker. In other words, the approach of identifying risks in the cloud runtime includes the inherent weakness that the risks you want to protect against must first be exposed.
A case can be made that this is not a huge problem, if risks are detected and fixed fast enough. But there is no guarantee that is the case, depending on the tool used and the level of automation implemented. But the scale and scope of the problem grows as teams adopt DevOps practices.
CSPM in the age of DevOps
As organizations leverage DevOps, another problem has emerged with CSPM solutions. Modern teams, especially those leveraging cloud technologies, are increasingly using infrastructure as code (IaC). This doesn’t necessarily impact the efficacy of CSPM tools, but it creates some practical and operational challenges.
Cloud resources and configurations originate in the IaC, and the deployment pipelines use the IaC to provision the infrastructure upon which the application will run. If misconfigurations exist in the IaC, they will be deployed with the application. The CSPM tool will ideally identify those problems quickly and fix them, but the fixes are applied in the cloud runtime rather than in the IaC. Every time the application is deployed, the misconfigurations will be reintroduced to the runtime environment and give attackers an opportunity to exploit them before the CSPM tool can fix them.
Some CSPM vendors have added IaC scanning capabilities to their toolsets, to enable these teams to identify misconfigurations in the IaC before deployment. This is a great improvement, but also creates new problems. The IaC scanners are generally configured separately from the runtime tools – meaning that teams need to maintain two different configurations and toolsets, and any differences between risks identified in IaC and in runtime will create confusion. It also means that there’s still a chance for misconfigurations to get past the IaC scanner and be deployed into the runtime.
And every time a misconfiguration is fixed by the CSPM tool, the cloud runtime configuration moves a little bit further away from the configuration defined in the IaC. This so-called drift creates even more problems, because development teams are no longer aware of the environment within which the application runs and operational teams may compound that problem with fixes applied in runtime.
Fixing CSPM for DevOps
Solving these problems requires a CSPM tool that truly understands IaC – one that can consistently identify problems in both IaC and runtime with a single configuration. This ensures that resources are secure before they are deployed, and any risks introduced after deployment are also identified. When fixes are required, instead of applying them in the runtime, where they exacerbate the problem of drift, they should be applied in the IaC. This keeps the IaC as the single source of truth and allows teams to leverage secure and operationally robust paradigms such as immutable infrastructure.
Perhaps more importantly, these improvements help ensure that all functions — development, operations, security, and compliance – are aligned behind the same definition of success and are able to communicate effectively. This has the effect of breaking down the silos that too often exist between DevOps and security practitioners, and begins to build a culture of security everywhere. And it translates naturally to models such as GitOps and security as code which depend on an accurate codified representation of security policies, infrastructure configuration, and application logic.
For more information, please download The Buyer’s Guide to Next-Generation Cloud Security Posture Management.