We’re doing a fair number of cloud security assessments. This post will talk a bit about what we have found and some common ideas that seem to apply across them.

Cloud Security Assessment Process

When we do work with a client to help them secure their cloud environment, let’s just talk about AWS for now, the process looks something like this:

  1. Client provisions us a security-audit role that we can assume via STS
  2. We set up a profile for the client in aws-vault
  3. We run tools like our own app.jasp.cloud tool, Scout Suite, Prowler, etc.
  4. We run command line checks to ask questions
  5. We draw diagrams in LucidCharts
  6. We produce a backlog of work that needs to get done
  7. We help coach a client’s existing resources around the tasks
  8. In some cases we help the client do the work that needs to get done
  9. We leave the client with interim access to our JASP tool so that they can track improvements, regressions or new problems

As a general rule, we’re trying to stay away from writing reports because those tend to be time consuming to write and not particularly easy to read. Instead, we deliver through JASP or GitHub issues.

In the Real World

IAM is Hard

In the real world, IAM is really hard. Understanding what roles and profiles exist is foundational to building out any kind of secure environment. Sadly, this is different from company to company and that makes it complicated to talk about or set baseline expectations around.

A couple of important things:

  • Understand and use STS
  • Build appropriate roles and profiles (maybe more fine grained than you initially want)
  • Audit via CloudTrail
  • Don’t use access keys from apps
  • Certainly don’t use root access keys from apps
  • Use Orgs and Accounts to get strong separation (eg. we use an account for Prod, not just a VPC)
  • Consider having a Security account
  • Run the IAM Credential report and handle results

CloudTrail Is Rarely Fully Utilized

Many AWS services can easily integrate with CloudTrail. Sadly, this is often not the way people do it. Often we see theoretical integration with a SEIM via a Syslog based logging system then forwarding to the actual SEIM. That’s not bad per se, but where you can, use CloudTrail.

For example, use CloudTrail for tracking:

  • Changes to IAM
  • KMS key usage
  • etc.

GuardDuty and Security Hub

Many teams we have worked with were not aware of GuardDuty. While the utility may be overstated, i.e. I personally don’t buy that this is equivalent to an IDS, it is a legimately useful tool for identifying strange behavior. Turn it on and you can get a feel for a baseline of certain types of events. Also, it is fairly easy to manage.

Inspector

Most teams are not familiar with or running inspector either. In their defense, some can’t very easily. If they are running Docker images for example, we don’t see it being realistic to run Inspector on these.

Also, Inspector is like GuardDuty where you may or may not get everything you think you’re getting. But its support for CIS and some level of host based checking is a solid control to add to the arsenal.

We recommend using this particularly in sensitive environments (as segmented by network or account).

Networking

Speaking of segmentation, we often don’t see proper segmentation even at a network level. The idea here is to clearly segment areas of your network so that you can define scope. The segments might correspond to business functions, application environmens, stages in a pipeline (dev / stage / prod). They might include different VPC’s for very sensitive data. One of the great things about cloud environments is that you can just use another VPC!

Again, we also see benefits to doing this type of segmentation at the account level but at the very least we would want to see VPC level segmentation.

Beyond that, it is advisable to use a WAF, VPC Flow Logs and Guard Duty but we often don’t see these.

Backups and Replication

Many people we talk to believe that their backups and failover are going to be automatic.

In some cases and senses that is true, but probably not in the sense they really mean. How are your S3 buckets or RDS instances really available in another availability zone or region if AWS has an issue? Are you making backups to Glacier?

Config

AWS Config is a useful tool for tracking and optionally checking the security of certain core configurations. The cost to run the checks seems quite high in some cases, so often this is not used. Our JASP tool provides simialar types of checks for a much lower cost. Still, if your budget allows, by all means, run AWS Config with the checks enabled.

S3

The classic AWS mistake is to put sensitive information in a public S3 bucket. I would go so far as to consider writing automated checks that will verify that your S3 buckets look the way you expect. We have written tests like this with Gingko and Go tools.

Many tools will report about public or otherwise misconfigured buckets. Use these, but be prepared for the cases where the buckets are intentionally public.

Conclusion

There is so much to learn with the cloud and with vendors like AWS releasing new security features and other services at a rapid pace, it can be overwhelming to configure your environments in a reasonable way. At the same time, engineering teams are trying to keep pace with their feature requests and deadlines. This post tried to at least mention some common issues and capture some of the easier and simpler items that can be addressed generally. Enjoy and reach out if you have questions or feedback.

Matt Konda

Matt is a software engineer. He's our CEO and former Chair & OWASP Board Member.

Want to stay up to date with the lastest from Jemurai?

Sign up for our monthly newsletter!