Following on from the Optus breach learnings blog, we look at how you can implement the learnings in your AWS environment. The AWS Cloud is ideally suited to enable you to use these modern techniques to help secure your services.
Let’s step through each of the learnings.
Control changes to your endpoints
All access to AWS environments should be through IAM roles and temporary credentials, not through long lived user credentials (think username and password) or API access keys.
We recommend implementing AWS Identity Center (formerly AWS SSO). Identity Center provides access to all the AWS account in your organisation through a single access point. Access to environments is through temporary roles that your define and allocate to users or, ideally, groups. If you have an existing identity provider, such as Azure AD, you should integrate Identity Centre into that. That way you can manage who can access your AWS environments using Azure Security Groups. Since you already have MFA enforced (right?) in your identity provider, you will ensure MFA access to AWS. Note that even without integration to an identity provider, AWS Identity Center also supports enforcing of MFA!
In Identity Center, use the principle of least privilege to setup highly refined roles for different activities and functions. Users are then given access to assume the role based on their group membership.
You should monitor the use of roles and actions. Look to continuously refine permissions using some of the techniques defined here.
Monitoring & visibility
Monitor not only the use of those roles but also specific high risk actions in your environment. You can use an external service such as Sumologic to do that or you can use native AWS services, such as AWS CloudTrail.
For example, let’s look how we can use AWS services to monitor changes to security groups. You want to monitor this type of change to understand what access is being allowed to assets in your AWS environments.
- Go to the CloudTrail console
- If you don’t have an existing Trail, setup one up and configure it to send events to CloudWatch
- If you have an existing Trail, update it to send events to CloudWatch
- Go to the CloudWatch console
- Select Log groups and select the log group that you used above for CloudTrail.
- Create a metric log filter for the log group. To set one up for Security Group changes, use settings similar to the following.
- Create an alarm for this metric. Select the tick box for the created metric filter and click on Create alarm
- Set a Metric name
- Keep the Statistic as the default of Sum
- Keep the Period at the default of 5 minutes
- Choose a Threshold type of Static
- For Whenever metric_name is, choose Greater/Equal
- Set the Threshold to 1
- Choose Next
- On the Configure actions page, choose In alarm
- Select an existing SNS topic or create a new one. If this is a new topic, add the email recipients
- Select Next and give the alarm a name
- Select Next and then Create alarm
Test the notification by making a change to a security group. It will look similar to the below.
Adopt a zero trust approach
Zero trust is the gold standard for access to services, including service to service communication. It’s the third of our Optus breach learnings.
To implement zero trust requires that every service is required to prove it’s identity to access another service. The same principle can be applied to external access to your APIs. There are many ways to enable authentication for you APIs managed through Amazon API Gateway.
- An API Key – clients pass the key in the X-API-Key header. API keys also provides the ability to throttle requests through usage plans
- Configure a Lambda authorizer for your API Gateway – with an authorizer, you specify a function that will authorize the request to the API and the data to use from the incoming request. This can be used in conjunction with an API key to control access to different API resources
- Use JSON Web Tokens (JWT) to control access – JWT is a very common way to control access to APIs and their resources and recommended. When used in combination with Cognito as the issuer, it presents a robust authentication approach, requiring credentials to obtain the token and then the token itself.
- Implement mutual TLS – all clients must present a certificate to prove their identity. With the Amazon API Gateway, you create a trust store in S3 to manage certificates
Only store what you need
Take the time to understand what customer data to store from a compliance perspective. If you don’t need it, don’t store it. Use Amazon Macie to discover the data in your S3 buckets in your accounts. Macie uses machine learning and pattern matching to identify sensitive information in your S3 buckets. You can then use this information to put appropriate controls in place. These controls come in the form of access control and monitoring, encryption at rest and in transit. You can also use Macie as part of your deployment process to ensure that sensitive data doesn’t end up where you don’t want or expect it.
For access control and monitoring, you can use the approaches discussed above.
For encryption at rest, we recommend that you enable encryption for your EBS (block storage) volumes by default using AWS KMS. It’s a simple process to enable and has no cost. If you want to share volumes, consider using custom KMS keys that give you more control over the key policy. For S3, you can use the same KMS approach for server side encryption. Particularly sensitive data may be encrypted client side. This does add the overhead of managing keys at the client end to decrypt the data, however.
Encryption in transit through SSL requires the management of certificates. AWS Certificate Management (ACM) can help with that through creation and automatic renewal for AWS services, such as ALB and CloudFront. If not need to encrypt all the way to the endpoint, then you can create a private CA in ACM and export the certificates to use on your EC2 instances.
Wrapping up
If you’d like to know more about implementing the Optus breach learnings in your AWS environments, please get in contact with us here at RedBear.
Alternatively, come and see as at the forthcoming AWS ANZ Security forum! Register here for one of the sessions in Melbourne, Sydney, Auckland and Perth.
