Saturday, May 26, 2018

CIS Control 2 on Azure - Software Inventory

Continuing on with discussing the CIS Controls on Azure, the goal of this post is to talk about CIS Control 2, which focuses on software assets, specifically 2.4: track software inventory.

I had to think about this one a little bit. In the context of Azure, I would define the software that we need to track as the components of the Azure platform that are currently in use.  As per the documentation, we need to track the following:

  • Name
  • Version
  • Publisher
  • Install date
I would say that most of the above don't make sense in the cause of components on the platform. 

From powershell, you can very easily obtain a list of all the resources you have currently deployed. 

$resources = Get-AzureRmResource

The output of this will work for any resource you have deployed.  The output will follow the information provided in the REST documentation.  The output looks something like this:





You can very easily get a list of unique resource types that are deployed in your Azure subscription.  The following powershell should do the trick.

$resources | sort-object -Property ResourceType -unique | select ResourceType

You should get something like the following:



Now that you can build this list, you can monitor it for changes as required.

The only thing we are not able to get easily off of the Azure platform is the install date of the particular resources.  While there are some methods (such as OMS, or Azure monitor) they are mostly subject to log retention constraints.  One way would to track this would be to make use of tags.

Sunday, May 20, 2018

CIS Control 1 on Azure - Maintain Asset Inventory Part 4

In part 3 I talked about a high level process for responding to new events being created on the Azure platform.  One of the components involved in the process was an Azure function that would be used to process the events, and determine if further action would be required.

I decided to use this as a good excuse to play around more with Azure functions.  The goal of this post is to talk a bit about the code required to make this work.

Step 1: Get Data Object

I started off by creating an http triggered Azure function, which seemed like the easiest way to integrate the function.  When you create an HTTP triggered function, you get some access methods to get data either off of the query string or the post body.

For example, the shell code is:

                 dynamic data = await req.Content.ReadAsAsync<object>();
                name = data?.name;

In our case, we want to grab the resource ID of the resource being written to.  That would be something like data.data.resourceID based on the event hub schema.

Step 2: Getting Access to Azure

Once we have the resource ID, we would need to connect to Azure.  I am big fan of Azure MSI, and decided that this would be the best way to go forward.  In order to utilize this, I decided to use the "Microsoft.Azure.Management.ResourceManager" library, which is essentially a wrapper around the REST methods.

Please note that you will also need the "Microsoft.Azure.Services.AppAuthenticaiton" library, to facilitate the MSI interaction.  Once you get these wired into your program, connecting to Azure is as easy as:

var azureTokenProvider = new AzureServiceTokenProvider();

var serviceCreds = new TokenCredentials(await azureTokenProvider.GetAccessTokenAsync("https://management.azure.com/").ConfigureAwait(false));

var resourceManagementClient = new ResourceManagementClient(serviceCreds);


Step 3: Getting tags from an Azure resource

I found that the easiest way to get access to the resource information I needed was to use the GetByID method.  Please note that I tried to use the CheckExistence method, but if failed to return at all for the API versions that I tried.  Not sure if there is a bug in there.

During this, I fooled around with the new Azure REST API Manager preview.  Check it out here.
There is a pretty cool "try it" feature that logs you into your Azure subscription and allows you to test the calls.

Step 4: Profit

After that, getting access to the tags was pretty easy. I can now add my own logic to check for what I want (in our case, the existence/population of certain tags such as owner, department, and approved).

This was a pretty fun little foray into the world of Azure functions.

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.