Sponsored Unsecured data storage and containers, leaking sensitive company data. Unrestricted access to network ports and services. Excessive permissions. The risks associated with misconfigured cloud resources could hardly be more serious, effectively laying out a welcome mat for cybercriminals.
Yet many misconfigurations continue to go entirely undetected by companies developing and deploying digital apps and services on public cloud infrastructure. Undetected, that is, until disaster strikes.
Given Amazon Web Services’ market leadership position in public-cloud services, it’s hardly surprising that a huge number of these misconfigurations are found in AWS deployments. But it’s not the cloud giant that’s at fault here, argues Barak Schoster, chief technology officer of cloud security specialist Bridgecrew.
“The AWS ecosystem is extremely robust, the company’s doing an amazing job - but what sometimes gets overlooked is that the security of the data that customers keep on the cloud is the customers’ own responsibility,” he says.
That’s made very clear by the AWS Shared Responsibility Model. “AWS takes responsibility for the security of the cloud; but it’s the customer who is responsible for security in the cloud. And that means it is down to the customer to correctly configure applications, role-based access controls, data sharing, that kind of thing, and to keep on top of AWS security best practice in terms of how infrastructure is configured and operated.”
This, he acknowledges, can be a huge challenge. “Cloud engineering can be hard. We know this from real-life conversations we have with cloud-native companies every day, who tell us about the problems they have in implementing identity and access management rules and in defining best practices for new services,” he says.
“Another challenge is that, once an issue’s been identified in production, it can be a lengthy process for a security team to feedback details to the engineer who wrote the code and get it fixed. It can often take days, so instead, it makes much better sense to give that engineer what they need to apply the right security configurations at the time that they’re actually developing the code.”Find-and-fix missions.
With that in mind, Bridgecrew is on a mission to help companies find and fix misconfigurations in their AWS environment not only at run time, but also far earlier on, during the build process. Either way, the goal is simple, according to Schoster. By automating cloud security, embedding it earlier in the development lifecycle and delivering it as code, the company’s tools mean IT teams “spend less time securing their infrastructure and more time scaling it”, he says.
This is achieved through close integration between Bridgecrew and various AWS services. Once Bridgecrew is connected to a company’s AWS account, Bridgecrew deploys a read-only IAM role on that account, via AWS CloudFormation, an infrastructure-as-a-cloud (IaC) service that enables users to create collections of related AWS and third-party resources and provision and manage them efficiently. This IAM role, Schoster explains, then performs read-only API calls in order to assess configurations and identify issues in existing and new services on AWS.
Misconfigurations are then categorized in a number of ways: for example, by type, severity, and deviation from a whole range of benchmarks relating to security best practice and compliance. These cover not only AWS best practice, in areas including IAM, Kubernetes, networking, logging, Elasticsearch, S3 and Serverless, but also PCI-DSS 3.2 for customer payment details, HIPAA in healthcare and NIST 800-53 for US-based federal information systems. Bridgecrew currently comes equipped with around 500 predefined policies for best-practice configuration, Schoster estimates, and the number is growing all the time thanks to the open source community contributing to a number of Bridgecrew tools, including its IaC scanner, Checkov.
This is by no means a one-time task, he adds. Once connected to an AWS account, Bridgecrew will continue to periodically perform such scans, preventing what he calls “cloud security drift” – a common occurrence in dynamic cloud environments that undergo a steady stream of updates and improvements.
Nor does the work on run-time environments end there. Bridgecrew can also provide automated remediation of many misconfigurations on AWS. “It’s a big help to many engineering teams already facing enough work that we can take the strain of tackling these fixes, without the need to add yet another JIRA ticket to the pile,” he says.
Find and fix
What really excites Schoster about Bridgecrew is how it’s geared specifically to the way that engineers think and work - and nowhere is this more apparent in the way the technology integrates with code repositories, in order to bring the same ‘find-and-fix’ approach to code well before it goes into production. As well as AWS, Bridgecrew supports Azure and Google Cloud, and multiple tools and frameworks outside of the AWS ecosystem. These include Terraform, the big IaC framework, SCM/VCSs such as GitHub, GitLab, and Bitbucket, and CI/CD providers such as CircleCI and Jenkins.
This process of putting the original developer in charge of the security of the code they develop is commonly referred to as “shifting security left”, but while it’s frequently talked about, many IT teams find it hard to put into practice, says Schoster.
“At the same time, we’ve seen that it can be very valuable in terms of supporting the kind of rapid development and deployment that teams want to achieve, as well as catching misconfigurations before there’s even any potential for harm,” he says. “So, our idea has been for Bridgecrew to run as part of testing suites on each and every change a developer makes to their cloud infrastructure code, scanning for issues and stopping problems in their tracks, flagging them up right there in the CI/CD pipeline. Prevention, in effect, is preferable to cure.
What’s more, fixing IaC misconfigurations by enforcing common security policies through small changes to missing configuration rules or incorrect values in IaC templates and modules at build time helps speed up future deployments. “And that can have a positive, lasting impact on security posture going forward.”
With AWS, that might include setting S3 bucket encryption at rest to relevant buckets, so that all subsequent data added to it is encrypted automatically. It might mean tweaking automatic key rotation in AWS Key Management Service (KMS), so that the keys used for encryption and decryption are refreshed more regularly. It could involve enabling Point-in-Time Recovery (PITR) for Amazon DynamoDB.
“That’s especially true if you’re working in a development environment where there are hundreds of commits a day and you want each of them to be vetted. That’s where we’re playing to our strengths, because the sooner teams are getting alerted to necessary changes, the better feedback loop they have and the less organisational overhead,” says Schoster.
“I never underestimate the challenges involved, because I’m a security practitioner myself. And I find it hard enough to keep up with AWS, even though I’m reading about updates every day with my morning coffee, having conversations at work about the latest changes, and checking in again right after I put my kids to sleep. There’s a lot of work involved in staying up to date with AWS security best practice, but what’s great about Bridgecrew is we have so much experience that goes into our hundreds of policies and playbooks, as well as an amazing open source community helping us out.”
Sponsored by Bridgecrew