Sensors Up! Start a Data Perimeter with Access Analyzer

There's a lot to creating a cloud data perimeter, so this week we'll learn what the heck a data perimeter is and use Access Analyzer to get started.

Prerequisites

  • Have an AWS Organization with a Security Audit account.

The Lesson

Spend too much time with a crusty old security graybeard and he or she (okay, most of the shes lack the beard part, but you get me) will regale you with phrases like “defense in depth”, “DMZ”, and “egress perimeter consolidation”. In case you didn't already know, most of the information security profession started with network security, and for many practitioners that’s still their primary focus. And there’s nothing wrong with that; network security is difficult and complex, especially at scale, and only gets harder as we move more into cloud and containers.

But if you really think about it, our focus on network security isn’t about the network itself, but about protecting systems and data on networks. Put it this way: we don’t call the professions information security and information technology for nothing. Network security is a cornerstone, but we have more than one corner (don’t make me count the corners, please).

As we move to cloud we are learning that public cloud creates some new, intertwined perimeters. Why? Because the entire management plane and all our stuff is hosted on the Internet, not behind a set of firewalls in a datacenter we could disconnect from the world by pulling a few cables.

In previous labs I talked about the IAM perimeter, which is a great way to describe the problem of preventing attackers from accessing management plane credentials (including system credentials) to break into our deployments. I hinted at a related concept: the data perimeter — which defines how data can be accessed in the cloud, and includes predominantly IAM and network permissions.

The Data Perimeter

I first heard about the data perimeter concept from a friend of mine I’ll just refer to as “H”. He’s another long-time hard-core cloud security pro who has had to work in thorny environments with high stakes. Since those early days of our discussions it’s become a concept AWS talks about, defines, and teaches more broadly. Their succinct definition nails it:

A data perimeter is a set of permissions guardrails in your AWS environment you use to help ensure that only your trusted identities are accessing trusted resources from expected networks. Data perimeter guardrails are meant to serve as always-on boundaries to help protect your data across a broad set of AWS accounts and resources.

Think of a data perimeter as a set of interlocking security controls to define who, where, and how cloud data can be accessed. This includes API calls, network access, and any other potential sharing (like those archaic S3 ACLs).

We have already completed quite a few labs laying down the foundation of a data perimeter:

  • Service Control Policies

  • VPC Endpoint Policies (although so far we have covered endpoints but not policies)

  • Resource Control Policies

Why not resource-based policies and IAM policies? Because a data perimeter applies to your entire organization, and those policies are limited to specific resources. It’s the shields around the Enterprise, not those wimpy personal shields around individuals from Dune.

While you’ve learned the concepts, we barely touched on how to build the data perimeter… and we won’t be doing that today.

Instead we will start on detection. When I go into a new organization which needs AWS security help, this is where I always start. Because if I start with prevention… I break things. Like, badly. One of my goals for these labs is to teach you how to build a data perimeter — but while it will be easier to create in our nice, fresh CloudSLAW organization, implementation in existing environments is considerably harder.

Access Analyzer

AWS provides a great tool to help figure out data exposures, and we can use this detection to drive remediation and prevention. IAM Access Analyzer includes a handful of features for evaluating IAM policies and access, including resource-based policies. They include (copy/paste from the documentation):

Today we will configure external Access Analyzers. These are free and a powerful tool to detect both public exposure and sharing to untrusted AWS accounts. Access Analyzer doesn’t cover every possible resource; but its solid coverage includes the major ones like S3, IAM roles, Lambda functions, KMS encryption keys, and various databases.

All the features are interesting, but I find external analyzers to be most important so thus we’ll start there. A few important points:

  • Access Analyzer supports delegated administration, which we will configure for our Security Audit account.

  • Access Analyzer works with a concept known as “zones of trust”, and detects sharing outside those. For our labs we will set one up as our entire organization, but in real life you might find you want to narrow things down.

  • Security Hub picks up any Access Analyzers alerts, and we already have that configured to send them as emails. Kind of cool how this all wires together.

  • Access Analyzer tries to detect an external share within about 30 minutes of the change that caused it, but that relies on CloudTrail and isn’t 100% reliable due to the complexity. It also runs a daily sweep to catch what it missed, but this means you can’t rely on it as a real-time exposure tool.

Key Lesson Points

  • A “data perimeter” is how we ensure only the right people and things access the resources we want from locations we want.

  • While Access Analyzer doesn’t create a data perimeter, it helps us find where and how our resources are being shared, which is an important first step.

The Lab

Today we will:

  • Delegate administration to our Security Audit account

  • Enable Access Analyzer

  • See if it detects our public S3 buckets

    • BTW: some of you probably already received GuardDuty alerts for creating public buckets. When it comes to public buckets, the more alerts the better!

Video Walkthrough

Step-by-Step

We’ll start at our Sign-in portal > CloudSLAW (your management account) > AdministratorAccess. Then go to Access Analyzer (this is a feature of IAM, but you can skip directly to it using search):

Then go to Analyzer settings > Add delegated administrator:

You’ll need the account ID for your SecurityAudit account. It’s easy to get from the sign-in portal tab which should still be open. Switch tabs > SecurityAudit > Copy the ID > Switch back to the Access Analyzer tab:

Paste in the account ID and Save changes:

That’s it for the management account, so close the tab:

Then switch over to your SecurityAudit account with AdministratorAccess > Access Analyzer > Create analyzer. Remember, the SecurityAudit account can now administer Access Analyzer for the entire organization. Also confirm you are in the us-west-2 (Oregon) region:

It will default to the settings we want:

  • External access analysis (which is free!)

  • Current organization

  • Leave the default name

Then Create analyzer:

NOW CHANGE REGIONS TO VIRGINIA (US-EAST-1) AND CONFIGURE AN ANALYZER THERE WITH THE SAME DEFAULTS!!!

Access Analyzer is a regional service, even though IAM is a global service. We restricted all regions except Oregon and Virginia. One important point is that when I create a new organization I use automation to deploy Access Analyzer (and GuardDuty and a few other services) in every region before I locke them down. That way if someone turns them on later, I still get alerts.

Everything is running so let’s see our results. Go back to Oregon > Access Analyzer and then go to External access:

Cool, eh? If you don’t have results, wait 5 minutes and refresh. Notice how my public buckets show up? Even though one is a bucket policy and the other an ACL?

Access Analyzer uses Amazon’s advanced automated reasoning technology to figure out exposures, and does so across all the different policy types. Yeah, it’s a version of AI, but don’t call it that.

All those other findings? Those are ranked as low priority because we have IAM Identity Center set up. I was surprised to see them since they are all within the scope of my organization. Possibly because federation could technically be linked from an outside identity provider.

One last thing: go check your email. Odds are Security Hub has already forwarded over the alerts. Here’s mine, just dumped into a tool to make the JSON legible:

From now on every time you make a protected resource public, or share it with an account outside your organization, you’ll get an alert.

This data perimeter lacks enforcement, but it’s a wonderful way to find exposures until we put defenses in place. And even then, most data perimeters need some exceptions for things which should be public, which Access Analyzer helps you track.

Lab Key Points

  • Use delegated administration for Access Analyzer. This is one of the services you should send to your SecurityAudit account.

  • Access Analyzer is a regional service, and so needs to be enabled in each region in use (or all of them!)

  • Access Analyzer uses automated reasoning and looks at all your combined resource and IAM policies (including RCPs and SCPs) to identify exposures.

  • You can define your own Zone of Trust. The default is your Organization.

-Rich

Reply

or to participate.