How-To
An Inside Look at Secure DevOps Kit for Microsoft Azure
Learn how you can use this collection of tools to set a security baseline for your subscriptions, check for security issues during development and so much more.
Many challenges in cloud computing come from the sheer size of deployments. If you have a handful of servers that you need to manage and secure, a manual approach can work. As the number of servers and applications increase, however, managing security by hand won't work.
Add to this the demands for increased agility that DevOps bring to the table and the automation that's required and the risk that something falls "between the cracks" is vastly increased. This is the challenge that many enterprises face, including Microsoft itself (its IT department runs more than 90 percent of the company's applications on Azure). The solution Microsoft built is called Secure DevOps Kit for Azure (Microsoft shortens to AzSK), which is open source and available on GitHub here. In this article, I'll show you how you can use this collection of tools to set a security baseline for your subscriptions, check for security issues during development, deploy securely via Azure DevOps (formerly Visual Studio Team Services, VSTS), scan production workloads to catch configuration drift and have a dashboard in Azure Log Analytics tracking security issues across the entire DevOps lifecycle.
Installation
The installation documentation is here -- you'll need to have PowerShell 5.0 or later running on Windows. Simply run:
Install-Module AzSK -Scope CurrentUser
Depending on what's already installed on your PC you may have to add -AllowClobber to that command. The kit is updated monthly so it's a good idea to keep up-to-date, if your installation is more than two versions behind, you'll get error messages telling you to upgrade -- just run the same command I just showed you. There's also an option to automatically update the kit by running:
Set-AzSKPolicySettings -AutoUpdate On
Which will prompt you to update whenever a new version is available.
Basic Usage
The kit has been updated to use the new Az set of PowerShell modules (as opposed to the older AzureRM modules), so make sure to uninstall the older modules if they're present. Let's start by using AzSK to scan a subscription for issues (see Figure 1), begin by logging in:
Connect-AzAccount
Once you've authenticated, run:
Get-AzSKSubscriptionSecurityStatus -SubscriptionId <SubscriptionId>
[Click on image for larger view.]
Figure 1. Scanning a subscription for issues.
This will take a little while and then a folder will open containing a summary .CSV file, and a few subfolders with logfiles. Opening the SecurityReport.csv file lets you filter the content (in Excel) -- you should pay particular attention to Failed and Verify results. The former lets you know when a control wasn't fulfilled, and the latter doesn't have an automatic way to be checked and you have to manually attend to them. In this report from a production subscription I can see that I have three high-impact fails and two medium fails. The .CSV also contains a recommendation column where I can see the steps I should take to remedy each issue.
One of the high-impact fails points out that I haven't configured Azure Security Center correctly, but there's a Set-AzSKAzureSecurityCenterPolicies cmdlet that lets me configure the correct people's e-mail and phone number details to fix this. I also don't have alerts configured on the subscription (Set-AzSKAlerts), no ARM policies configured (Set-AzSKARMPolicies) and the Standard tier for Azure Security Center isn't enabled. I can now go through and address these issues (unless I have compelling business reason to not follow the recommendations) and then rerun the script.
To check the security stance of applications in a particular resource group (RG) use (Figure 2):
Get-AzSKAzureServicesSecurityStatus -SubscriptionId <SubscriptionId> -ResourceGroupNames <RG1, RG2>
This will take a little longer, depending on the number of resources in your RG. Depending on the number of issues and their nature there could be a lot of work to fix all these issues. If you'd prefer your reports in PDF format you can use the -GeneratePDF flag, with options for landscape and portrait mode.
The tests I've run in both these cmdlets are called Security Verification Tests (SVTs).
[Click on image for larger view.]
Figure 2. A Resource Group .CSV security report.
Autofix
Both of the preceding cmdlets lets you pass in a -GenerateFixScript flag, which will generate a script that you can subsequently run to automatically remediate issues. The report .CSV has a column showing which issues can be addressed this way. The results folder will have an extra folder called FixControlScripts that'll contain RunFixScript.ps1 and a FixControlConfig.json file with parameters (IP address, usernames and so on), which you may need to edit, depending on the fix (Figure 3).
[Click on image for larger view.]
Figure 3. Folder output from a scan.
Attestation
If you see controls that you don't want flagged in future scans, but that you don't want to fix or that you can't fix for some reason, you can attest these issues. To do this, pass in the ControlsToAttest switch, which will run the scan as per normal but then enters into an attestation mode where you can provide justification and settings that are then stored in the subscription (along with when and whom provided them), preventing them from being flagged in future scans. You can have these attestations expire after a set amount of time, with defaults for Critical controls of 7 days, High 30 days, Medium 60 days and low 90 days. The state of attestations is stored in an RG called AzSKRG and a user needs Owner or Contributor permissions to this RG to do attestation, which makes sense, as you would only allow certain security people this power.
If you have a large number of resources across many RGs to attest you can do so with bulk attestation.
Integration
Being able to run these tests on an ad hoc basis is a good starting point for ensuring good security hygiene. The next step is to run the SVT tests automatically as part of a CICD pipeline and if they fail you can have different actions triggered, such as failing the deployment, e-mailing someone or pausing progress awaiting manual approval.
This functionality is published as the Secure DevOps Kit (AzSK) CICD Extensions for Azure in the Azure DevOps marketplace (see Figure 4). It's got an ARM template checker for new deployments, as well as a task that can run the SVTs against deployed resources.
[Click on image for larger view.]
Figure 4. CICD plug-in for Azure DevOps.
There's also an extension for Visual Studio (2015 update3+, 2017 and 2019) called Security Intellisense, which will flag code with red or green squiggles based on the severity of the issue.
Continuous Assurance
OK, so you've cleaned up your act around security for new deployments and you're checking templates as they pass through your deployment pipeline. But these are still points in time, now you need a way to monitor on a continuous basis to ensure that configuration drift doesn't induce security issues. You'll need to have a Log Analytics workspace in Azure Monitor set up and be running the kit on Windows 10 or Server 2016. To enable a subscription for continuous assurance run:
Install-AzSKContinuousAssurance -SubscriptionId <SubscriptionId>
And specify parameters such as the automation account to use, the OMS (older name for Log Analytics) workspace and so on. There will be a runbook in your automation account called Continuous_Assurance_Runbook and you can edit the schedule to run it as often as you'd prefer. If you'd prefer to have a central subscription that runs continuous assurance against multiple other subscriptions use the Central Scan mode. Interestingly you could end up with "positive" configuration drift if newer security controls are made available in Azure and existing deployments flag these, allowing you to implement these on running deployments.
Monitoring
Continuous assurance, along with the CICD plug-in and basic usage (using Set-AzSKMonitoringSettings) also known as SDL mode, send their results to a Log Analytics workspace. This is the final piece of the puzzle for visibility of your overall security posture where the kit reports to a central Log Analytics workspace with a prebuilt overview tile and detailed dashboard blades for subscription, ExpressRoute and resource security (Figure 5). Log Analytics also lets you write and run queries to dig into the data as deeply as you need to.
The kit also integrates with Applications Insights for telemetry gathering.
[Click on image for larger view.]
Figure 5. Log Analytics Dashboard.
Wrapping Up
Migrating to the cloud is more than just shifting a few VMs to run on someone else's servers -- it's a shift in how to "do IT" and along with that comes changes to all aspects of IT service delivery. The Secure DevOps Kit for Azure is a tool developed internally at Microsoft for its IT team to manage its own deployments and it really shows. It's got a lot of real-world applications and features that were clearly developed in response to actual security risks and controls. If you're deploying to Azure, I recommend taking a good look at Secure DevOps Kit for Azure, there's definitely a learning curve but the end result will be a much more secure environment.