Press Release
Last Updated on January 14, 2024
Giving Your Dev Team “Guardrails” in the Public Cloud
Hopefully developers building software in the public cloud are concerned and supported to help mitigate cloud security risk at the application level. But what about security around the cloud management environment, which controls access to the software and all associated resources, including workloads, databases, and potentially code?
To discuss best practices around the most critical aspects of public cloud application security, especially Amazon Web Services (AWS), a recent episode of The Virtual CISO Podcast features Temi Adebambo, Head of Security Solutions Architecture at AWS. Pivot Point Security CISO and Managing Partner, John Verry, is the host.
Not a core dev competency
In Temi’s view, dev teams aren’t generally very focused on the AWS management interface—nor should they be.
“If they’re operating only at the application layer and they are not really connected to the AWS platform and what’s provided for them, I would encourage security teams to build guardrails,” advises Temi. “Don’t expect the developers to be in tune with all the security that is necessary at the AWS layer. Rather build guardrails for them so that they are able to operate and build things without going outside of those boundaries.”
A common guardrail might be a service control policy in AWS to limit what a service can do in your environment, e.g., “no public S3 buckets can be created.”
“How dev teams should work is to be aware of the data they’re putting in AWS and the permissions that are need to manage the workload, and then focus on building in a secure manner and do all the [security] checks,” offers 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.’”
Just keep swimming
A bump against a guardrail is an alert to security maintainers to connect with dev, understand the business need and co-create an efficient solution.
“One thing you don’t want to do is slow down the pace of innovation in the cloud because you keep putting security [there] as a barrier,” Temi cautions. “You want to enable them to move forward.”
“All too infrequently do we see those types of guardrails in place,” John observes. “We had a client recently where someone spun up another instance and didn’t have those types of controls and an S3 bucket was left open. Which seems to be somehow an easy problem to have, and it caused some impact.”
What’s next?
To hear this practical, best-practice oriented show with Temi Adebambo, click here.
Is it still a data breach if the data was outside your sanctioned/managed infrastructure? Good question as it turns out: Is It Still a Data Breach if the Data was Outside Your Infrastructure?
