AWS Security Myths Part 2 – Cloud Security

This is part 2 of the AWS Myths mini blog series. Part 1 touched upon data security within the public cloud and can be found on the Bridewell website. Part 2 intends to take you through common security myths associated with public cloud usage, specifically AWS.

The public cloud is not as secure as on-premise or private cloud infrastructure

The AWS global cloud infrastructure is comprised of industry leading physical, technical and administrative security controls. The infrastructure has been built to meet the requirements of world leading organisations, of which many have extremely sensitive security and compliance requirements. Visibility of the controls implemented to meet these requirements are published on their website and can also be accessed through the AWS Artefact service.

In general, when deployed properly using cloud approved patterns the public cloud can help to meet or exceed security levels when compared to the costs of deploying the same controls on premise.

My secret access keys are not safe in the cloud and access to my keys is not secure

For all human access to AWS the ability to utilise multi-factor authentication is available. MFA is also available for automated (non-human) interactions such as API calls, this is typically a good idea for high impact API calls as an additional security control. AWS has dedicated services to manage secrets and cryptographic keys including AWS Secrets Manager, EC2 Systems Manager – Parameter Store, AWS Key Management Service and Cloud Hardware Security Modules (HSM’s).

Where possible AWS encourage the use of IAM roles as opposed to static access keys. This allows users to assume roles that enable specific activities to take place. This is safer, as temporal access keys are generated as opposed to the creation of static keys that could be compromised through malicious or accidental actions.

Detective controls are also available such as CloudTrail, CloudWatch and AWS Guard Duty. There are also several community tools that can be used to scan repositories pre and post commit to attempt to identify secrets before attackers discover them.

My business is highly regulated, so I cannot use a public cloud to deploy my services

The AWS public cloud is used by highly regulated organisations across the globe. AWS runs a global compliance program that is comprised of certifications and standards applicable at global, national, regional and local levels across the globe. AWS helps its customers comply with many of these certifications by providing quick starts that can deploy compliant infrastructures such as PCI DSS, UK OFFICIAL and Public Services Network (PSN).

I can’t security test my assets if they are in the cloud

AWS allows penetration testing of their platform and currently AWS allows you to perform tests of the following resources: EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, LightSail, DNS Zone Walking. It also prohibits testing of small or micro RDS instances andm1.small, t1.micro and t2.nano EC2 instances.

Before you can perform your own penetration tests you must request permission from AWS via a request form. Other simulated events such as CTF’s, war game simulations, Red/Blue/Purple team activities, DR simulations, (Chaos Engineering) etc. must also be requested by submitting an email to aws-security-simulated-event@amazon.com.

Cloud penetration testing in general encompasses a different approach to traditional Infrastructure penetration testing and cloud security testing is something we cater for within our service line.

I don’t need to worry about patching in the Cloud

Again, we come back to the shared responsibility model when it comes to patch management responsibilities. If your consuming a compute service such as EC2 then AWS is only responsible for patching up to the hypervisor level, it’s your responsibility to ensure the OS of any AMIs you deploy are fully patched, and that any software installed on top of the operating system (OS) is also patched. This is very similar to traditional on-premise IT responsibilities.

To combat the challenges of patch management within EC2, you can utilise ephemeral infrastructure where you tear down instances and replace with known good (patched) AMIs periodically, essentially removing the need to perform traditional patch management processes.

In contrast to this when you consume PaaS services such as AWS RDS, AWS holds the responsibility for patching everything up to the OS. This removes the need for you to configure a database server and to ensure that the server OS and database software is patched. However, you still maintain responsibility for your application that utilises the RDS service. Another key feature within RDS is the ability to defer patching in the console.

This can be useful for production workloads, where you can specify that Test and Dev receive patches automatically, and then choose to manually roll out the patch to Production when you are happy that your code is working.

Finally, SaaS services relieve you totally of any patching responsibilities and usage of SaaS is becoming a key component of many digital transformation strategies.

Takeaway

As well as introducing financial benefits from the subscription based as a service model and enabling organisation of all sizes to take advantages of economies of scale, there are also clear security benefits associated with moving to the cloud. The cloud dramatically increases the pace in which you can assess, adapt and apply security. It also enables your organisation to test advanced services using separate environments that involves minimal effort and provides no onward impact to your production assets.

The cloud provides the building blocks to simplify and automate the implementation of identification, protection, detection, response and recovery controls. That can prove challenging to implement within a traditional on-premise environment.

As the technology and security world continues to shift to the left and embrace a DevOps/DevSecOps world, it’s clear that cloud is going to continue to play a huge part in this movement. As always though, there is no one size fits all approach to security, this statement is no different when addressing security within the cloud. There are many dichotomies that still must be overcome to achieve a security posture that addresses the key threats to your organisation and which also delivers true value to the business.

If you missed AWS Security Myths Part 1 - Data Security, don't worry you can read it here.