You’ve decided to shift your cloud security left. You researched vendors, evaluated solutions, did a proof of concept and now you’re off the IaC security races.
You know what your efficient, secure-by-default future holds, but how do you get there?
There are so many ways you can roll out an IaC security program to best suit your organization’s needs, with tons of decisions to make along the way. We know how difficult it can be to navigate that process and how to figure out where to start.
In this post, we’ll give you a general plan for choosing your IaC security path, rolling out your program and iterating along the way.
Before You Start: Pick Your Path and Define Your Goals
Before you can roll out your security program, you need to pick the best path based on your team’s existing processes and how much effort you’re ready to invest in setting up your program. From our experience, teams use one of three paths:
- Path 1: Relying solely on surfacing automated feedback to developers on commits and pull/merge requests via VCS integrations.
- Path 2: Encouraging individual developers to leverage local CLI scans or IDE plugins on top of VCS feedback.
- Path 3: Combining local and VCS feedback with additional scanning as part of build pipelines via CI/CD integrations.
These paths have different benefits and vary in setup complexity.
Path 1 yields the majority of IaC scanning benefits for the least setup effort, like getting easily actionable, collaborative and automated feedback to developers. With Prisma Cloud’s Code Security, you can set up VCS integrations to provide periodic scanning of repositories and real-time developer feedback within the pull/merge request workflow. Combined with customized enforcement, that feedback allows you to fine-tune how security policies are enforced. We’ll cover how to do that in the next section.
Path 2 builds on top of Path 1 by shifting IaC security feedback further left. By empowering developers to address misconfigurations earlier, before code is even committed, feedback cycles are much faster and cheaper. It also helps with general security awareness for developers that may be less familiar with cloud security best practices. This path does rely on individuals to configure scanning in their own local environments, and it may be difficult to enforce total adoption. However, because these local scans can also include custom configurations from Prisma Cloud’s Code Security, users will quickly see that scanning locally before they push code saves them time later on.
Path 3 enables the most complete adoption of IaC security. While this path involves customization for each pipeline and takes the most implementation effort, you’ll be able to take full advantage of IaC security features and automation capabilities. Because CI/CD pipelines are the heartbeats of software development and deployment, embedding centralized and universal guardrails is the best way to get final security assurance before cloud resources are provisioned. This is especially important for frameworks like Terraform, wherein code resources become more representative of their runtime states the further along the pipeline they get. The CI/CD pipeline may be the first time security tools have access to dynamically imported values or Terraform plan files to identify the actual misconfigurations that would be created with an apply command.
Once you’ve decided which path you’ll take to implement your IaC program, keeping in mind you can always add on more options later, you’ll want to set aside some time to identify your key performance indicators (KPIs) and goals to improve existing benchmarks. To do this, you should first assess your current runtime issues. Your ultimate goal is to reduce the number of runtime issues your team faces, but it’s also important to measure leading indicators of runtime issues, like the posture of your code. To establish your baseline code posture, break down your violations by severity level and identify the average number of new issues you see each month. Once you’ve assessed your baseline, you can set goals to work towards, such as reducing new monthly violations by a specific percentage, or just track your progress over time.
How to Start Implementing Your IaC Security Program
Once you have an end goal in mind for your IaC security program, you’re ready to start implementation!
To help make your program rollout as frictionless as possible, we recommend taking a crawl, walk, run approach.
Crawl: Onboard and Set Baseline
We recommend starting with your most innovative, early-adopting team, as they are typically the most open to leading new initiatives and will likely continue to serve as security champions in your organization. To begin with, you should onboard no more than fifty repos belonging to this team so that they can get comfortable with the new security program, start to experiment with more customizable features and tailor the program to their workflows.
You’ll want to follow the instructions below depending on the path you chose earlier.
- Automatically onboard your VCS
- Run scans locally using the CLI or integrating with your IDE
- Integrate your CI/CD pipeline
Before you actually enable any of those integrations, it’s important to set expectations with your team about how you want to enforce IaC security findings. Because hundreds of policies are being scanned and each organization has its own standards, we recommend starting with just non-blocking feedback via soft-fail checks. Keep in mind that all violations in IaC and secrets are set to hard-fail by default. In Prisma Cloud’s Code Security module, you can do this through configuration files or in the UI with our enforcement rules.
When you enable soft-fail checks, regardless of your path, you are merely surfacing informational feedback. When time permits, developers can act on that feedback or move feedback into a backlog to work through over time. Flagging misconfigurations as informational also allows you to suppress policies that aren’t applicable to specific teams.
As you think about progressing to the next phase of the rollout, you’ll want to measure your KPIs and your new baseline number of violations to get the complete picture of how your program is performing so far. If you’re starting to see the rate of new misconfigurations and vulnerabilities decrease, that’s a great indicator that your team is learning some cloud security basics, misconfigurations are being addressed earlier and your policy library is fine-tuned to your needs. So, if you’re seeing improvements in these areas, congrats! You’re almost ready to start expanding your program rollout further. But first, you should reaffirm expectations with your team members, adjust KPIs if needed and ensure that you’re gathering early-adopter feedback and incorporating it into your approach as you expand the rollout across the rest of your organization.
Walk: Get Started with IaC Security Features to Customize and Automate Your Program
The next phase of your IaC security program is two-fold: expand coverage across repos and teams and start leveraging more opinionated and mature IaC security features.
By incorporating what you learned from initial repo scans and feedback from security champions, you’ll be ready to start onboarding more repos and teams.
This is also a great time to start adding custom policies to your IaC program. While built-in policies monitor and enforce a wide range of cloud configuration specifications, custom policies add a layer of customization that can be helpful if you need specialized configurations that are unique to your organization. And as early-adopting teams get comfortable with the rollout, you can also start adding other integrations, such as an IDE or CI/CD pipelines.
For Prisma Cloud customers, this is also the point where more advanced features like Smart Fixes may become more valuable. Smart Fixes augment out-of-the-box fixes by leveraging your team’s past actions when addressing misconfigurations. As you onboard more teams and start scanning more of your IaC, these Smart Fixes will get better at recommending misconfiguration remediations with specifications that are tailored to your organization. The more you can do to make it easier to fix identified issues, the better. Again, the goal here is to see the number of new misconfigurations flagged go down.
At this point, you should start comparing your KPIs—especially remediation rates—across teams to evaluate your program. How are you performing against the KPIs you set earlier? Re-evaluate your performance and address any areas that may need improvement as you start to expand the program to other teams. This is a great time to encourage DevSecOps evangelists to educate and inspire everyone else in the organization to become security champions. If you’re able to bring security champions together, you can also foster cross-team knowledge sharing, which should help identify any areas that still need improvement.
Run: Leverage More Advanced Security Features and Iterate on Your Rollout Strategy
Now that you’ve expanded across repos and teams, you can introduce more stringent guardrails, like hard-fails. We recommend setting custom enforcement rules for each code category—IaC, secrets, container images and open source packages—by severity. Generally, it’s a best practice to start by hard-failing more critical misconfigurations and vulnerabilities and then expanding from there. Once you’ve introduced these enforceable guardrails, you can scale up that process and further customize how and where you are surfacing feedback.
To maintain your momentum, you should aim to onboard as many teams and repos as you can while taking a crawl, walk, run approach for each newly onboarded team. It should start to feel easier each time you repeat the process.
Since many teams are now fully onboarded and starting to take advantage of the more advanced security functionality and automation capabilities with your IaC security program, this is also the phase wherein you should start addressing the existing backlog of issues. Each team will benefit from past learnings and customizations and will, undoubtedly, contribute new learnings. Ultimately, you will be able to start improving the remediation rate and mean time to remediate (MTTR).
This stage of the rollout also presents another opportunity to measure your performance, reflect on the rollout process and build a continuous assessment and improvement process to help you reduce friction as you expand and maintain usage across the rest of your organization. Up until now, you’ve customized policies and suppressions across teams, provided automated feedback with PR comments or CI/CD jobs and started measuring remediation rates. Now, you can gather your performance metrics and take the feedback you’ve gathered from that experience to address common obstacles and improve your rollout strategy going forward.
···
Rolling out your code security program can be a daunting experience, but it doesn’t have to be. If you adopt a diligent approach focused on continuous measurement and improvement, you’ll reduce friction in your program operationalization and will be able to take advantage of the benefits of an automated and customized approach to IaC security.
Interested in diving deeper into operationalizing your IaC security with a step-by-step guide? Download the Complete Guide to Operationalizing IaC Security!