Press Release
Last Updated on January 4, 2024
Over 90% of public cloud security breaches start with user error, not the cloud service provider (CSP). What are the most common missteps that lead to vulnerabilities? And what are the “low-hanging” best practices to adopt for quick cloud security wins?
Temi Adebambo, Head of Security Solutions Architecture at Amazon Web Services (AWS), explains what most often goes wrong with public cloud security and how AWS users can address their biggest risks.
Join us as we discuss:
- The 2 mistakes public cloud users make that cause the most security breaches
- Ideas for baking security into your DevOps pipeline without gating your developers
- The top AWS security tools that pretty much all users should leverage
Most common cloud security user errors
Public cloud security starts with a shared responsibility model.
“There’s a set of responsibilities for security that falls on the provider,” Temi explains. “Many times that’s everything below the OS… The responsibility of the customer is configuring their instances and their identities in the cloud, and how they’re keeping their data secure. And that’s where things start to fall apart.”
Because it’s so easy to spin up new cloud instances, you need to be extra careful not to configure resources with public access.
“The responsibility of the customer is configuring their instances and their identities in the cloud, and how they’re keeping their data secure. And that’s where things start to fall apart.”—Temi Adebambo
More “abstraction” equals more baked-in security
The closer you get to “serverless” (e.g., by leveraging AWS Lambda to run code without provisioning or managing servers), the more of the underlying compute stack—and associated security—is abstracted away from your application and onto the CSP.
That could take challenging tasks like patching operating systems and protecting endpoints right off your plate.
“Vulnerabilities in the operating system and unpatched systems are still one of the biggest areas of risk,” Temi cautions. “Moving up that stack and selecting services at that layer that allow us to manage services below for you… There’s a lot of good security that you can benefit from there.”
“Vulnerabilities in the operating system and unpatched systems are still one of the biggest areas of risk.”—Temi Adebambo
Why do orgs overlook cloud security?
It’s axiomatic that orgs skip security in the cloud (or on-premises) because it’s perceived to slow down developers. But that’s not the only reason many public cloud users stumble on security.
“The other part is a lack of security resources that are actually dedicated to the project,” advises Temi. “If you have a project with just a bunch of developers trying to do their best, and you don’t have a security champion in there, everyone’s going to do their best with best intentions. But if no one is really focused on security, it will make it an afterthought.”
“[When] security is baked into how we test, how we move from one gate to another, when we get to the end, we are not in a position of choosing between security and app functionality.”—Temi Adebambo
What AWS tools should everyone be using?
AWS has a vast and ever-growing menu of security tools and features. But which are the “must use” capabilities that most AWS users should enable?
“Oftentimes, I send customers to start with our AWS Security Reference Architecture,” Temi reports. “That is a set of prescriptive guidance that we have published that gives you a good starting point.”
From there, the most critical services for most orgs to turn on are:
- Amazon GuardDuty for integrated threat detection (including automated alerts on risky configurations)
- AWS Security Hub for cloud security posture management
Also essential are the AWS integrated identity & access management and key management capabilities.
“I strongly recommend data protection and encryption in the cloud,” emphasizes Temi. “You want to make sure that your data, when in transit and at risk, is encrypted and you’re managing permissions to those.”
“I strongly recommend data protection and encryption in the cloud,” emphasizes Temi. “You want to make sure that your data, when in transit and at risk, is encrypted and you’re managing permissions to those.”—Temi Adebambo
Putting up guardrails
The best way to keep developers developing is to create simple, automated guardrails they can gently bump against when a choice goes against policy. This works much better than expecting them to remember a lot of security concerns.
“I would encourage security teams to build guardrails and not expect the developers to be in tune with all the security that is necessary at the AWS layer, so they are able to operate and build things without going outside of those boundaries,” suggests Temi.
An example of a “guardrail” is a service control policy in AWS to limit the number of services that can be deployed or what a service can do in your environment, such as “no public S3 buckets can be created.” That way developers can create the S3 buckets they need and set appropriate permissions, without worrying about exposing the business to added risk. (All Amazon S3 buckets are and always have been private by default.)
“How dev teams should work is to be aware of the data they’re putting in AWS and the permissions that are needed to manage the workload, and then focus on building in a secure manner and do all the [security] checks,” states Temi. “When they need to do something special, we work together as a security team with the developers to understand why and create paths to make it happen. So, it’s more of a ‘Yes, but how?’ rather than a ‘No’ or a ‘You should know everything on security.’”
“I would encourage security teams to build guardrails and not expect the developers to be in tune with all the security that is necessary at the AWS layer.”—Temi Adebambo
What’s next?
Want to listen to the full podcast with Temi Adebambo? Click here.
