The OWASP Top 10 aims to provide security awareness to developers and to web applications. It consists of the 10 most important controls to consider in order to reduce risk to your application. However, the themes aren’t just relevant to your applications. They can also be applied to your AWS environment configuration.
Let’s have a look at each control and consider how it can be applied to securely configuring your AWS based solution.
In this second part we consider the next 5 controls. Check out part 1 for the first 5 controls!
Vulnerable & Outdated Components
Understanding your risks to potential vulnerabilities is key for your application environment. Knowing what you software you have and what versions are running is important to reduce risk. AWS Systems Manager Inventory can be used to track and report on versions of software on your EC2 endpoints. Amazon Inspector can also scan your ECR based container images and EC2 instances for known vulnerabilities, reporting on potential issues that should be remediated.
Use both to understand what you have, remove what you don’t need and patch the components that are vulnerable. Patch Manager should be setup to automate the patching process for your EC2 instances. If you have a software management tools, such as Chef, we recommend replacing over patching, automating the install of the latest versions. Regularly replace your instances with the latest AMI and use your tooling to install the components required.
If you have auto-scaling enabled to respond to load, you need to be scaling out quickly. Installing software on demand isn’t the answer. You are probably using a golden AMI approach. Ensure that you rebuild that image automatically and regularly to ensure the latest patches and versions of dependent software are installed for any launched EC2 instances. If you don’t have an existing tool, have a look at AWS Image Builder. You can schedule it to run regularly and build new versions of your images. It supports both AMI and Docker images.
Identification & Authentication Failures
In an application context, you need to think about how you protect your authentication system. Thanks to the shared responsibility model, AWS will take care of that for you. As the AWS account owner, your responsibility is managing how users and services access the environment. Avoid the use of long term credentials through stored access keys on endpoints. Instead, use temporary roles. AWS SSO simplifies this, particularly in a multi-account environment. If you have an existing identity provider, you can use that with AWS SSO and managed your credentials centrally.
Don’t forget to enforce MFA, either through SSO or your connected identity provider.
Software & Data Integrity Failures
Much like you might (should!) know what goes into your application code, you should know what you use in your AWS environment. Are you using validated tools, agents and software? Supply chain dependency checking should apply to your infrastructure as code, not just your application code.
Ensure that you have appropriate segregation between your deployment system and the systems you are managing. In general, avoid putting software or endpoints into accounts. Centralise the capability. Use roles that the centralised solution can assume in target accounts to perform operations.
Logging & Monitoring Failures
Having visibility of your AWS services and environments is a cornerstone for security. AWS offers a heap of services (think CloudTrail, Config, GuardDuty, VPC Flow Logs to name just a few) that produce a vast amount of instrumentation. In fact, in the AWS Cloud, the problem is not having the visibility, it’s knowing what to do with it. Turn on logging, preferably to a persistent store such as S3 (CloudWatch Logs is another, more expensive, option). If you have a multi-account setup, look to centralise your logs to ease collection and analysis of the logs. Think about both the control plane – audit logs of changes and access – and the data plane – activity in the environment such as VPC network access.
Once you are collecting logs, how do you analyse and monitor for suspicious activity? You can use AWS native tools, such as Athena (see how you can analyse VPC Flow Logs this way), Security Hub and Detective. You can also use CloudWatch alarms and dashboards. Alternatively, you can use a third party tool, such as Sumologic, to collate and analyse logs. Another advantage of a third party tool is that the logs are now replicated to an alternate solution. They cannot be tampered with from the source system. You can achieve a similar result using S3 replication or S3 or Glacier object lock.
Server-side Request Forgery
The final control in the OWASP Top 10 is server side request forgery. It can be mitigated through good application practice. Once again, our friend the AWS Shared Responsibility model takes care of the heavy lifting for us in relation to the AWS platform (but not the application you run in it).
To support and mitigate the risk further, think about how to segregate your VPC network layers. Implement egress control through NACLs, Security Groups and, if required, the AWS Network Firewall. Monitor both accepted and blocked traffic egressing from your VPCs.
Wrapping up
If you missed it, check out our previous blog where we cover the first 5 controls from the OWASP Top 10.
If you would like to understand more about how you can apply these to your AWS based solution, please get in contact.
