Approaching Least Privilege – IAM Policies with Usage-Based Analytics

By Luke Synnestvedt, Sr. Associate at PwC
By Harry Lu, Sr. Manager at PwC
By Nitesh Dhanjani, Principal at PwC

It seems that every organization has either fully adopted a DevOps/Agile deployment model these days, or has strongly considered adopting one.

The DevOps train is not only coming down the tracks, it’s accelerating and brings with it an opportunity to rethink the way security teams have traditionally certified access.

Amazon Web Services (AWS) customers are increasingly searching for new ways to manage access on AWS in a scalable way that maintains the benefits of an agile DevOps delivery model.

CISOs and AWS security managers face increased pressure to “prove” adherence to the principle of least privilege and may turn to their on-premises Identity and Access Management (IAM) security functions to help solve these problems.

However, the traditional and highly-manual processes for assessing and certifying access quickly demonstrates they cannot keep up with the speed of DevOps changes.

The methodology described in this post assumes your organization supports agile development principles, permits application teams to manage their own AWS policies, and deploys its applications using a CI/CD pipeline. This post explores how to design and implement baseline IAM roles, and leverage usage-based analytics to identify overprivileged roles.

PwC, an AWS Advanced Consulting Partner, helps its clients with various types of cloud transformation initiatives, including designing, engineering, and securing their workloads.

Designated as an AWS Security Competency Partner, PwC has had the opportunity to help design and secure AWS platforms for clients across the Fortune 500 portfolio, including organizations in healthcare, transportation, and financial services.

IAM Roles in a DevOps World

In a typical DevOps model, application engineers are trusted to design and implement their own IAM roles to enable their application to function.

Consider two very different types of access: the access the engineer maintains, and the access the application role is given (which will be called “machine roles” for the sake of this post).

Engineer Access

AWS best practices state that engineers should be members of groups which grant them their IAM policies (or through Active Directory role-mapping). These policies are responsible for defining least privilege for application engineers and may vary from environment to environment.

• DEV: Engineers should be given privileges in order to deploy, test, and tear down resources. So long as these development environments remain free of production data and aren’t ever connected to environments with production data, these roles should begin from a position of strong privileges.
  .
  Providing engineers a strongly-permissive set of permissions can prevent app teams from seeking to create shadow-IT accounts to circumvent security controls.
  .
• QA and PROD: As a guiding principle, engineer permissions within QA and PROD accounts (environments) should be limited to read-only. This is due to the principle of separation of duties where the designer and engineer of an application should not also be the one changing that application.
  .
  Establishing your environment using a continuous integration model supports this access model by ensuring developers are only capable of deploying changes through peer-approved code changes. Any changes that need to be made within the QA and PROD environments should require an approved change request and temporary escalation of privileges.
  .
  Engineer roles in QA and PROD should provide read-only access (which should not include issuing get calls to data within storage services)

Machine Role Access

These roles should be granted the permissions needed to communicate with other AWS services and nothing more, according to the principle of least privilege. Any permissions beyond these may inadvertently allow a malicious actor to exploit the extra permissions for an attack.

Keeping this in mind, when designing Machine Roles, “begin” by defining an IAM policy which permits your application to function in DEV.

Before moving it to QA for testing purposes, here’s a few more things to do first:

• Services: Remove AWS services from the policy if they will not be called by this policy.
• Actions: Only allow Actions as needed (for example, does your app need s3:* or just s3:PutObject?)
• Resources: Could these actions be limited to a subset of resources? A single resource? Consider the use of IAM Policy Variables and Tags to benefit from the use of resource tag references rather than exact resource names within IAM policies. The use of tags may enable more agile provisioning of access to resources based on the specific tags your organization has adopted (for example, cost center or project). Note the use of tags requires an enforced tagging strategy to be effective.

Least Privilege as a Principle, Not a Blocker

The term “begin” was intentionally bolded in the above explanations because as security professionals it’s important to understand the principle of least privilege is just that—a security principle often required by industry controls but which may never be economically feasible to achieve.

Least privilege role design means any given IAM policy should only permit the actions which a user or application will:

1. Actually use within its access period, and;
2. Are permitted to use the actions as defined by their role or company policy.

The security team’s role in the DevOps world is to enable developers to do their jobs within the guardrails of what’s acceptable and with the tools needed to make secure design decisions. With that in mind, how can traditional access review services be automated and integrated within a DevOps Pipeline?

