Friday, May 11, 2018

CIS Control 1 on Azure - Maintain Asset Inventory Part 3

In part 1 and part 2 of this series, we talked about how to use the Azure portal and powershell to create relevant reports relating to your asset inventory.  The problem with a reporting mechanism of this nature is that it isn't future proof.  Changes into the future require manual action (someone to review and correct the report).  Processes like this, especially security related ones, are known to become hard to maintain.

The goal of this post is to discuss conceptually how to tie in a couple of Azure services to create an alerting system that warns of changes that do not conform to the tagging required for the asset inventory.

At a high level, here are the steps we want to look at:

  1. User/Process creates resource (with or without appropriate tags)
  2. Automation is fired off to check resource for required tags
  3. If tags are missing, alert is sent to security team to review
It turns out that creating an alerting system like this is actually quite easy.  The first piece of tech we need will be Azure Event Grid.  If you haven't already, check out my previous post on the subject.  The event hub source we are going to need to look at is the resource group event.

Creating an event subscription is quite easy, but requires knowledge of a downstream subscriber endpoint.  You can create one in the portal via Event Grid Subscriptions.


It is important to note, in the future, that prefix/suffix filters can be used to scope the resource groups that alerts are generated from.  The other thing you are going to want to do is change the event type to only look at resource write success.  What this will do is create an event that we can subscribe to.  The event will be triggered whenever an Azure resource is written to, regardless of what it is.

When you examine the schema for resource group event, there are two key pieces that we will use downstream.

The resource URI will give us the fully qualified name of the Azure resource.  The operation name will give us the action that is being executed on that resource.

Okay, so now that we have an event triggering on write actions, we need something to process the request and check our business rules against it.  This is a perfect application for Azure Functions.

The Azure Function will have two main tasks.

  1. Parse out information for the target resource, and operation id
  2. Utilize the Azure SDK to look up that resource and confirm the tags in place
Parsing out the information is quite easy as Azure Functions maps the post data to a data object, that you can then just traverse.

The second part is also quite easy.  If you are using c#, you can make use of the Microsoft.Azure.Management.Fluent library.  There are a ton of examples you can use to get your barings.

The last thing that we need to do is send an email to our security team if the Azure Function determines that a resource has been deployed without appropriate tagging.  A super easy way to do this is using Azure Logic Apps.  The process is well documented.

At this point, we have a functioning alert system that, based off of business rules, creates an alert if resources are created in azure that are missing tags.  This automation can help ensure our asset inventory is up to date.