Close Common Security Holes with Azure Security Center

When you read the headlines, or watch television shows or movies, you get the impression that all major security incidents are the result of highly sophisticated attackers executing amazingly complex exploits that require ten Ph.D.’s in computer science and some double doses of nootropics.

If that were true, all of our lives would be a lot easier.

The fact is that there aren’t that many mega-geniuses out there. And even if there were, complex exploits are often very expensive to execute, and so the attacker/victim economy doesn’t favor the attacker.

Unfortunately, anyone who’s ever been involved with a minor, medium or major security incident knows it’s the “low hanging fruit” that gets overlooked that ends up creating the security hole that lets the attacker in. Attackers take advantage of easy exploits against easy to fix imagesecurity issues – and while the security issues are easy to fix, too often the fixing doesn’t happen.

We can have a major impact at reducing the risk of compromise if we can find a solution, a tool, a service that makes it easy to quickly find and remediate these common security holes.

Azure Security Center is one of those solutions. To demonstrate that, let’s look at a collection of “easy to fix” security issues that when they’re not fixed, bad things can happen.

Virtual Machines

Antimalware can go a long way toward protecting your operating systems and the virtual machines they run on. It’s easy to install antimalware. What’s not as easy is getting visibility into systems that don’t have antimalware installed and therefore are vulnerable. With Azure Security Center, it’s easy to get visibility into how many virtual machines don’t have antimalware, the names of the VMs, and installing antimalware right from the Azure Security Center console.

If you go into the Prevention pane of the console, you’ll see Resource security health section. There you can click Virtual machines to see if there are security issues with your virtual machines.


There’s a notification stating that Endpoint Protection not installed. What? I thought I had antimalware installed on all my VMs!

Well, its easy to miss VMs, especially if you have 100’s or 1000’s of them. Let’s click on that notification to get more information.


Now we see a list containing the names of VMs that don’t have antimalware installed.

Not only that, but we have the option to install antimalware right from the Azure Security Center console. Notice that the checkboxes are already checked, so if you have a lot of VMs that need antimalware, you won’t have to worry about making an avocation of checking checkboxes Winking smile


That’s all there is to it! Very easy to fix, but if you don’t fix it – you could be famous for things you don’t want to be famous for.


There are some easy things you can do to secure your network, like making sure that devices that aren’t intended to be Internet-facing are not able to accept incoming connections from the Internet. Sounds easy, right? Again, it is easy to configure network access controls. What’s not easy is to find virtual machines that you assumed were not Internet-facing, but in fact, are accepting incoming connections to the Internet.

Azure Security Center has you covered here. We’ll start again in the Prevention pane and click Networking in the Resource security health section.


This will open an interface that provides us a tidy list of Internet facing endpoints. How cool is that? Try that on-premises!

Notice that Azure Security Center identifies Internet-facing VMs and then assigns severity ratings to the status of NSG (Network Security Group) and NGFW (Next Generation Firewall). Let’s drill down on vm1.


When we drill down on vm1 and we see two recommendations:

  • Add a Next Generation Firewall
  • Restrict access through Internet facing endpoint

I don’t know if I want to add a Next Generation Firewall yet, but I know that Network Security Groups come with my Azure Virtual Networks, so I’ll check into that first.


Well! Look at that – my default RDP rule (that allows me to manage the virtual machine using RDP) has a Network Security Group rule that allows any IP address to connect to the virtual machine.

That’s quite an “attacker surface” (number of possible attackers who might be able to reach the virtual machine over the Internet). Azure Security Center recommends that inbound rules be configured to limit inbound connections to the VM.

Sure, but how do I do that? Notice the Edit inbound r… notation in the figure below? You can click that and it will take you through a path that will allow you to configure your Network Security Group rule right within Azure Security Center.


And here’s the interface.


Azure Security Center once again makes it easy to handle a security problem that’s easy to fix in theory, but often difficult to fix in practice because of visibility issues.


Data at rest needs to be encrypted. In the on-premises environment it’s critical because someone could walk away with hard disk drives. In Azure, this isn’t much of a problem, since walking away with disk drives (assuming that it was possible) isn’t going to give the thief much useful information due to the distributed nature of the Azure storage system and the expanse between the data itself and the metadata. However, encryption at rest is required by many compliance initiatives, so you better have that data encrypted or face the consequences.

Like with our virtual machine and networking examples, it’s pretty easy to do. On-premises, you just enable encryption in your storage arrays or use operating system based encryption mechanisms. How about in the cloud? Again, it’s very easy to enable encryption. But, like the previous examples, how do you know if a storage account hasn’t been encrypted? You might have 10s, dozens or 100s of such accounts. There’s got to be a way to find these unencrypted storage accounts and get them encrypted.

Once again, Azure Security Center saves the day! Let’s see how.

Let’s go back to the Prevention pane and click Data.


Here we see a list of STORAGE RECOMMENDATIONS. One of them is Storage encryption is not enabled. That’s not good – let’s see what storage accounts haven’t been encrypted by clicking on that recommendation.


This shows a list of storage accounts that haven’t been encrypted. How do we fix it? Let’s click on one and see what happens.


Nice! Azure Security Center let’s you fix the problem right within the Azure Security Center console. Just click Enabled to turn on Azure Storage Encryption.


As you can see, simple security holes become a lot more complex when you don’t have easy visibility into the problem. Azure Security Center not only solves the visibility issue, it helps you fix the problems right with in the console. With that said, “in-the-box” easy mitigations aren’t available for all the security issues we find, but we’re adding more every day. And even if we don’t provide one-click fixes, we do provide detailed instructions on how you can fix them.

Fixing the issues we discussed in this article can help prevent a successful breach of your Azure assets. If you haven’t checked out Azure Security Center yet, give it a try. It’s free to try with any Azure account.



Tom Shinder
Program Manager, Azure Security
@tshinder | Facebook | LinkedIn | Email | Web | Bing me! | GOOG me

Skip to main content