Getting started with automated cloud security in 4 steps

Although the definitions and scope of security and compliance haven’t changed much in recent years, the nature of risks, access, and implementation of controls has changed quite dramatically. Containers, infrastructure as code (IaC), CI/CD, and other modern DevOps tactics have transformed the way infrastructure is provisioned and managed, making it easy for cloud security and compliance to fall to the wayside.

Bridgecrew’s codified and automated approach to cloud security is designed with that in mind—to empower teams to be proactive when it comes to identifying and reducing infrastructure risk. But getting started isn’t as easy as signing up for a new tool and reducing risk. This post will provide a framework for setting your cloud security priorities, planning your approach, implementing processes, and iterating.

Step 1: Assess your cloud security priorities and requirements 🤔

Whether you’re interested in modernizing your existing security program or building one from scratch, you should periodically ask yourself what you need to get from cloud security. The first step is assessing your motivations and requirements for investing in securing your infrastructure:

• What are your primary drivers? Compliance? Data security?
• Is there something in particular that you’re concerned about? IAM? Encryption?
• Who will be the stakeholders, and who will be doing the day-to-day work? DevOps? Security?
• What is success to you and your team? Avoiding breach? Passing an audit?

Assuming that you have the answers to those questions and have relatively solid cloud footing, you’ll also need to take stock of your infrastructure footprint:

• How many cloud accounts do you have? Are you on multiple clouds? Public or privately deployed?
• What frameworks are in use? Are you using IaC or leveraging containers?
• How are your cloud resources currently being managed?
• Are there plans to implement new IaC frameworks or containers in the future?

You’ll want to form your approach based on the nature of your current infrastructure and deployment stack and your plans for it in the future. If your infrastructure provisioning and management are mostly manual via your cloud provider console, you’ll need continuous runtime scanning. If you utilize or plan to utilize infrastructure as code frameworks like Terraform or CloudFormation, your approach will need to support getting visibility across those.

Step 2: Plan for complete visibility in the right places at the right times 🔎

To protect your infrastructure, you need to have a plan to get complete visibility into what risks are present. Adequately understanding your infrastructure risks and areas of improvement will require either a manual audit of your infrastructure or an automated solution. While you’ll be doing a bit of both, automation is a crucial part of any modern cloud security program. Even if you have a small cloud footprint, manually checking configuration against all security best practices like CIS and any relevant compliance frameworks is likely not feasible.

Also, keep in mind that while it’s essential to get adequate visibility into your cloud security posture, it’s just as important to get that insight on a continuous basis. There are a few approaches to getting automated and continuous visibility into your cloud security posture in both runtime and build-time:

• Cloud providers native tooling: Cloud consoles come equipped with some rudimentary built-in and add-on tooling to monitor your cloud security posture.
• Open source tools: To scan a few environments’ configuration against known libraries of security and compliance policies, you may opt to leverage an open-source tool such as CloudMapper for AWS runtime environments or Checkov by Bridgecrew for build-time IaC files.
• Third-party cloud security solutions: Third-party cloud security solutions monitor your cloud infrastructure based on industry best practices and compliance frameworks. They are a great way to provide visibility and continuous benchmarking and reporting for internal and external audit needs.

Regardless of your approach, set clear expectations for the amount of resources and management automated cloud security solutions may be. Open source tooling often requires customized implementation and constant upkeep. Some cloud security platforms can come with a steep learning curve to adopt internally. Regardless of the approach, automation can also create distracting noise for you and your team, which is why it’s incredibly helpful to put the right processes in place up front.

Step 3: Implement processes to address cloud security feedback 🤝

At the heart of every successful cloud security strategy is a well-defined process for governing policies and managing cloud security feedback. Generally, there are two approaches to gathering input and enforcing policies:

• Passive, alert-based monitoring: The least invasive cloud security approach provides passive monitoring and results gathering, providing a backlog of issues to address. There are several ways to make this kind of feedback more visible—real-time notifications and integrations with ticketing systems like Jira or ServiceNow.
• Active, control-based guardrails: The more heavy-handed approach to cloud security is implementing cloud security feedback into development processes wherein issues can actually block builds or deployments. Taking that down a notch, you may opt to instate guardrails that don’t unequivocally hinder work and provide workarounds with the right number of reviews or reviewers in place.

Whether you’re scanning your production cloud environment periodically throughout the day, or you’re employing more advanced cloud security reviews on pull requests or via CI/CD builds, the feedback you receive is only as valuable as your ability to take action. By understanding who will be responsible for addressing issues, it will be easier to delegate responsibility throughout your teams and set clear expectations.

First, work with every team responsible for each part of your infrastructure to determine:

• How they should receive security feedback and be alerted of new errors
• Investigation and prioritization processes
• SLAs for fixing issues based on their severity

A great way to establish relationships and set up processes to enable collaboration is to leverage the tools and workflows already available. If your data science team uses Jira, make sure your workflow supports that natively. If your core infrastructure team lives and breathes by Slack, prioritize notifications there.

Before putting those processes in place, determine whether your team is adequately equipped and resourced to address issues on an ongoing basis. That may entail dedicating effort points into sprints or implementing a rotating security resource to be on call at any given time. Consider how you and your team will prioritize issues alongside existing performance upgrades, bug fixes, and, most importantly, new features.

If you’re tight on security resources or are focusing on other areas of your security program, you may want to consider alternative remediation paths. For example, Bridgecrew goes beyond scanning to provide automated remediations in AWS via Lambdas and security-as-code fixes into Terraform and CloudFormation via pull requests. Considering a solution that provides automated fixes may be a great way to get buy-in from your champions who will need to spend less of their own resources. This can also be a particularly valuable approach if your team is particularly lean.

Step 4: Press play and iterate 🚀

For modern organizations, cloud security is ultimately a collaborative and incremental undertaking. Although it’s important to start with goals and guidelines, know that your processes will likely evolve. To that end, when you’re getting ready to turn on or ramp up your cloud security automation, our final pieces of advice are:

• Get both bottom-up and top-down buy-in and advocacy before turning anything on.
• Start small by adding security monitoring just a few accounts or repositories.
• Optimize for minimal disruption and test the waters before turning on alerts or roadblocks.
• Codify as much as you can early on by implementing as many fixes as you can in build-time and writing custom policies along the way.
• Plan to iterate over time by setting periodic checkins to see what is and isn’t working.
• Live long and prosper. 🖖

···

If you have questions about your specific goals and infrastructure stack, we’d be happy to help. Reach out here and let us know that you’d like a cloud security consultation. We’re always publishing tactical guides for approaching cloud and infrastructure as code security on our blog, so be sure to subscribe! 👉