CIS 3.4 in Azure - Automated OS Patch Management

CIS 3.4 focuses on deploying automated operating system patch management tools.  In specific, the text reads:

Deploy automated software update tools in order to ensure that the operating systems are running the most recent security updates provided by the software vendor.

In order to properly understand how to implement this control on Azure, we have to have an understanding of the shared responsibility model that helps to determine roles and responsibilities between cloud-providers and cloud-consumers.  Here is a diagram from the shared responsibility for cloud computing whitepaper released by Microsoft.





Patching operating systems is part of the "host infrastructure" row above.  As you can see from the diagram, the only operating model we need to specifically address is the IaaS model.  This is because in all other cases, the cloud-provider is responsible for the management of the host infrastructure.  I'd love to get more into shared responsibility, but that is likely the subject of another blog post.

Because the target architecture is IaaS, in general, all your existing on-premises solutions for operating system patch management could apply.  This includes GPO settings with WSUS servers, custom yum repos, enabling/scripting update checks, etc. 

In the Azure world, there are two options.  Windows VMs can have automatic updates enabled at the run time using the ARM template configuration.  For linux VMs, you can make use of the custom script extension to enable automatic updates at deployment time.

 

In general, connecting your machines directly to automated update mechanisms works only in certain types of scenarios (stand alone machines, dev/test, etc).  In most other scenarios, you generally want additional options such as specifying an appropriate time, whitelisting/blacklisting updates, and staging updates across your infrastructure.

For those wanting more control over their updates, Azure has published an update management solution that makes use of the Azure Automation infrastructure to manage your updates.  I might cover update management in more detail in a future blog post.

In conclusion, managing operating system updates for Azure IaaS VMs is a very similar process to what you would currently do on-premises today.  There are features within the platform that make updates easier to maintain if you do not currently have a solution.  For the other deployment models, patching is an issue for the cloud-provider, and not the cloud-consumer.

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.