Usage-Based Least Privilege Design

In order to understand what a role should be allowed to do, first look at what the role has done. This is the thinking which drives Usage-Based Least Privilege Design.

Using AWS CloudTrail and a defined period of time, catalogue which API actions have been taken by a role. Compare that to the list of actions which could have been used. The difference between these two inventories is the least privilege gap.

Use the following framework as a guide when querying CloudTrail with Amazon Athena or similar log analysis tool:

• Identify the in-scope log sources.
• Identify the in-scope IAM roles and narrow the log query to these roles.
• Enumerate and catalog the API permissions granted to these roles (consider importing the information into Amazon DynamoDB or a similar AWS database service).
  • You may consider starting this inventory at the service level. As your organization matures, expand the inventory to be more granular (for example, at the API permission level)
• Define a window for privilege usage analysis (30 days, for example).
• Record the API actions taken using the IAM role.
• Identify gaps between API permissions granted against used.

Figure 1 – The Least Privilege Gap.

Just as above, consider options to remediate this gap in different ways depending on what type of access is under review.

Machine Role Access

Machine roles are often simpler to design for least privilege than engineer roles, given the scope of actions needed by a machine role are often minimal. Engineers should deploy new roles into a development environment to validate the role allows the application to function.

Once deployed to QA, review the API Actions taken by the role using CloudTrail as your data source. The API calls made within the logs represent the only permissions which should be allowed within the IAM policy on this role.

Engineer Access

Engineer access is a bit harder to assess given that engineers gain their privileges through their assigned IAM or AD group. The actions a single engineer uses will not be the same actions another engineer needs.

To address this, leverage a process to define roles for groups similar to the following steps:

• Group Users by Business Function: Based on your team structure, define groups based on the various roles of the team (app engineers, infra engineers, app managers, QA, PROD operations, security).
  .
• Define and Apply Explicit Denies: Based on your company’s policies, approved AWS services, and risk appetite, define a baseline deny policy which should be applied to all engineer roles or groups. Consider denies such as IAM actions, banned services, and banned regions.
  .
  For Well-Architected AWS account structures, consider the use of the Service Control Policy (SCP) to baseline-deny all services, and only allow services through a formal approval process.
  .
• Select AWS-Managed Policies: Begin by selecting a single or combination of AWS-managed policies for each defined user group based on the group’s defined job description. The first release of these groups may be overprivileged, but will allow your teams to begin accessing the platform.
  .
  The data generated during this access period will inform future least-privilege decisions. (Remember, read only policies in QA and PROD).
  .
  • For example, the first iteration of user groups may consist of:
    • Admins: Responsible for managing the AWS Organization, IAM services, and account level controls.
    • Developers: Granted broad permissions across AWS services in the DEV environment, but lacking the ability to modify IAM roles, policies, and permissions.
    • Read Only/Audit: Given read access to AWS services, but not the data stored in storage services.
      .
• Monitor API Usage: Over a defined period of time (as determined by your security organization), catalogue the services and actions used by your engineers. This inventory should include at least the following to help drive conversations:

Figure 2 – Sample role usage inventory.

• Design and Apply New IAM Policies: Using this inventory, design new policies and assign them to new roles (or groups). For example, the Admin group described above may be separated into Platform Admin and IAM Admin groups, while the Developer Group may become the Infrastructure Developer and Application Developer groups.
  .
  Collaborate with a target application team to test the new roles, still permitting use of the old role as needed to solve for errors in permissions. Refine policies based on engineer feedback, and challenge feedback to determine if an action should be considered routine or privileged (to be included in temporary access roles).
  .
  Additionally, consider bucketing high-risk permissions into new groups which may require additional access requests and approvals (for example, a developer seeking data-read-access to their application’s storage services).

Conclusion

As AWS customers continue to adopt DevOps methodologies and the responsibility for implementing security shifts left to application engineers, security teams should seek to capitalize on opportunities to automate traditional security activities to scale with their development teams.

Through early partnership and with a usage-based approach to least privilege, application teams will be able to continuously secure their IAM policies and approach the principle of least privilege within their AWS environment.

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

.

.

PwC – AWS Partner Spotlight

PwC is an AWS Competency Partner that helps customers drive innovation throughout IT and the business to compete in today’s service economy.

Contact PwC | Practice Overview

*Already worked with PwC? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.