By Chris Binnie
Each week it seems that we are informed that our data has been exposed to the internet by another household name.
In part this is because serving customers via applications that are run in the cloud is exceptionally difficult to do in a secure manner. It is not just a case of securing the network perimeter any longer, instead the dynamic nature of modern applications means there are multiple attack surfaces to secure.
Typically, the main components of a cloud estate would be broken down as follows, although it is worth noting that often multiple tools are utilised to monitor and protect each of these components and their associated subcomponents.
Firstly, the cloud infrastructure itself, or multi-cloud infrastructure, needs to be continually checked for non-compliance. In other words, even on a medium sized cloud estate, operators need to monitor the misconfiguration of hundreds of thousands of cloud platform settings that may pose a security threat. This falls under the category of Cloud Security Posture Management (CSPM).
Secondly, the services within that cloud infrastructure need to be hardened against attack. In a cloud native environment often the applications that are presented to the end users are running in containers, which provide a useful way of developing applications in modern environments. In order to run multiple containers efficiently, orchestrators are often used. These are generally based on a service called Kubernetes, which was developed by Google around a decade ago. In addition to containers, serverless functions need to be hardened too; this is where the infrastructure is less configurable by users and provided as a managed service to a greater extent. Where the applications or workloads need to be secured, this is often called Cloud Workload Protection (CWP).
Last but by no means least, is the application code itself. Commonly many vulnerabilities, that have been rated by severity using industry consensus, are discovered within both containers and serverless functions. These are known as CVEs (Common Vulnerabilities and Exposures).
Remediating these vulnerabilities, by upgrading the software packages that have the bugs present, is often the most labourious part of securing applications. This is partly thanks to the fact that enterprise-grade security tooling can identify vulnerabilities that have not been fixed by the software vendor that created the package. As a result, trying to mitigate the threat without patching the software is time-consuming to research. Enterprise security tooling can help with more than just the monitoring of these vulnerabilities though. And, often older vulnerabilities that have been patched by the software vendor will offer “fix status” advice. This is where a specific package version is shown to the developer or analyst responsible for remediating the vulnerability. When they upgrade the current package to that later version, the vulnerability alert will be resolved.
To confuse things further, the applications running in containers or serverless functions also need to be checked for non-compliance. Warnings that may be presented by security tooling when these applications are checked against recognised compliance standards, frameworks or benchmarks for noncompliance are wide and varied. For example, if a serverless function has overly permissive access to another cloud service and an attacker gets access to the serverless function’s code via a vulnerability, the attack’s blast radius could exponentially increase as a result. Or, often compliance checks reveal how containers are run with inappropriate network settings. For example, if a container is running within a closed environment, analysts or platform operators need to know if it has access to the internet somehow.
At a high level, these components and importantly, how they interact with each other, is why applications running in the cloud require time, effort and specialist expertise to secure them.
If you couple that with the fact that attackers can run automated tools to check for non-compliance and vulnerabilities 24/7, it’s imperative that the defenders of such cloud estates are equipped with the most effective security tooling available. In this case that tooling is known as a CNAPP. This is a Cloud Native Application Protection Platform which, broadly speaking, will secure multiple components through a single pane of glass. By employing AI functionality, CNAPPs can understand the expected behaviour of a resource, such as a container, and then immediately alert if its behaviour changes. That nuanced change could be a successful compromise which needs immediate attention.
A more ambitious approach to using CNAPPs is where automated blocking takes place, based on multiple indicators of an attack. Here, tooling can immediately stop an attacker from doing more damage but such blocking can be disruptive to live services and needs careful planning and consideration. In such dynamic cloud native environments, we essentially need computers to monitor our computers for us. This is where CNAPPs come to the fore.
Chris Binnie is a veteran cloud native security consultant, based in Edinburgh, with almost three decades of working with critical online infrastructure and main author of Cloud Native Security.