Lately, there have been a lot of articles and reports in the media about security breaches. Poisoning the software supply chain has become a popular attack vector in large-scale cyber attacks, these attacks aren’t small widespread attacks like a worm, they are reputationally and financially devastating, stealing data, leaking or selling it, and holding the company for ransom.
Detecting such attacks can be difficult because our software delivery pipelines constantly change. These pipelines are also some of the most privileged areas in our environment. Several vendors have attempted to build solutions to secure the pipelines using things like agents that run inside of our runners, but these solutions aren’t preventative, at best, they’d halt execution of obvious malware, but many complex supply-chain attacks use native functions that can be hard to detect.
In this series, I’ll guide you through ways to secure your supply chain, in AWS in particular.
Static Credentials
A common way you’ll get compromised is via static credentials, whether they’ve been leaked in a repository, or brute-forced, or stolen from a developers computer, static credentials pose a massive risk to your organisation and should be rooted out at all costs.
A static credential is any type of credential that doesn’t change or requires manual rotation such as API Keys, Usernames and Passwords and AWS IAM Access Keys. While static credentials aren’t completely unavoidable, where they are used, using something like 2-factor-authentication is advisable.
Substitutes for Static Credentials
AWS provides us with several alternatives to static credentials we can use to lock-down our environment access.
User authentication
For user authentication, it’s recommended to use IAM Identity Center, independently or with an external identity provider like Microsoft Entra, to have a centralised place to configure user access and permissions across your entire AWS environment.
Even though a username and password is a type of static credential, there are a few ways IAM Identity Center has a one-up on traditional IAM users here:
- IAM Identity Center is centrally managed, not just per account but across all of your accounts, from a single account.
- Integrates with your existing authentication provider, giving your team a central place to remediate security breaches and enforce login standards such as 2-factor-authentication.
- When a user authenticates with an AWS Account using their IAM Identity Center user, they assume temporary role credentials, even authenticating with AWS programmatically from their machine assumes temporary credentials, reducing the risk of an attacker stealing working credentials from a developer’s machine.
Programmatic access
For programmatic access you have a couple of recommended options,
- If you’re using programmatic access from inside AWS, it’s recommended to use IAM Roles to authenticate across accounts and with AWS Services.
- If you’re authenticating from outside of AWS, it’s recommended to use OIDC authentication or IAM Roles Anywhere, both of which establish a trust between AWS and another system, and allow the system to assume temporary IAM Role credentials into your environment.
It’s important to remember, if you’re using IAM Roles Anywhere, you need to keep your certificates private, as these are the key to having access to assume roles.
Managing Static Credentials
If you’re forced to use static credentials, such as if you have legacy systems that don’t support modern methods of authentication, then you need to ensure you’re managing those credentials in an appropriate way.
Secret management
Using a secret manager is paramount if you’re relying upon static credentials. The idea behind a secret manager is that it will store your static credentials securely, and may even have a modern form of authentication required to retrieve the credentials, sometimes, they will support auto-rotation, allowing you to automatically rotate your static credentials.
Using auto-rotation with a secrets manager is ideal, because you’re able to achieve similar results as a modern form of authentication, although, secret managers can introduce complexity in your environment.
Choosing a secrets manager
A few popular secret managers to use on AWS are:
In my opinion, Hashicorp Vault is the ideal option for secret management because of it’s capabilities and integration. However, Hashicorp Vault will introduce significant complexity into your environment, there are cloud services offered that can reduce the complexity, but if you want maximum security, it’s best to host it inside of AWS.
The most common secrets manager to use on AWS is, of course, AWS Secrets Manager. AWS Secrets Manager is the best option if you’re using AWS native services especially, as you can authenticate to it using IAM Roles, and it supports automatic secret rotation, allowing you to easily rotate secrets for things like RDS Databases.
I would recommend using Hashicorp Vault and AWS Secrets Manager for your secret managers, but, if you are on a very tight budget, you can use AWS Parameter Store, which supports encrypted parameters, and also uses IAM, although it’s not recommended because it’s less secure than AWS Secrets Manager and you’ll have to implement your own automatic rotation.
A temporary solution
While you should always have a secrets manager in your environment, the end-goal is to use modern forms of authentication for everything, so don’t let yourself get complacent with static credentials on legacy systems. If your system doesn’t support modern forms of authentication, you should look at moving away from it in the long-term.
For many of your systems such as CI/CD Pipelines, they might already support modern forms of authentication. You can read my other article on setting up GitHub Actions with OIDC for a guide on using GitHub Actions securely with AWS.
Least Privilege
Enforcing least-privilege is an ongoing activity that involves making sure every Role, User and Policy on your system has the least amount of access it needs without inhibiting your employee’s work or breaking your application. It’s a core component of protecting yourself against supply chain attacks, because often the supply chain is a secure environment where elevation is needed. Often times this elevation is gained by finding some old, often over-privileged credentials and using them to access other parts of the environment.
There are a few easy ways we can enforce least-privilege:
- Use attribute-based access control to ensure more granular control to specific resources instead of entire services.
- Ensure Security Hub is configured with at least the CIS Foundations standard, so it can look for Roles and Users with relaxed policies.
- Configure IAM Identity Center and create custom permission sets for roles, don’t just give everyone AdministratorAccess.
- If you don’t want to configure IAM policies, at least use the AWS managed policies for specific job functions to limit the scope of access.
- Use Organizations Service Control Policies (SCPs) to restrict the modification or creation of IAM policies, roles, users or access keys by users unless they meet a criteria.
Keeping Track of External Access to Your Environment
AWS IAM Access Analyzer is a free service that lets you keep track of policies that allow external principals to access your AWS environment. It’s useful and recommended to use this service and set-up events to be notified of new roles that allow external access.
Setting up IAM Access Analyzer
to Services > IAM > Access Analyser and create an analyser to start.
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.
Click Create; you will see the findings once the analyser is complete.
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.
From here, you’ve have a couple of options for dealing with findings:
- Archive the finding to remove it from the active findings.
- Resolve the access.
By setting up this tool, you and your team can have more control over what external principals have access to your environment, keeping your principals internal in AWS, where you have control.
Getting notified of new 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 configure an Event Bridge rule to listen for IAM Access Analyser findings by using the following event pattern:
{
"source": ["aws.access-analyzer"],
"detail-type": ["Access Analyzer Finding"],
"resources": ["arn:aws:access-analyzer:ap-southeast-2:xxxxxxxxxxxx:analyzer/MyAnalyzer"]
}After an event is picked up, you can process it how you want, this could include auto-remediation or just sending an alert to a phone number or mailbox.
Final Notes
I hope this post helped you to understand the risk of supply chain attacks and how you can secure your AWS environment from external access. In the next article, we’ll configure our pipelines themselves with security best practices.
Leave a Reply