Cloud Native Application Protection Platforms (CNAPP) are a new category of security tools that are designed to protect cloud-native applications. CNAPPs are a combination of functionality that comprise Cloud Security Posture Management (CSPM), Cloud Workload Protection Platform (CWPP), and Cloud Infrastructure Entitlement Management (CIEM). More recently they’ve integrated SAST (Static Application Security Testing) for workloads which are built using IAC (Infrastructure-as-code). Oof, now that the acronym soup is over, let’s make sense of all this and what this means for you in your enterprise security framework.
CNAPP
In its simplest form, CNAPP is essentially a ‘vulnerability scanner for the cloud’. If you think of your on-premise vulnerability scanners, including the different asset types that are covered, you’ve got your containers, databases, servers (both virtualized and physical) and networking assets such as switches, routers and firewalls. Vulnerability scanners can audit these, point out configuration errors or vulnerability issues. So far so easy. When this is transplanted into the cloud though, things get a bit more complicated.
A traditional on-premise vulnerability scanner doesn’t understand cloud native assets. Think of an AWS S3 bucket (which is essentially a discrete storage asset) and a vulnerability scanner will simply ignore it. Why? Well because it doesn’t have an IP address or even an operating system so not only can the scanner now not find it or audit it, it doesn’t even understand what it is. Same again for a Lambda (a serverless asset). This doesn’t have an IP address, and an infrastructure scanner or even a web application scanner would have a hard time figuring out what it is. Thus it’s promptly ignored leaving a nice invisible risk to fester within your enterprise infrastructure.
Thus, CNAPP was born, as it now covered traditional assets (containers, databases, and so forth.), as well as native cloud assets (S3 buckets, security groups, Azure blobs, and so on.). The acronym itself is a vendor creation; but lets dig deeper to find out what its components are and what they are supposed to do. Keep in mind CNAPP wasn’t created initially with all these sub-components; and some products still market themselves as having only specific functionality, so it’s worth pointing out the difference.
Cloud Security Posture Management (CSPM) is perhaps the best known precursor to CNAPP and the most common functionality suite within a CNAPP tool. CSPM focuses on Misconfigurations. Cloud environments are complex, and it is easy to make mistakes when configuring cloud resources. The most common configuration issues would be security groups configured with any/any access or S3 buckets that are unencrypted or made public by default.
Next we have CWPP (Cloud Workload Protection platforms) which overlaps a little with CSPM functionality but will focus on scanning cloud workloads for vulnerabilities and out-of-date runtimes. This can include some aspects of DLP and even some IDS functionality (depending on the vendor). Certain agent-based solutions can also offer encryption; and again, all this is single pane of glass and cloud agnostic.
CIEM (Cloud Infrastructure Entitlement Management) is slightly different. It focuses on the process of controlling and managing access to cloud resources such as data, applications, and services for different users or groups of users within an organization. This involves defining roles and permissions for each user, and ensuring that they only have access to the resources they need to perform their job functions, and all this within the context of cloud native access control (think of AWS roles). Naturally, this has many security advantages that range from the obvious (improved security) to the more mundane (better productivity for employees and reduced management overhead in access control audits). There are also compliance advantages to maintaining a robust access control framework that’s automatically audited, and this will translate into all of the above benefits (productivity, security, lower overhead).
Lastly, more and more CNAPP tools now incorporate IAC (Infrastructure-as-Code) scanners since a lot of cloud workloads are now built with tools like terraform, essentially reducing workload production and config to a few lines of code. This is an interesting development, not least because this functionality competes directly with SAST (Static Application Security Testing) vendors, and would eat into their market share. After querying this with CNAPP vendors directly, it seems many of them are content to now compete directly in this space as they offer a higher value by adding code scanning on top of all the other resident benefits of CNAPP. Look for lots more vendor acquisitions in this space as this battle heats up.
Now you’d be forgiven for thinking that all the components of CNAPP aren’t necessarily required for your use case and you’d be right. There is no ‘most’ important component of CNAPP. You may even have a hybrid environment so your use cases may be spread out across cloud and on-premise environments, and you may be piggy backing both legacy security tools and cloud native tools. In this instance, you may only be interested in the CSPM functionality of CNAPP while the CWPP component is off-loaded to other tools. Likewise you may forego all of those and only be interested in the access control and entitlement portion of cloud auditing, which is arguably more complex than on-premise environments.
When faced with this dilemma, it’s always important to remember the ‘role’ of the tool that you’re using, based on the specific needs and priorities of an organization. Below are some context and examples to help you understand the roles of each component and how they contribute to overall cloud security.
Roles and Components
Remember that the CSPM portion focuses on identifying and addressing security risks in cloud infrastructure with a particular specialty in misconfigurations, vulnerabilities, and compliance violations. For example, an organization might use a CSPM tool to monitor their cloud infrastructure for open ports or insecure network configurations.
CWPP focuses on protecting cloud workloads, such as containers, VMs, and serverless functions. This involves deploying security controls, such as firewalls and Intrusion Detection Systems (IDS), to protect against threats such as malware and unauthorized access. For example, an organization might use a CWPP tool to protect their containerized applications from attacks such as container sandbox escapes or runtime injection.
CIEM focuses on managing user access to cloud resources. This involves defining roles and permissions for users and ensuring that they only have access to the resources they need to perform their job functions. For example, an organization might use a CIEM tool to control access to their cloud storage buckets for a defined population. This can help prevent unauthorized users from accessing sensitive files and ensure that only authorized users can modify or delete data.
But wait, to complicate things even further vendors have now started releasing DSPM modules, which stand for Data Security Posture Management. These should be thought of in the context of your traditional DLP (Data Leakage Protection) tools that you may already have deployed across your organization. Again, just like their CSPM counterparts they focus on cloud native environments. Having used this quite a bit and seeing their evolution over the years, they now almost behave like traditional DLP tools. They will pattern match according to structured data of your choosing and alert you depending on the threshold of the alerts set.
For example, depending on the vendor, you can pattern match on the following:
- PCI related data, such as card numbers
- E-mail addresses
- Hardcoded Secrets and API keys, such as AWS keys
- SSH keys that have been saved in publicly available directories
- Passwords that have been saved in cleartext
- Medical data
- Other PII identifiers such as passport numbers and social security numbers
Again, these will only work on cloud native environments, so in a hybrid setup you may be carrying two sets of tools that duplicate a security functionality, but this will again provide a single pane of glass across all your cloud environments.
Conclusion
With all that covered it hopefully gives you a better idea of what CNAPP covers, and crucially, what it doesn’t do (This will help you avoid the pitfalls of thinking they are a magic bullet for all your cloud security concerns). As products are continually developed, expect to see a lot more functionality appear in these products (and more acronyms too). The current fast-moving areas of focus and development seem to be in the SAST and DSPM space, so always remember to run a good proof of concept to test requirements against functionality so that you up with the CNAPP product you need, and not what a CNAPP vendor wants you to have.
There are other factors to consider when acquiring CNAPP software that aren’t necessarily technical in nature but are quite important to how the product will run within your organization. Licensing models have become more important as the variety of cloud assets has propagated. The current licensing models can range from the straightforward (number of VM’s) to the bewildering – some of them require entire spreadsheets to license your environment as they multiply and divide different asset categories to end up with a final license count. Don’t forget final budgetary cost and of course, even something as simple as localized support if you’re an international organization.
Once complete, you’ll find CNAPP provides a comprehensive toolset to help you manage cloud security within your business and will be a valuable asset in your enterprise security framework. 
Alex Haynes
Leave a Comment