Cloud Compute Vulnerabilities — If You Don’t Find Them, Someone Else Will
In this post, I continue my commentary on reading through the AWS Well-Architected Framework Security Pillar. Protecting a cloud infrastructure is divided into two areas, network and compute. The compute section lists six best practices. At first glance, this seems very comprehensive. However, best practices three through six are somewhat less substantive than the first two. As such, the rest of this post will focus on reducing the attack surface, and vulnerability management in the cloud.
When planning to use a compute resource, my first thought as a security practitioner is “how could this be compromised?” That’s why I like starting with attack surface reduction. Throughout my career, I’ve had the luxury of putting security at the highest priority. However, as I shift from working for the government to a revenue-generating venture, I realize that certain risks may be tolerated for the sake of the business case. Ideally, securely delivering a product, feature or service is part of the company’s values. Attack surface reduction should start in the design phase of the project. When you bring security into the requirements and architecture design, the resulting product should have fewer vulnerabilities than submitting a system to security checks after it’s been built.
Vulnerability management attempts to govern and mitigate the inherent risks of operating an information system. With regard to compute, vulnerability management includes how and when you would patch your EC2 instances among other activities. While there are ways to automate vulnerability management programs, it would be best to start with a reduced attack surface to manage. One of the examples I liked from the documentation was the suggestion to build a custom Amazon Machine Image (AMI) with customized security configurations in place.
Taking things a step further, suppose you needed to periodically deploy EC2 instances to meet some business case. You could have those images built to your security standards, save them as a custom AMI and provisioned as necessary. Or maybe you’re working with containers. You could automate your build to include container scanning before the final product is deployed in ECS.
Ideally, securing your compute resources in the cloud would start with security in mind. You’d have all the resources to reduce your attack surface, build customized and hardened templates to deploy using Infrastructure as Code. Once deployed, periodic vulnerability scans and a deliberate patch schedule will help keep your compute work-loads secure.
That’s my takeaway from reading through this section. Do you have scenarios or different ways to implement compute security for your cloud workloads? Leave a comment. Thanks for reading.
