Repokid and Beyond: AWS Least Privilege, Gift-Wrapped

In 2017, I started a two year professional stint working on Repokid, an open source project that automates privilege rightsizing in AWS. Security teams have always been really busy with a seemingly infinite list of things that need to be locked down or automated, so why did we choose to invest so much in automating least privilege? According to the latest Verizon DBIR report, more than 70% of breaches involved privilege abuse. Although least privilege is highly impactful, it is very hard to achieve without automation. In this post, I’ll take a look at why least privilege is so hard to achieve and how the automated approach works.

Least privilege policies require a deep understanding of what a principal (typically a user or application) should do. In most cases, the applications developer (or user themselves) has the best knowledge. Let's introduce a developer, Imani, who is building a new application called “Security Alerter” that parses incoming log files from a S3 bucket, transforms the event, and drops them in another bucket. Imani knows that she needs access to read and write from S3 but does not know how to construct the least privilege IAM policy.

From Intent to Policy

Translating developer intent into a working AWS IAM policy can be daunting. As of today, there are 258 AWS services and 9286 total permissions, for an average of 35.99 permissions per service. If you know what you are doing, you can grant the exact permissions necessary to accomplish a task. For developers who don't spend much time writing IAM policies, it can be difficult to know whether “S3:PubObject” will work, or if “S3:PutObjectVersionAcl” is the correct permission. Sometimes this confusion leads to trying a lot of permissions before stumbling on the right set, and sometimes people understandably give up and add “S3:Put*” or “S3:*” to their policy.

An ideal solution would allow developers to effortlessly create right-sized policies without learning about IAM syntax. Repokid enables this approach by observing which permissions are used by developers and removing the permissions that are not used. In the previous example, Imani receives default permissions during application creation and over time, the policy converges on the exact permissions used. New permissions can be added by cloud security teams or even granted by self-service tools such as the Netflix OSS ConsoleMe. This system works well because once an application stops being used (and exercising its permissions), the unused permissions are automatically removed.

Policy Build Up

Other open source solutions like Policy Sentry and Cloud Tracker approach the problem from the other side, allowing you to easily build up correct policies without much knowledge of IAM. AWS also recently released IAM Access Analyzer to automatically generate policies based on Cloud Trail logs. Unfortunately, automatically building policies from Cloud Trail isn’t a complete solution because many actions are still not logged, so policies generated this way may miss vital permissions.

The High Bar of Operationalizing Least Privilege

Even with all these great tools, organizations still have a relatively high bar to operationalize least privilege policies. Running open source requires software engineers to learn how the software works well enough to answer questions about it, perform updates, and troubleshoot when issues come up. I joined Ermetic as an advisor because I believe companies want to buy this capability as a nicely packaged service.

In addition to top-notch least privilege automation, Ermetic leverages deep integration with cloud environments to provide essential security capabilities including:

• asset inventory/change management
• cloud security posture management
• additional context via deep integration with an identity provider
• anomaly detection
• multi cloud support

Today, there are many solutions for easily achieving least privilege that didn't exist when we started working on Repokid. For any organization that has not yet achieved automated least privilege, now is the time!

***

Travis McPeak is the Head of Product Security at Databricks and has held senior cybersecurity management roles at Netflix, IBM, HP, and Symantec. He has served as the developer lead for Repokid, an automated approach to least privilege, and Bandit, a linter to find Python security bugs. In his spare time, Travis leads the Bay Area OWASP Chapter and advises startups.