With many companies transitioning their on-premise resources to the cloud, cloud security in DevOps is becoming an increasingly important topic of discussion for many IT Security Teams. One commonly overlooked cloud security issue faced by every organization is cloud misconfigurations in applications. A simple configuration mistake made by a developer or sysadmin can lead to a costly data breach. Cloud misconfigurations have caused many high profile breaches which not only affect a company’s bottom line but also their reputation. Given the severity of these misconfigurations, security teams must find ways to monitor and detect these developer mistakes early in the software development lifecycle before the misconfigurations are pushed into production. Microsoft provides a potential solution to this problem in Azure cloud environments with their open-source tool called the Azure Secure DevOps Kit.
The Azure Secure DevOps Kit (AzSK) is a free collection of scripts, tools, extensions, and automations that can be used within a continuous integration / continuous deployment (CI/CD) pipeline to continuously monitor and scan an Azure environment for configuration issues and vulnerabilities. The AzSK can provide security teams with Microsoft’s suggested best practices to secure Azure Subscriptions, Resource Groups, and Features, and provides the ability to automate security in a CI/CD pipeline. The tool also has the capability to be integrated into Azure DevOps and events generated by the tool can be sent to Azure Log Analytics to create dashboards for continuous monitoring. This tool provides security teams with the ability to automate security tracking issues across the entire DevOps lifecycle.
One of the core features of the AzSK is the Security Verification Tests (SVTs). An SVT is a set of security control checks which can be run against a particular resource type in Azure. The AzSK contains a PowerShell module which runs each of these SVTs against an Azure subscription to determine potential security weaknesses in the configuration of Azure resources. This module is also packaged into a Visual Studio Extension which can be integrated into a CI/CD pipeline in Azure DevOps. The extension can provide DevOps Engineers with the ability to confirm the security of new Azure configuration deployments and automatically stop deployments if they fail to pass the SVTs. Depending on the risk profile of a particular application or service, “breaking the build” and preventing deployment may be a powerful option for organizations who cannot risk costly configuration errors in production environments.
Once you have an understanding of the tool and its utility in a CI/CD pipeline, the next step would be to start using this tool in your organization. To get started, we recommend a phased approach that begins with running the SVT scans manually on a periodic basis until your IT team becomes familiar with the tool and the results it produces. As more experience is acquired the team can gradually work to integrate the SVT scan to run automatically in a CI/CD pipeline, much like one might with other common tools such as Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST) or Software Composition Analysis (SCA) technology. In an ideal scenario an organization would have mandatory SVT scans in both the CI and CD phases of a pipeline in addition to a separate automated scan that runs on a weekly basis for a Security Team to monitor. If an SVT fails in this scenario, an action could be triggered to halt the deployment and email a developer or other stakeholders for review.
Do not underestimate the need for a behavioral change management plan to smoothen the rollout of AzSK capabilities. Security champions programs are a great vehicle for such communication with developer teams. If an organization can implement these recommendations, they will be one step closer to preventing cloud misconfigurations and hopefully not become another statistic in a cloud breach report.
