by: VMware Engineer, Cloud Security (VGS) Casey Lems
Sad to say, it’s not a matter of if a threat actor is going target your environment and put your security posture to the test, but when. Once an attacker gains that access, they immediately attempt to mimic and exploit admin credentials to expand their footprint in your network. That’s why the greatest secondary defense is to immediately wall them off—ensure the virtual ‘room’ they entered has absolutely no doors.
Accomplishing that feat involves establishing the right permission strategy via least privilege, which in turn can be combined with threat mapping software like CloudHealth® Secure State™ to present a formidable defense.
The key is automation. In general, there is an enterprise cyberattack every 11 seconds, and that means non-human intervention is required. Once all the permission parameters (guardrails) have been established, it’s straightforward to automate least privilege. Of course, teams need to identify what they are looking for based on the enterprise’s rules, regulations, and other factors. Otherwise, security teams risk garbage in, garbage out scenarios that benefit no one except threat actors. This is similar to a doctor requesting blood work from a lab—the lab needs to know what it is looking for in order to generate the best results.
Searching for a new identity
The first step in least privilege is to establish identity parameters and profiles based on three major buckets (see Figure 1).
Figure 1. Three major buckets to consider prior to establishing permissions.
Static inputs are those things which generally stay the same— what compliance framework an environment must adhere to, or the classification of data which dictates who or what should have access to it.
These are the easiest to tag and oversee due to their consistent ‘boring’ nature. Different assets (app, technologies, etc.) have different security requirements and unique exposure rates, thus the need for threat models. And, naturally, there are dynamic inputs in the enterprise ecosystem that will change a lot, and therefore require ‘fluid’ permissions.
Putting your cards on the table
Let’s take the example of AWS s3:GetObject used to downloading files from S3. Applying our three buckets, we can conduct an identity profile analysis (see Figure 2) that enables developers and administrators to understand every potential access point a threat actor might try.
Figure 2. Identity profile analysis of AWS s3:GetObject scenario.
Now, let’s examine an even more serious potential breach—creating a new user via AWS iam:CreateUser. The identity profile analysis i(see Figure 3) demonstrates that even with a ‘For Official Use Only’ classification, allowing new users to be created can be a road to ruin.
Figure 3. Identity profile analysis of AWS iam:CreateUser scenario.
Solving the puzzle, each and every time
At VMware, we employ Secure State to put the puzzle pieces together to create an interconnected cloud security model (see Figure 4). The solution comes with 300+ rules right out of the box, and offers infinite customization to meet specific needs.
Once criteria are entered, Secure State delivers all the relationships between various components in the cloud. This can radically alter the way least privilege is implemented versus traditional siloed approaches that can inadvertently miss an open door. There is no longer the need to manually go through each potential scenario, parse together relationships, or other labor-intensive tasks. This frees up cloud security teams to focus on more mission-critical issues, as well as ensures the enterprise is safer regardless of the threat at hand.
Figure 4. Identity profile analysis of AWS iam:CreateUser scenario.
Helpful hints (that worked well for us)
While there are no set rules for least privilege, there are some general guidelines our teams have been following for protecting apps and data, including deploying Zero Trust strategies.
Start by asking internally if there are any permissions that should be uniformly denied or flagged from use by service users. Establish identity profiles for your service organization and find ways to detect non-conforming resources. Engage with cloud developer teams to help them understand the value of least privilege—getting everyone psychologically on board with a new paradigm is more than half the battle.
Be carefully using provider-managed IAM policies (ReadOnly, PowerUser, etc.), especially when it comes to service accounts, and avoiding using wildcards when possible. Infrastructure as code can definitely help!
Finally, use ephemeral credentials whenever possible, and don’t forget to employ resource policies to further your least privilege strategy.
Check back for more updates on this ever-changing topic.
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 [email protected] to schedule a briefing on this topic. Visit the VMware on VMware microsite and follow us on Twitter.
