SBN

Keep Your IAM Users Close, Keep Your Third Parties Even Closer – Part 1

Technical and legal controls that you take for granted when managing cybersecurity policy within your organization are usually out of reach when a third party is compromised.

Many scenarios call for providing access to your AWS environment by services and/or users outside your organization. This is the case for entities not represented by IAM Users or IAM Roles in an AWS account that your organization controls and aren’t managed through federation by an identity provider such as Okta or OneLogin. Typically, these entities are software services requiring access ranging from read-only to granularly defined actions—and even administrative access to specific or considerable parts of the environment.

AWS provides two main mechanisms for handling such a situation:

  • Programmatic access, for authenticating an IAM User using an access key and secret. This approach enables external access to any entity with which these secrets are shared.
  • An alternative mechanism, which AWS strongly argues for, that allows external accounts to assume (and delegate the ability to assume) a role within an AWS account and use the permissions granted that role.

From a security perspective, allowing access to third parties literally opens up AWS accounts to significant risks if not managed properly. A very cool table-top exercise recently tweeted by Matt Fuller illustrates how an attacker can use a mechanism allowing third-party access to create a beachhead to your environment.

In the first part of this two-part blog series, we will review how third-party access is configured and controlled, and how it can go sideways — that is, create undue risk to your organization. In the second part, we’ll explore best practices for protecting against third-party access risk and how automated analysis can help you control this extremely sensitive aspect of identity and access management.

Third-Party Access – How It’s Done

Probably the most straightforward way to give an entity—including a third party—access to perform actions and retrieve information from your AWS account is to do so programmatically. You do so by creating an IAM User and enabling the use of an access key:

Configuring an Access Key for a dedicated or third-party IAM User

Figure 1 – Configuring an Access Key for a dedicated or third-party IAM User

These credentials can be used for a variety of clients and use cases by just about anyone. Some, but not all, third parties support this method. In any case, AWS advocates an alternative approach: letting the third party assume an IAM Role that considers the third party’s AWS account to be a trusted entity. You configure this fairly easily by creating a new role and specifying that it be trusted by an external AWS account:

Configuring an IAM Role for external access

Figure 2 – Configuring an IAM Role for external access

Note that in Figure 2 we’ve also checked the External ID option; this is a string coordinated between the AWS and third-party account that restricts access to those using the role. External ID is a very important security feature that we will delve into later. Find more information about giving access to AWS accounts owned by third parties in the AWS documentation.

Creating an IAM Role for external access eventually configures a trust relationship that looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<3RD_PARTY_ACCOUNT_ID>:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<EXTERNAL_ID>"
        }
      }
    }
  ]
}

Listing “Principal” as the root user is a little misleading: one might be lured into thinking that only the root user can assume the role and use the permissions granted it. However, assigning the principal as root user actually allows the account to delegate the assumption of the role to any other principal within the external account.

Specifically, the mechanism works by— using the AWS Security Token Service (STS)—allowing the trusted entity to receive temporary credentials that the third party will use to perform actions. The fact that the credentials are temporary is a security benefit. In addition, unlike access and secret keys, which can be held insecurely and fall into the wrong hands, no secret sharing with the third party takes place.

To work with the role, the third party is required to get: the Role’s ARN, the External ID (if used, as recommended) and, of course, the AWS Account ID. None of these values is considered a secret—although they shouldn’t be advertised anywhere public. That secrets are not needed to configure the access to the AWS account is itself a security issue that we will also look at later.

Why Third-Party Access Is Sensitive

Almost by definition, allowing an external entity to access resources is an extremely sensitive action. Granting access to a third party in the context of an AWS account is no different. Let’s review some reasons why.

Delegating control

As mentioned, when you are setting up a trust relationship with an account, the root user is not the only user allowed to assume the role that grants access. Allowing the root user to assume the role means that an IAM policy can be configured in that external account to allow any user or role to assume the role. This can happen with no further allowance from the AWS account that allowed the delegation to the root user of the external account.

A much better practice is to allow only a specific user or role to assume the role. That said, the control still remains in the hands of the person managing the external account. Even if only a specific role in the external account can assume the role in your AWS account, the person managing the external account can allow anyone within the external account to assume it—thus giving them access to it. Even if you only allow a specific user to have access, programmatic credentials enable access that can be shared with literally anyone, as noted earlier.

Third parties are (also) prone to being compromised

The SolarWinds breach showed how devastating a compromise of a vendor can be to a whole roster of clients. While that hack has mostly on-prem implications, we’ve shown how it can also impact an affected organization’s cloud infrastructure.

The point is that whether it’s an external bad actor that gains control of a third party or an insider threat, third parties are, like your organization, prone to getting hacked. The real trouble is that, in the case of third parties, the tools at your disposal to prevent attack via a third party—whether detecting it or handling it once you are aware of it—are much more limited. Technical and legal controls that you take for granted when managing cybersecurity policy within your organization are usually out of reach when a third party is the source of the compromise. For this reason, being extra careful with the permissions granted third parties in the first place is especially important.

Third parties (also) make mistakes

Finally, even if we’re not talking about actions originating from malice by the third party or someone seeking to harm it, third parties can make mistakes like everyone else, as well as design and operate systems that malfunction. The difference in intent doesn’t make the resulting damage less significant.

For example, if you provide a third party with permission to spin up EC2 instances and they use it by mistake to generate massive amounts of computing resources, your bill will increase just as if done by an attacker looking to mine bitcoin. Alternatively, if you provide a third party with access to terminate EC2 instances and by mistake they shut down some which are mission critical at just the wrong time, the impact to your business will be just as significant as that of a hack designed to perform this on purpose.

***

Check out Part 2 in this series, which presents best practices and describes how automated analysis can help you keep tight control over third party access to your AWS account.

The post Keep Your IAM Users Close, Keep Your Third Parties Even Closer – Part 1 appeared first on Ermetic.

*** This is a Security Bloggers Network syndicated blog from Ermetic authored by Ermetic Team. Read the original post at: https://ermetic.com/whats-new/blog/keep-your-iam-users-close-keep-your-third-parties-even-closer-part-1/