Cloud Security Posture Management – CSPM – is quickly becoming the gold standard for every organization with cloud-first initiatives. CSPM tools help cloud security teams document and visualize what resources live in their cloud environments and determine whether the proper security controls are in place.
The reason why CSPM has become the gold standard is that organizations needed an easier and more automated way to understand their cloud infrastructure investment. According to TechCrunch, the cloud infrastructure market soared to $178B in 2021, growing $49B in one year. With this explosive growth, organizations are increasingly funding cloud initiatives and are leaning on CSPM to help protect their investments in their cloud infrastructure.
CSPM Core Functionalities
The core CSPM functionalities defined below are the building blocks to ensure a secure and correctly configured cloud infrastructure. One of the major issues facing organizations is the human element of making mistakes. The capabilities that CSPM provides remove these potential mistakes by leveraging the cloud providers’ standards in an automated manner.
Detect & Auto remediate cloud misconfigurations
One of the core pieces of functionality of a CSPM solution is the ability to identify misconfigurations based on the cloud providers’ standards. A simple misconfiguration like an unencrypted S3 bucket could lead to a major security breach. At scale, cloud architectures are very complicated so having a solution that provides a list of misconfigurations is critical.
Identifying a misconfiguration is just half of the problem. Remediating it is just as important. Some CSPM solutions can fix these misconfigurations based on the cloud providers’ specifications. This saves a ton of time.
A visual map of all the cloud services
Cloud infrastructure can be complicated to understand via textual or list representations. The interaction of the cloud services in a visual map context is much easier to understand. It provides the end-user a much better understanding of what services are doing and how they interact with other cloud services.
Able to identify cloud infrastructure drift
Cloud architectures go through a lot of approvals to ensure they are architected correctly. It is assumed that they stay architected as expected but there are instances where an unapproved change happens and the cloud architecture drifts away from the approved version. CSPM is very good at identifying when cloud architecture changes unexpectedly.
An SBOM of all cloud services
CSPMs typically provide a comprehensive Software Bill of Materials (SBOM) associated with the cloud infrastructure it is monitoring. This includes things like service names, versions, and dependencies. This information is critical to know especially as it relates to issue resolution.
Continuous monitoring of cloud infrastructure
CSPM provides a holistic and ongoing view of your cloud infrastructure for risk and misconfigurations. This is a very complicated process without an automated solution like a CSPM. CSPM also takes out the human error element of the equation.
Identify Data Risk
Ensuring that cloud service storage components are one of the main risks cloud infrastructures face. Are they configured and encrypted correctly? Is your storage service publically accessible? These are all key features of CSPM providers.
Detect Policy Violations
The ability to automate policy violations is very important as it allows you to immediately respond when something unexpected happens. Without policies driving actions in a CSPM solution, it would be very difficult to identify what is happening and why.
Cloud Provisioning Automation
CSPM solutions are also capable of automating cloud infrastructure provisioning using technologies like Terraform and CloudFormation. While this functionality is not the same in all CSPM solutions it does allow for a proactive approach rather than just a monitoring approach. This is important because it gives you the ability to update your cloud infrastructure with the click of a button.
Monitor account and role permissions
Do you have overprivileged users or roles in your cloud infrastructure? A best practice is to provide these entities with least-level privileges to accomplish their job or activity. Being able to see if there are over-privileged users or roles significantly decreases the risk in your cloud infrastructure.
Gaps in CSPM Functionality
While CSPM has become the gold standard over the past few years, some gaps in the technology still lead to potential attack surfaces going undetected (if you solely rely on CSPM to protect everything that runs in the cloud).
CSPM proves a lot of value for cloud teams, but there are a lot of application-specific gaps that need to be filled. For example, here are the more critical types of application-specific risks that CSPM cannot find.
All Application data flows and services
The main purpose of any modern application is to process data between application services. The data that applications process is the main target of hackers. Data like PII, PHI, and PCI are the prime target for hackers. Knowing all the upstream and downstream data flows in your application is critical to secure it. CSPM can only see applications from the outside so it does not understand how data is being internally processed by the application.
Application Service Drift
The unanticipated drift of application architectures may introduce unmanaged risk in your application architecture. If an application architecture drifts away from the approved architecture some sort of notification is critical to address this issue. CSPM cannot identify application architecture drift because it does not look at the deployed artifacts of the application.
Misconfigured Secrets in an application
Misconfigured Secrets in an application such as hardcoded passwords are a major security risk for an application as they may allow access to protected system resources without proper authentication. CSPM does not see any of the code for the application deployed to the cloud infrastructure.
Multi-Level application risks such as an application service with a critical CVE consuming PII data
Typically attacks have multiple variables associated with their execution. For example, having an application service that has a critical CVE that accesses PII data may provide a hacker an easy path to a data breach attack. CSPM is not looking at the interaction of application-level services so it would never see this type of vulnerability.
Identifying and Prioritizing Zero-Day Vulnerabilities such as Log4Shell and SpringShell
The identification of zero-day type vulnerabilities is a complicated process once the details of the zero-day vulnerability are made public. Once the vulnerable libraries are identified it is even more complex to prioritize what to fix first. CSPM cannot help with the prioritization as it does not have the application-level information to understand what library would be more dangerous than another.
Continuously Updated Application-specific Dynamic Bill of Materials (dBOM)
With today’s aggressive CI/CD release cycles it is hard to keep an SBOM associated with an application up to date. Having an accurate and continuously updated SBOM is critical in addressing issues like new zero-day vulnerabilities and vendor architectural questionnaires. While CSPMs do provide an SBOM of the cloud services it does not provide the same information at the application layer.
Security, risk, and misconfiguration issues unique to your application’s architecture
The hardest issues to find are the ones that are unique to your application architecture.
For example, a web application with a critical CVE accessing PII data and also communicating with an unauthenticated 3rd party API are very difficult to identify. CSPM does not have this level of application service detail so this type of issue would go undetected with CSPM alone.
Automated and Continuous Application Threat Modeling
Automating the creation of an accurate application architecture map for threat modeling purposes is impossible without leveraging the code artifacts themselves. CSPM does not have access to application artifacts so it cannot create an application architecture map like it can for a cloud services architecture map.
Application-specific risk policies
Creating policies to find risk in an application architecture requires application-level details like data flows, dependencies, and a complete application service list. While CSPM can create policies associated with your cloud infrastructure it cannot provide the same level of application-specific policy.
Application dependency mapping
Understanding the dependencies your application needs to function is a complicated activity. Missing even one dependency could cause functionality to not work correctly in your application or cause the application to crash. Knowing all the application dependencies is critical for all cloud transformation activities. CSPM understands the dependencies of the cloud services but does not identify application-specific dependencies.
Why Should I Care?
By just having a CSPM solution, you are only 50% covered in terms of security posture by a secure cloud infrastructure. The applications themselves are the other 50% of the security posture equation. The only way to have 100% coverage is to ensure the cloud infrastructure and applications are properly monitored.
100% coverage sounds much better to me.
Significant Gap: Cloud-Native App Visibility
There is probably a reason if you spend a ton of time, resources, and money on your cloud initiatives. I am guessing that you want to deploy applications to your CSPM monitored cloud infrastructure? With CSPM, you are continuously aware of the state of your cloud infrastructure but not the apps you are deploying to the cloud infrastructure.
Cloud-native is all about designing applications explicitly for cloud deployment. The issue is that although these applications are designed for the cloud there is still risk associated with the application regardless if it is deployed into a secure cloud environment. CSPM does not understand application-level risk – which is a huge problem.
A direct quote from a connection of mine that works for a CSPM vendor is, “Our product can see the apps deployed to the cloud infrastructure and provide a bit of information, but the app is a black hole to our product.”
CSPM Map vs. Application Map
One of the core features CSPM products provide is a map of the cloud services and not the services that make up the application deployed to the cloud. For example, AWS Cloud services commonly used are AWS EC2, Amazon RDS, Amazon S3, and Amazon Lambda, while application services are web applications, databases, message brokers, and 3rd party components in addition to their risk scores.
Application Map Example
Above, we see all the application services that comprise an application architecture. In addition, risk scoring information is provided directly on the map so you can see where to focus your remediation efforts by focusing on the higher risk scores first.
ASPM + CSPM gives you the complete picture
Having a complete picture is essential to mitigating risk.
If you have any cloud initiative in your organization, CSPM is a very effective solution to ensure that your cloud infrastructure is secure, continuously monitored, and configured correctly. The problem is that CSPM does not provide the same type of information for the applications deployed to your cloud infrastructure. To have a complete application security posture, you need to have a secure cloud infrastructure and a secure and properly configured application architecture. Just having a CSPM solution does not provide 100% risk coverage.
Although similar in concept, ASPM, and CSPM solutions provide very different information. This information is critical to ensure cloud infrastructure and application architecture are secure and configured correctly but having just CSPM is not a comprehensive approach. You are entirely missing the risks associated with your production applications.
Check out a demo of Bionic to see how ASPM approaches cloud application security: