P0’s Security Features for AWS

Installing our integration

Before I dive into our security model, let’s understand how our integration works.

To install the integration, we ask you to run AWS commands that: create an IAM Role, create a trust relationship that allows P0’s service account to act as this role, and bind an IAM policy (which allows P0 to read and edit your account’s IAM) to this role. The P0 service account resides in P0’s own environment.

The AWS IAM policy allows P0 to:

‍

• Create and assign identity policies, and list users, role tags and rolessome text
  • List Roles, Policies, Users, User Tags, Role Policy, Attached Role Policies, Attached User Policies, Policy Versions
  • Get Role, Policy Version
  • Add a user to a group
  • Attach Role Policy,  User Policy
  • Detach Role Policy, User Policy
  • Delete Role, Policy, Policy Version
  • Remove User from group

The AWS IAM policy also:

• Denies P0 from assuming or attaching more policies to itself

The P0 IAM role also has a preconfigured trust relationship that blocks any identity other than the P0 service account from assuming the P0 role.

‍

These permissions are necessary for the core functionality of our tool: Reading and setting IAM identity-based policies is necessary for provisioning access for users.

Attack Vectors

When providing this level of IAM access to a third-party, a key concern is whether the permissions can be abused by malicious actors in a manner that allows them to gain access to your environment.

‍

There are several potential attack vectors to consider:

• A user in your organization is able to assume P0’s role to escalate their own privileges outside of the tool.

• A user in your organization is able to hijack P0’s policy to escalate their own privileges outside of the tool.

• An attacker compromises P0 and attempts to use our privileges to gain access to your account resources.

P0 takes prevents these attack scenarios using conditional IAM and trust policies, as follows:

‍

Scenario 1: A User assumes P0’s Role

Since P0 uses a role inside your AWS account to grant permissions, a plausible scenario is where an existing user or role inside your account might assume P0’s role to escalate their privileges. To mitigate this threat, we use a strict IAM Trust policy [1], which allows AssumeRoleWithSTS only for P0’s service account. This ensures that no identity other than P0 can assume the P0 Service role in your account.

‍

Scenario 2: A User escalates their privileges using P0’s policy

P0 also uses an IAM policy to define the actions P0 can perform inside your AWS Account. A potential threat is a user who might attach this policy to a user/role outside the P0 tool, and hence elevate their permissions, without going through P0’s approval workflow. To prevent threat, we use conditional IAM to restrict each of the statements inside the IAM policy, to the P0 role alone. Any identity that is able to attach this policy will be prevented from performing any of the aforementioned IAM actions.

‍

Scenario 3: An attacker compromises the P0 Service Account:

P0’s GCP service account use STS inside your AWS accounts to gain access to the P0 IAM role. In theory, if an attacker can infiltrate P0’s infrastructure, they would be able to perform AWS IAM actions via the P0 service account. This is a security threat, as the malicious actor might create new roles in your AWS account, which can be assumed from outside the account, and provide escalated permissions on various AWS resources.

‍

To counter this threat:

• P0’s AWS IAM policy explicitly denies the service account from adopting any roles other than its assumed IAM role.

• P0’s AWS IAM policy explicitly denies it from attaching any additional policies to, or removing policies from, its assumed IAM role.

• P0’s AWS IAM policy, via conditional IAM, denies it from attaching any policies to identities outside of the AWS account.

Transparency

The entirety of the above configuration (role, role policies, and trust relationship) resides within your AWS account’s IAM, and is auditable by your root account (or any user in the account with IAM read permissions). You can additionally view the configuration commands prior to running them in your system.

‍

While the configuration is editable by your account’s users, manually editing it is not recommended, as it may either break your P0 integration, or expose your account to additional security vulnerabilities.

To dive deeper into the world of P0 Security, explore our guided tour of workflows here, or refer to our detailed docs. You can also join our community Slack channel to engage with like-minded users.

References:

1. https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html

‍