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 first part we consider the first 5 controls. Stay tuned for part 2!
Broken Access Control
The number one control in the OWASP Top 10 is enforcing access control policy. The goal is to ensure that users or services only have permissions to access the services they require for their function. In AWS, a least privileged approach is essential. Avoid the use of long term credentials by using roles over users. Scope a bunch of functional roles instead of providing broad access. Ideally, for end users, you should look to use a central identity provider through AWS SSO. For services, make sure your EC2 instances always use instance roles. Similarly, your containers and Lambda functions should use heavily focused role policies. It’s worth spending the time starting with minimal access and adding additional access as you find a requirement. Avoid providing broad access and then “coming back later” to fix it!
Only provide public access to your assets (such as EC2 instances and S3 buckets) when required. The default should be to make everything private. Make heavy use of Security Groups and NACLs to protect your environments. If you need additional control, consider a Web Application Firewall (AWS WAF) or a managed firewall such as AWS Network Firewall.
Monitor access to services, especially from outside of your VPCs or AWS accounts.
Cryptographic Failures
Dance like no-one is watching, encrypt like everyone is – Werner Vogels, Amazon CTO
Encryption in transit and at rest are foundational to protect your data.
In AWS, it is simply and very cheap to ensure you encrypt your data at rest. In EC2, you can enable EBS encryption by default so all subsequent storage will be encrypted. Similarly, it is simply to encrypt databases in RDS. Many services, such as DynamoDB, are encrypted by default. We recommend that you use customer managed KMS encryption keys to gain greater control over the key policy.
For encryption in transit, AWS Certificate Manager also offers free SSL certificates that you can use with AWS services, such as CloudFront and ALB. For these services, always use the latest encryption policy, enforcing TLS 1.2 as a minimum.
In fact, protecting your network traffic is really important. Network segregation is nothing new. Put your resources into a layer that is appropriate for its function. That may be public facing or it may be deep in your VPC! Use VPC endpoints to keep your network traffic inside the VPC. When communicating outside your VPC, use secure channels like IPSec based AWS VPN or private connections via Direct Connect.
Injection
Many people first think of SQL injection when they ponder the OWASP Top 10. Classic injection issues include SQL, NoSQL or shell based commands provided as user-supplied data. Every application should validate and filter any input (whether human or machine provided). In the AWS platform, AWS themselves take care of this when using the AWS CLI or console? Do you have any other ways to manage your environments, such as via a ChatBot?
Consider how you validate any input. Use code scanning tools such as Snyk or Amazon Code Guru to evaluate your code before you deploy it. Perform a threat modelling exercise on these key services. Keep your platform up to date through vulnerability scanning of your EC2 instances and container images with Amazon Inspector. Patch regularly and often, automating through AWS Systems Manager.
Insecure design
Secure design is a state of mind. Think about security upfront and your teams will continue to move faster. Plan your implementation to minimise your attack surface. Segregate your services. Adopt a zero trust mindset. Build a set of security blueprints for services. This allows your builders to keep moving as long as they stay within the guardrails of the blueprints without having to wait for security approval. Monitor for non-compliance to these standards.
Backup your secure design by enabling security visibility of your AWS implementation. Enable services such as GuardDuty, CloudTrail, Config and VPC Flow Logs (to name just a few). Collect the data from them and use it to alert on unusual or suspicious activity. It’s much quicker and cheaper to plan for and implement this as you build than to add it later!
The threat landscape is constantly evolving. So should your security controls. Constantly evaluate changes to your services and what that means for your security posture. Aim to adopt an “as a service” based approach. For example, use RDS over running your own database on EC2. Let AWS manage the DB platform and keep it secure for you!
Security misconfiguration
By 2025, 99% of Cloud security related failures will be as a result of configuration or other human error by the customer of the Cloud platform – Gartner
Problems caused by misconfigurations are not new and are not specific to Cloud based environments. Adopt repeatable patterns implemented through infrastructure as code (via CloudFormation or Terraform) to ensure you have a known baseline configuration.
Use services such as AWS Systems Manager, Config and Security Hub to monitor and report on compliance to standards and configurations. You can even use Lambda to automatically respond to misconfigurations and remediate the issue before it becomes a problem!
