Risk Manager helps operations, security, and compliance teams to detect when their cloud environments drift out of policy, and (optionally) automatically remediate these drift events when they occur. This reduces the Mean Time to Remediation (MTTR) for cloud misconfiguration exposures and saves a lot of time otherwise spent on a game of Whack-a-Mole dealing with infrastructure drift.
But today, let’s take a look at a different use case. This is typically the first use case for our customers: scanning cloud environments, discovering what resources they have running, and identifying any compliance violations. If you’re already operating on cloud at scale, this is the logical place to start with Risk Manager.
Scanning an AWS Account
Once you’ve created your Risk Manager account, you’ll need to point it at one of your AWS accounts in order to scan it. There are full instructions for setup here. For this use case, Risk Manager only requires read-only access.
The first thing we want to do is select one or more policy frameworks that we want to validate our AWS environment against. Currently, Risk Manager provides validations for HIPAA, GDPR, NIST 800-53 rev. 4, and the AWS CIS Benchmarks.
Now you’re ready to scan your environment, which produces a report like this:
Understanding your AWS Compliance Posture
Ok, so what’s really going on here?
If you drill into any of these standards, you’ll find that they cover a long list of requirements or best practices. The AWS Foundations Benchmark (CIS), for example, has a host of standards for things ranging from Docker to Android to Microsoft Office. These standards for AWS are 158 pages long and offer very specific directives, like “Ensure no security groups allow ingress from 0.0.0.0/0 to port 3389” or “Ensure rotation for customer created CMKs is enabled”. Each of these directives is well detailed, with instructions on how to check its status.
Sure, you could apply these standards by hand if you are willing to put in the time and effort. You can march through the checklist, testing each item, ultimately completing an audit of your AWS environment for CIS compliance. It won’t be a lot of fun, and it’ll take a long time. Of course, if you change your environment, then you get to do it again. Rinse. Repeat.
This seems like something that you should be able to automate. And the good news is, it is.
Risk Manager automatically runs through the checklist for the AWS CIS Benchmarks (and other standards, like GDPR, HIPAA, and NIST 800-53) for every infrastructure resource in your environment. It identifies violations and provides you information on how to fix it.
So for example, let’s look at CIS-1.16
1.16 - Ensure IAM policies are attached only to groups or roles
This is a pretty straightforward rule. Assigning IAM policies to roles and groups makes user management more straightforward and secure since you don’t need to worry about Doug, the new sysadmin, inadvertently getting permission to make an S3 bucket public. Doug’s a nice guy and wouldn’t do such a thing on purpose, but we don’t want to be exposed should Doug’s credentials get compromised.
So, Risk Manager sweeps for this. Under the hood, it’s running a command to get a list of IAM users and checking if any of them have roles attached. If it finds some, then Risk Manager will report something like this:
Click through and you get a breakdown of all the issues:
You have a clear, actionable list, and with a few fixes, you can bring your whole infrastructure into compliance.
But how can we make sure it stays that way and never drifts out of compliance? In the next post, we’ll show you how you can establish a known-good infrastructure baseline, detect for drift, and optionally enable baseline enforcement to automatically remediate drift when it occurs.