AI generated image of an office building that is secure on higher floors, but where the ground floor is open, visible and vulnerable to outsiders
There are economic and time-based imperatives to lift & shift systems and applications, even though refactoring to cloud-native platforms and services is more optimal. That doesn’t mean you should also lift & shift your security tooling stack into the cloud, though. The cloud adds new threats and risks that security tooling born in the data center isn’t aware. In addition, cloud security tooling can simplify your security stack and lower operating cost.
SAP went through rapid cloud transformation in the last five years and we learned a lot the hard way. Here are four challenges that we ran into, followed by the cloud security stack we ended up with.
Unaware of Cloud Infrastructure and Services
Legacy security tooling lifted & shifted from data centers may still provide value higher up the stack. But without monitoring and detection that is cloud-aware you leave yourself vulnerable to common cloud threats that legacy tooling cannot see. Relying on traditional security tools born in the datacenter would be like running an office building that is secured on higher floors, but where everybody can enter the ground floor and security guards pay no attention to who is getting onto the elevators.
Legacy security tooling may provide a false sense of security while lacking visibility in cloud-based events and infrastructure misconfigurations. No legacy tooling prevents or detects an open storage bucket or accidentally public snapshot, let alone the impact of leaked cloud credentials until it is far too late. When the solution is agent-based (and many end point solutions are), what do you do with cloud databases or managed Kubernetes nodes?
Focused On Runtime and Network
Legacy agent-based solutions focus on runtime and network security, both of which are diminished in importance in public cloud. Many corporate and data center networks are large open networks, so naturally network monitoring against threats is important. Cloud accounts however provide tenant isolation, where resources in other cloud accounts aren’t connected unless explicitly configured to do so. So when you deploy one system per cloud account you end up for far higher microsegmentation of networks than in the data center.
When systems need to communicate together, that is preferably done over HTTPS API calls, reducing the need for open network ports beyond 443. Administration of the landscape, whether through CI/CD pipelines or through the cloud admin web console, operates via cloud provider application programming interfaces (APIs) and administrators don’t directly connect into the system under normal circumstances. This leaves much of the network as a carrier of encrypted API calls.
Lateral movement in the cloud also manifests itself differently. The data center approach is for attackers to hop from one system to the next. But once the attacker has cloud admin privileges, they can create new resources. Your runtime tools can’t find an attacker even as loud as a crypto miner when they create new VMs. Those obviously won’t run your agent.
Instead of long-running servers that are carefully tended (“pets”), many cloud resources are often ephemeral and short-lived. VMs autoscale in minutes, containers may live only for seconds, and are constantly restarted from images in an image registry. That makes it very difficult for attackers to establish persistence in the traditional way. In public cloud, persistence involves gaining administrator privileges on the cloud account or Kubernetes cluster. Therefore, the primary focus instead is on Identity Access Management (IAM), role-based access control (RBAC), infrastructure configuration and the overlap between them: Cloud Infrastructure Entitlement Management (CIEM).
Cost and Per-Seat Licensing
Regardless of the cost model in your data center, it may be very expensive to run the same toolset in public cloud landscapes. Many vendors use per-seat licensing, when can get complicated and costly in the cloud. It may work for long-running VMs. But how do you calculate a seat when it only was around for a few hours? We cycle through some 30,000 VMs every 24 hours. Do all 30,000 count as a seat? Do we average the number of agents over a time period? This is not always clear.
Moreover, this model works very poorly in a situation of rapid growth. For several years in a row, we doubled the number of resources in the cloud. Per-seat licensing scales with that growth. The security tooling becomes a security tax, and security budgets cannot be expected to grow linearly with the size of the environment.
In the data center, you own the hardware. I don’t know if the practice has changed to spec servers for ~70% load on average. But that generally left a bit of headroom to run a security agent without changing the cost model. However, in public cloud, your compute and network use is metered. Since teams right-size their workload against a wide variety of compute instance configurations, adding the workload of an agent may push them into a different compute instance tier, and therefore higher costs. If alerts are transmitted over the network, they too add to run cost – whereas in the data center that network traffic would be considered “free” once the infrastructure is in place.
Cloud-native security solutions use the cloud providers’ API, which dramatically changes the cost logic. Our agent-less CNAPP solution is roughly five times cheaper to operate than an agent-based end point solution for the same number of VMs and container hosts. That math gets only better as the landscape continues to grow.
Onboarding and Operational Effort
It’s not enough to just buy a tool. You have to deploy it and operationalize it. This can be a challenge for legacy tooling. Developers have more autonomy than ever in the cloud and can deploy resources at will. Therefore, you need the active collaboration of those teams to install an agent on each of their end points. But the incentives all point the other way. I talked above about cost, but now you are also asking for operational effort in testing and deploying the agent, and make sure it communicates its alerts to a central back-end. That is not going to make the security team very popular.
Cloud-native security tooling instead can be deployed by cloud API, and can be done at the organizational level. That way onboarding can be done centrally and applied to all cloud accounts in the organization without any effort on the developer teams. Onboarding business units becomes largely a communication challenge, rather than an adoption challenge. Our Cloud-native Application Protection Platform (CNAPP) was deployed and rolled out to most of the organization in about three months. Our first central agent-based EDR solution adoption was abandoned after a year and a half as a failure.
For a variety of reasons, data center security tooling is often a collection of best-of-breed point solutions. In addition, through acquisitions organizations often own a collection of overlapping tools. This complicates the work of collecting data streams, enriching them with metadata and correlating them together in SIEM platforms. Each additional data source adds complexity and integration effort before they result in effective detections.
Over the last few years, cloud security tools have turned into platforms that cover many different use cases – unique in capabilities to the public cloud through the use of cloud provider APIs. They also contextualize these results, leading to high value signals that ease the work on the SIEM and detection teams and reduce tool sprawl. And retirement of legacy tooling provides further cost savings that can justify transitioning to cloud-native alternatives.
Based on our experience, the three primary requirements we set before even considering the security value of a solution are whether the tool is scalable, deployable and affordable. That dramatically reduces the number of vendors to evaluate.
Let’s have a look as SAP’s cloud security tooling journey since 2019. In a recent blog, I covered the cloud guardrails that make SAP’s cloud accounts more secure-by-default. The first of those was to centrally activate and collect cloud audit event logs such as CloudTrail and its equivalents in other cloud services providers. Since then they have been extended to a far broader scope of services.
Our cloud infrastructure security tooling (Cloud Security Posture Management, CSPM) proved the most challenging. Our growth, scale and multi-cloud nature proved too much for available commercial tooling on the market at that time, leading to SAP developing its own solution. Once that went live, we had for the first time full visibility across the entire landscape for the entire cloud infrastructure policy set. Since then we have worked ourselves to a 99% compliance rate.
We searched for a solution for higher up the stack that was scalable, deployable and affordable. We settled on an agent-less Cloud Native Application Protection Platform (CNAPP) that monitors cloud-native infrastructure and managed services, as well as VMs and container-based workloads through side scanning. It contextualizes both findings into risk-based alerts for misconfigurations, vulnerabilities, IAM alerts and file-based malware that facilitate prioritization within the organization. The CNAPP even supports asset discovery, important in a fast-growing, dynamic environment.
Since the solution is deployed through the cloud provider organizations just like the guardrails, employees or threat actors can’t bypass it. In October 2023, CNAPP replaced the in-house developed CSPM solution and in early 2024 will replace the existing network-based vulnerability scanner entirely for public cloud landscapes.
For runtime security, most notably EDR and Antivirus, SAP collected a variety of different security products selected by acquisitions or individual SAP business units, and largely legacy from the data center. This was centralized with an EDR solution from 2021, but this ultimately didn’t succeed. As mentioned earlier, adoption proved challenging. In 2023, SAP started rolling out a second solution for runtime that is more cloud-friendly.
The cloud security market has evolved dramatically in the last five years. I didn’t even hear of the CNAPP acronym until we were close to picking a vendor. Almost two years on, these CNAPP platforms have evolved and gained in features and functionality. The path to a cloud-friendly security stack is a lot easier now for those starting their cloud transformation later. If you haven’t deployed or looked at a CNAPP solution yet, I would strongly encourage you to do so.
Be the first to comment