This is part 1 of a multi-part series where I will cover strategies you can use to secure your digital supply chain


Introduction

Lately, there have been a lot of reports in the media about security breaches. It’s become common for companies to be compromised, with essential data being leaked or sold. This results in significant damage to their reputation and finances.

Architecture Diagram

Detecting such attacks can be difficult because our software delivery pipelines constantly change. These pipelines are also one of the most privileged areas in our environment.

In this series, I’ll guide you through ways to secure your supply chains on AWS to mitigate this kind of attack.



Static Credentials

One of the most common places for this kind of attack to start is by obtaining credentials, whether they’ve been accidentally leaked on the internet, are stored on a developer’s computer or are obtained from a secure location after it’s been breached.

Removing static credentials is one of the simplest ways to secure your environment.


What are static credentials?

By static credentials, I refer to any credentials that don’t change or require manual rotation. Think of AWS IAM Access Keys that are created and don’t change unless someone manually creates a new credential set and disables or deletes the old one.

Architecture Diagram

Another example of static credentials could be API keys to access essential parts of your system. If you’re using services like AWS Cognito with the client_credentials mode, you’re also putting your environment at risk, as these also don’t change and require manual rotation.


Substitutes for static credentials

AWS provides us with several substitutes for static credentials, depending on the kind of access we need.

  • AWS IAM Identity Center (AWS SSO) can provide users with a secure, 2FA enforced and centrally managed login, which utilises AWS session (temporary) credentials on the backend.
  • AWS IAM Roles allow us to access specific resources in our account and assume roles to access resources in other accounts. When a role is assumed, we use an AWS session using temporary credentials that expire after a given period (usually an hour).
  • Federated Identities can be used to authenticate using temporary sessions using 3rd party provider logins (e.g. GitHub - check out my previous post to learn more)

I’ll show you how to secure your CI/CD Pipeline to deploy resources into your AWS accounts using temporary credentials, configuring access to resources and continually monitoring your environment for potential access misconfigurations.


What if your application doesn’t support IAM Roles?

If you’re attempting to authenticate a third-party system into AWS, some applications don’t support IAM roles; in these cases, you can try to use IAM Roles Anywhere; however, if you’re using a SaaS application that doesn’t support IAM Roles, Federated Identity or IAM Roles Anywhere, I would suggest looking at alternatives.


Choosing a credential storage system

If you’re forced to use static credentials to authenticate with third-party systems, such as configuring SaaS or on-premises applications via an AWS-hosted CI/CD Pipeline, then here’s some knowledge that might help you make that choice.

Generally, the 3 I’d recommend choosing from are:

Architecture Diagram

You may think that Hashicorp Vault is the obvious choice from the above graphic. While it does provide a lot of flexibility, it is also the most expensive option and requires some integration into your existing systems.

AWS Secrets Manager and Parameter Store are native to AWS and integrate naturally with AWS services such as ECS, CodeBuild, CloudFormation, RDS, etc., making them the preferred choice for most workloads.

Once you have configured your secrets in either Secrets Manager or Parameter Store, you can access them via the AWS APIs, ideally using an application authenticated via IAM roles.


Removing static credentials

Wherever possible, use AWS native development services (such as CodePipeline & CodeBuild) which will integrate with IAM Roles out-of-the-box, but that can be pretty difficult in our world. We need to integrate many tools and technologies, including our CI/CD pipelines.

One of the most popular CI/CD tools is GitHub Actions, which is slowly becoming Microsoft’s de facto development platform.

If you’re using GitHub Actions for your development, consider implementing OpenID Connect instead of using access keys. I’ve already written an article with instructions on how to do this which you can find on my blog.

Architecture Diagram



Controlling access

Implementing a secure authentication mechanism between your deployment pipeline and your AWS infrastructure is the first step in securing your supply chain.

It’s important to architect your environment with the expectation you will be breached; that means sticking to a rigid least-privilege policy for your teams, ensuring they only have access to what they need for their role without causing problems.

Secondly, it’s also vital to continually monitor permissions in your environment for any misconfigurations, as it’s often these misconfigurations that will allow attackers to gain access to privileged resources.

While we’d like to restrict access to production, far too often, our teams require immediate access to resolve urgent issues, which will happen. We can implement monitoring & alerting when any of our team members manually access production via the AWS Console or generate any static credentials.


Enforcing least-privilege

There are a couple of strategies we can use to enforce least privilege that I’ll discuss here:

  • IAM Access Analyser
  • Attribute-based access control (ABAC)


The IAM Access Analyzer

The IAM Access Analyzer is a free tool provided by AWS that lets you validate your IAM policies by seeing what resources the policies provide access to and generating IAM policies based on CloudTrail activity.

Note - in the below section, specific details such as account and organisation IDs will be omitted for security purposes. You will see additional information if you’re following along.

Go to Services > IAM > Access Analyser and create an analyser to start.

Architecture Diagram

Creating the analyser across your entire organisation is recommended. If you’re using Control Tower, you can set your Audit Account as a delegated administrator and perform your organisation’s analysis from there.

Architecture Diagram

Click Create; you will see the findings once the analyser is complete.

Architecture Diagram

Click on any of the findings, and you will see some details on what the resource is, how it’s accessed, and what kind of permissions it has.

Architecture Diagram

From here, you have a couple of options for dealing with this finding:

  • Archive it, which will remove it from the active findings.
  • Resolve the access, which may entail removing the role or adjusting access and then rescanning.

This tool provides you and your team an easy way to review access into your AWS environments and is crucial to ensuring least privilege.


Getting notified of security risks

Once you’ve performed your initial review and remediation of your access, it’s highly recommended to configure an EventBridge Rule to monitor for future findings and notify your security team to review.

You can quickly remediate any misconfigurations before they become problematic by alerting new potential IAM Access Analyser findings.

You can configure an EventBridge rule to listen to IAM Access Analyser findings on specific analysers by utilising the following pattern:

{
  "source": ["aws.access-analyzer"],
  "detail-type": ["Access Analyzer Finding"],
  "resources": ["arn:aws:access-analyzer:ap-southeast-2:xxxxxxxxxxxx:analyzer/MyAnalyzer"]
}

Creating a rule per analyser is recommended so you can process these accordingly. You can direct each rule to an EventBridge Pipe, which can filter and enrich your finding with additional data that can be sent anywhere, an API, SNS, or to a centralised event bus.



Attribute-based-access-control (ABAC)

Attribute-based access control is a methodology for controlling access across your environment. ABAC relies on allowing access to resources based on their attributes, such as tags.

I won’t create a guide on using ABAC, as AWS covers it very well. Combining ABAC with RBAC is recommended to provide you with more granular control over your user’s access, ensuring access is restricted to the accounts, services and unique resources they need.



Closing notes

Thank you for reading my blog post; I hope you found it helpful, and stay tuned for additional blog posts on this topic.

Let me know if you have questions or perhaps comments about this article.

Thanks again.