Security

Why Cloud Security Is for the Privileged Few (Spoiler: It’s a Good Thing)

by: VMware Engineer, Cloud Security (VGS) Casey Lems and VMware Cloud Security Staff Engineer Mike Schimmel

The cloud has created a host of new security challenges as deploying appropriate preventative measures isn’t as straightforward as it used to be. Traditionally with on-premise solutions, the approach is to simply authenticate (AuthN) a user’s identity and then grant access. This involves incorporating complex passwords, biometrics, SMS, push tokens, email tokens, and various combinations.

And overall, it works. Even if a bad actor overrode AuthN controls within a virtual desktop infrastructure (VDI) environment, the enterprise can mitigate the impact as the breach is restricted to that sandboxed VDI ecosystem—a distinct ‘bucket’ that can be readily monitored and controlled.

Authenticated user security infographic

With on-premise security, an authenticated user has highly restricted access 

Cloud security is the same?

When the cloud became a dominant force in enterprise infrastructure, it seemed logical to simply lift and shift existing security protocols and apply them to API and service layer buckets. The only real difference was an emphasis on authorization (AuthZ)—what does the user have access to once AuthN takes place. This led to an unwanted imbalance between security and ease of use—including unrestricted security groups or over-permissioned service accounts—as the intent was to not hinder product development or negatively impact team productivity.

Unfortunately, these defenses are easily exploitable by even the most junior attackers. Teams inadvertently give more permission to a single shared account than intended. Normally, if attackers try to jump or infiltrate a virtual machine monitor (hypervisor) the actions would trigger numerous alarms. But in cloud, users have access to the whole cloud infrastructure, even if granted read-only access. 

Bad threat actors in cloud

The cloud poses significantly more (and more significant) security risks.

Doing the least possible

APIs are a key reason cloud security requires a different approach. There are tens of thousands of APIs across the public cloud, and each one is a potential exploitable gateway. Rather than apply traditional AuthN and AuthZ protocols, the solution is to do the contrary—implement leastprivilege controls and literally, as per Zero Trust, trust no one. In this way, APIs are treated like next-gen firewalls. Research has shown by implementing least privilege a significant number of attacks can be mitigated, even new or previously unknown types.

What that means in practice is that any and all privileges must be scrutinized—whether via humans, automation, or a combination. The system then determines the good, the bad, and when to implement least privilege based on the level of secure access allowed. This method removes many of the flaws inherent with the aforementioned over-permissioned approach.

Sorry, your time’s up

There are a variety of ways to implement least privilege, and we will cover those in future blogs. One recommendation you can implement immediately is to shorten token lifecycles. Traditionally, a signed Java token certificate or an API key pair has an expiration date assigned to it, typically 90 days. But that three-month window comes with two major drawbacks. 

First, it’s difficult for teams to support. Manual changes are continually required, and that’s an (unnecessary) drain on resources. More crucially, 90 days gives a threat actor more than enough time to inflict substantial damage—without detection. In fact, many breaches are found months, if not years, after the 90-day limit has passed. Typically, it takes three days for an intruder to successfully breach an enterprise environment, and 78 days on average for an enterprise to discover and take corrective action.

The easy fix is to limit token lifecycles to 15 minutes or less. The good news is that is remarkably easy to accomplish—the cloud provides native mechanisms that can set lifecycle limits automatically. You simply program it once and the system takes care of the rest.

This drastically reduced token lifecycle time severely restricts what a malicious attacker can accomplish, and virtually eliminates any chance of a threat actor learning the security ecosystem from the inside. This is conceptually similar to how auto thieves operate—they look for the quickest, least obvious way to accomplish their goal, and will generally move on to another vehicle if they can’t defeat a security system in minutes.

90 days vs 15 minutes stopwatch infographic

An easy way to thwart threat actors? Dramatically reduce token lifecycles.

Check back soon for more least-privilege blogs.

VMware on VMware blogs are written by IT subject matter experts sharing stories about our digital transformation using VMware products and services in a global production environment. Contact your sales rep or vmwonvmw@vmware.com to schedule a briefing on this topic. Visit the VMware on VMware microsite and follow us on Twitter.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *