Getting Started with the Azure Security Center

Microsoft recently announced the availability of the Azure Security Center which is designed to provide a single place to view your security stance for resources deployed to Azure.

In this post I’m going to walk you through what’s initially available and see how it can start helping you today.

Who ever said “no” to something that’s free?

The core features (today) are free. Yes – free. This isn’t just preview pricing either. During preview even the Standard Tier is free until early 2016.

The free tier will give you the ability to understand your VM and networking security stance for zero dollars down and I can’t think of a single scenario where you wouldn’t use it.

The rest of this blog will cover the free tier only.

What can you do today?

Right now the Security Center is primarily aimed at the components of Azure that provide Infrastructure-as-a-Service (IaaS) features such Virtual Machines, Virtual Networks with some limited support for Azure SQL Databases as well.

Arguably, IaaS components such as VMs are also the ones that you can most easily misconfigure such that you create a security hole in your environment. Many of the other Azure services are secure by design and make it very hard to leave yourself exposed (you’ll notice I didn’t say impossible).

In order to use the Security Center you must first enable it for your Subscription (simply selecting “Security Center” in the Azure Portal will prompt you to do this) and once enabled you must set up a Policy.

A Policy determines what the Security Center will monitor, and can include any of the following:

• Virtual Machines
  • Windows Updates are up-to-date
  • Baseline rules compliance
  • Antimalware is installed and operational
• Networking
• ACLs on open endpoints for “classic” VMs
• Network Security Groups are configured. Inbound rules are analysed
• Inbound port 80/443 is protected with a WAF
• Azure SQL Database
• Auditing is enabled at Server/Database level
• Encryption is enabled at Database level.

Remediating VMs

If your scan highlights issues with VMs you can remediate these issues from right in the Security Center. Let’s take a look at fixing missing antimalware.

Firstly we click on the Virtual machines resource health entry.

Which opens the Virtual machines view. Here I only have one VM, but you could image a fleet of VMs here in various states.

At this point I can click on a particular status (such as missing Antimalware).

Which gives me the option to remediate the problem. In our scenario it is installing Antimalware. Note that I can select one or more VMs to remediate in a single action if I wish.

I even get a choice of Antimalware software…

Now I configure the Antimalware the way I need to be when installed.

When I switch back to the VM details blade I can see that the extension is being deployed.

Now it’s installed I’m just waiting for the outputs from the antimalware scan.

Eventually when the scan takes place this option will turn Green (hopefully I don’t have any malware on my VMs!)

While I was doing the above, the Windows Server also installed a round of Windows Updates and rebooted, which resulted in the health status of its updates changing from High to Low.

I can see at a glance that I still have 13 pending updates to deploy though none are critical as the Severity is ranked as ‘Low’. I can drill into this further and look at the actual pending set of updates and open the details of each individual update and decide if I really need to deploy it or not.

Note: you can also monitor Linux machines, though you don’t get the same deep metrics around updates and AV as you do with Windows.

Remediating Networks

As well as VMs we can also manage VNets deployed (both on the v1 “classic” platform and the new v2 “ARM” platform).

Drilling into our network stance we can immediately see some things that might need attention.

We can see a recommendation here about what needs fixing.

Drilling in once more exposes the NSGs applying here and a clear description of why this configuration is sub-optimal.

I will add source address restrictions to these endpoints and when re-scanned by the Security Center this issue will no longer show. I could, of couse, dismiss this issue if I was aware of it and happy to accept (a public application is likely to have to accept inbound traffic from any host).

Remediating Azure SQL Databases

The final service we can manage today is the Azure SQL Database PaaS offering. The new v12 SQL Database engine has introduced new features such as encryption which is top of many enterprise’s data security list.

At a glance we can see which databases (and servers) we should be looking more closely at.

For this post I’m looking only at the auditing capabilities which, when set at the server, are inherited by hosted databases. This feature is available for the classic v11 (or v2) engine and the new v12 engine too.

I can open the server and see further details about any recommendations and when I click on the recommendation I can remediate it by performing an action – in this case I can configure auditing for this Azure SQL Database instance.

After I’ve applied the new settings and a short period of time has passed (to allow the Security Center analytics process to run) I can now see how my security stance has changed.

I could further increase my security by switching on Transparent Data Ecnryption (TDE). As with the other recommendations I could choose to suppress this warning because I may not need encryption. If I do change my mind at a later time I can always come back and switch it on (and unmute the warning).

Summary

The Azure Security Center is so new it still has that “new car smell” about it and it is also early days for the coverage that it offers for the multitude of Azure service offerings. Over time hopefully the services covered will expand and we’ll have an even better way to protect ourselves.

As I said at the start of this post – given the free service tier provides good value, I can’t see why you wouldn’t be using it.

Happy days!