CIS 3.1 in Azure - Azure Security Center

Continuing on with discussing the CIS Controls on Azure, the goal of this post is to talk about CIS Control 3, and specifically 3.1: Run Automated Vulnerability Scanning Tools.  On-premises, this control focuses on using tools to scan networks and systems for known vulnerabilities.  In some cases, this can include both internal and external scans, depending on your policy.

Applying this to Azure is a bit tricky.  When you think about the shared responsibility model, vulnerabilities in the underlying services that you use are technically the responsibility of the provider.  Services that you create (and place on top of) Azure resources fall under your responsibilities.

So, if I had to translate CIS 3.1, I would say that vulnerability scanning is essentially ensuring that the services you have provisioned are secured by default (ie: you have used the correct configuration) and that the configuration of those services meets your corporate policies.  There are a couple of tools in the Azure toolbox that you can use to satisfy this requirement, and today we are going to talk about Azure Security Center.

Azure security center comes in a couple of different service levels, but even in the first level, you get access to a rich dashboard and the ability to apply policy/audit to your resources (in a generic way).  Here is what my dashboard looks like currently (in my test subscription).



Oh my! I've got a lot of work to do here.  Here is a look at the current recommendations for my subscription.



Azure Security Center has a rich feature set that is only growing.  You can look at a list of the policy definitions here.  I would say that implementing Azure Security Center and working through the remediation/policy items in a timely fashion (as per your patch management policy) would suffice to meeting CIS 3.1.  It is constantly being updated by Microsoft to reference best practices for the Azure platform, and provides continuous scanning against deployed resources.

CIS Control 2 on Azure - Application Whitelisting

Continuing on from the first post to chat about CIS Control 2, lets now have a look at 2.7: Utilize Application Whitelisting.  In the context of CIS, this references that application whitelisting is in use on all assets to ensure that only authorized software executes and all unauthorized software is blocked from executing on assets.

In the terms of Azure, I think the closets thing to software would be the Azure resources that one can deploy.  In this case, we want to be able to white list the Azure resources that can be deployed, and block all others.

It turns out that doing this via Azure policy is actually quite easy.  Here is an example:

{
  "if": {
    "field": "type",
    "notIn": [
      "Microsoft.Compute/VirtualMachines",
      "Microsoft.Compute/disks",
      "Microsoft.Compute/networkInterfaces"
    ]
  },
  "then": {
    "effect": "audit"
  }
}

The above policy (as written) will throw an audit even when a resource is deployed that is not of the listed types.  Using Azure Policy effects, one could switch the result to deny, which would then enforce that no resource types that were not previously approved could be deployed.  Building out a policy such as this would likely satisfy the application whitelisting control of CIS Control 2.

CIS Control 1 on Azure - Maintain Asset Inventory Part 5

In part 4 we discussed how we could use an Azure function (presumably triggered off of an event hub subscription) that would look at a resource and grab information on the required tags.  Another way to do this is to make use of Azure Policy.

The policy document for this type of affair is quite easy and looks something like this:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "anyOf": [
          {
            "field": "tags.department",
            "exists": "false"
          },
          {
            "field": "tags.approved",
            "exists": "false"
          },
          {
            "field": "tags.owner",
            "exists": "false"
          }
        ]
      }
    ]
  },
  "then": {
    "effect": "audit"
  }
}

The above policy will only look at virtual machines, and will kick off a non-compliance item if any of the tags department, approved, or owner is missing.  Pretty neat!  One thing to keep in mind when using this system is the evaluation triggers.  See this link for more information.