An Inside Look at Secure DevOps Kit for Microsoft Azure

Source :-

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: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):

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).

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).

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.
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: