Show your Tool: Parliament

In this series, we present AWS tooling from the community for the community. We talk directly with the tool makers. Who are they? What problem does the tool solve? And what motivates them to contribute to open-source AWS tooling.

This time, we talk with Scott Piper about Parliament. You can connect with Scott on Twitter or LinkedIn.

cloudonaut: Tell us a little about yourself, your history with AWS, and your motivation to develop AWS tooling.
Scott Piper: My history with AWS didn’t really start until a little over three years ago, when I released flaws.cloud, which is a free CTF of sorts, that I built to teach myself and the DevOps folks at the company I was with, about AWS security. I released it publicly and thought that if I got lucky, maybe a dozen people would check it out. Instead, in the first month 30,000 people tried it out and it has continued to be a popular site for learning about AWS security in a hands-on way. And it continues to be relevant! One of the levels (again, this was created three years ago) is nearly the exact same as the scenario that resulted in the Capital One breach a few months ago.

As a result of the popularity of flaws.cloud and some other things, I decided to start a consulting business focused on AWS security. I was lucky enough to be able to work with Duo Security with whom I developed CloudMapper, CloudTracker, Parliament, and some other things.

The tools I’ve developed have largely been the result of working with clients and identifying problems they had for which there weren’t any existing solutions for. Recently, I shifted my business to focusing on providing AWS security training privately to companies, but I’ll continue building tools as a result of conversations with these companies and as a great way for me personally to learn and stay on the leading edge of AWS security.

cloudonaut: What problem does your tool solve?
Scott Piper: Parliament is a linter for AWS IAM policy policies. What this means is that the JSON document you write to define the privileges and access someone has on AWS can have spelling mistakes and other problems in it, but will still be valid (ie. it will still save), so a tool was needed to check for these problems.

I had started monitoring the changes that AWS was making to their managed IAM policies and noticed that every once in a while they would make a correction to what had been a mistake in a policy. For example, a common problem was using “s3:ListBuckets” (which is the name of an API) instead of the correct name for the privilege “s3:ListAllMyBuckets”. I then manually reviewed every single AWS managed IAM policy by hand to try to find every possible mistake they had made. I found a lot of mistakes (and missed a lot as I later realized), and reported those in.

I figured there were a couple of common types of mistakes that even AWS was making so customers had to be making even more mistakes, and I should build a tool to find these. Since then, the tool has continued to evolve from finding what are basically spelling mistakes to looking for privilege escalations and the ability to create custom auditors to identify concerns that are specific to a customer’s environment, such as which policies grant access to a specific sensitive bucket.

cloudonaut: Who should use your tool? Who should not?
Scott Piper: Anyone using AWS who wants to review their IAM policies should use this tool. Parliament exists as a stand-alone tool and also as a library. If you build a tool that does any sort of auditing and checking of AWS, or anything related to IAM, you should integrate Parliament into it.

cloudonaut: Show us a short demo of your tool
Scott Piper: As a simple example, create a file with the following IAM policy:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::mybucket"
  }
}

Pass this to Parliament, and you’ll get the following output:

$ parliament --file test.json
MEDIUM - No resources match for the given action -  - [{'action': 's3:GetObject', 'required_format': 'arn:*:s3:::*/*'}] - {'actions': ['s3:GetObject'], 'filepath': 'test.json'}

The reason for this finding is that s3:GetObject requires a resource that refers to S3 objects (it should have a “/“ in it), whereas the resource given refers to an S3 bucket. As a result, this policy actually doesn’t grant any privileges because of the mismatch.

cloudonaut: How can we use your tool
Scott Piper: pip install parliament

cloudonaut: Where can we find more information about your tool?
Scott Piper: https://github.com/duo-labs/parliament

cloudonaut: Are you aware of tools that solve a similar problem than yours? What’s the difference?
Scott Piper: A few tools, such as the CloudFormation linter cfn-python-lint, have some ability to spot misspelled actions used in an IAM policy, but there are no open-source (or vendor) tools that are as in-depth as Parliament. For example, Parliament can also identify when a Condition is used that does not make sense for the given actions. That’s a much harder problem and requires a more in-depth data set of knowledge than any other tool uses. To get that data, I had to write a scraper for the IAM docs and have worked with the AWS security team, reporting over a hundred issues that no other tool was capable of finding in AWS’s own policies, in their docs, and elsewhere.

The AWS web console does have some advanced abilities to spot problems in IAM policies, but you have to click through the web UI to see these, and can’t extract that ability out into a stand-alone tool or library like Parliament.

cloudonaut: What’s the roadmap for your tool? Are you planning any significant releases?
Scott Piper: I have been working with Kinnaird McQuade from Salesforce’s security team, who developed Policy Sentry, to integrate some of the functionality from that tool into Parliament. Specifically, Kinnaird is an active user of Parliament’s ability to create custom auditors, so we will be integrating in his work that detects various high risk privileges into Parliament.

cloudonaut: How do you stay motivated to maintain your open source project?
Scott Piper: I’ve been lucky a few times to have had contract work that directly involved my open-source projects, either building them in the first place, or adding functionality to them. If given the choice between doing a thing that privately helps one company, or doing a thing that can be released publicly to help lot’s of companies in addition to the one paying me, I’m going to choose the latter contract. My clients like working with me because of that. They know that I’m genuinely trying to help improve security for everyone.

It also helps me learn. I know so much more about how IAM works now because of building Parliament, I know how people use IAM policies because of public Github issues and private conversations that resulted from people using it, and I have a good relationship with a few people at AWS that have opened up back channels for me to have discussions with them and make requests for things from them, that I wouldn’t have been able to by not doing this public work.

cloudonaut: Are you attending any conferences within the next few months where the community can get in touch?
Scott Piper: I’m actually one of the organizers of fwd:cloudsec, which is a new, not-for-profit, cloud security conference taking place in Houston, Texas, the day before re:Inforce on June 29. There are a half dozen organizers from various companies and industries that are working to put it together. We’ve already had a lot of interest from some of the top people in cloud security who want to speak at it, so we’re really excited about it.

–

What tools do you use to make your AWS work easier? Share your favorite tool with us!