It’s hard to stay in touch with all that’s being going on in Azure security, so we decided to make things a little easier for you by providing a monthly “catch up” post. This will make it easier for you to get a quick view of what happened in Azure security for the previous month.

We’re a little late with this one, as it’s the first one we’ve done. In subsequent months, we’ll post the monthly Azure Security News Catch Up on the first Monday of each month.

Here’s a list of things I found that should help you get in touch with last month’s Azure security happenings. If you have something in Azure security that you want to include in the monthly Catch Up, send me an email and I’ll make sure it’s included.

Now, let’s Catch Up with what happened in Azure security in August.

• Row-Level Security for SQL Database is Generally Available– OK, this isn’t strictly Azure security, since it’s about a SQL Server 2016 feature, but you can run SQL Server 2016 in Azure IaaS, and it’s a cool security feature.
• Azure Government Achieves Significant Compliance Milestones– Azure Government achieves certificates in FedRAMP Moderate Provisional Authority to Operate (P-ATO), , DISA Level 2 Provisional Authorization (PA), HIPAA Business Associate Agreement (BAA) and support for federal tax workloads under IRS Publication 1075.
• Securing Your Pre-production Environment in the Cloud– Devs an work in a pre-production environment where it’s super easy to move non-Internet facing pre-production slots to Internet facing production slots with single “click” (or command)
• A Practical Guide to Designing Secure Health Solutions Using Microsoft Azure– this white paper provides you with what you need to know to design and create secure application in Azure.
• SQL Server Connector for Azure Key Vault Public Preview Refresh Now Available– the SQL Server connector for Azure Key Vault allows you to manage your keys separately from the SQL Server itself.
• New Public Preview of Converged Microsoft Account and Azure Active Directory Programming Model– now you can work across Microsoft Account and Azure Active Directory using the new converged programming model.
• How I learned to stop worrying and love the cloud: Azure Forensics for the Security Responder - forensics in the cloud? Yes. Troy Larson shows you how.
• Microsoft Azure Storage Client-Side Encryption Goes into General Availability– encrypt data contained within Azure Blobs, Tables and Queues. Implement encryption in common use-case scenarios, and best of all, it’s interoperable across a number of programming languages.
• Pen Testing Your Applications in Microsoft Azure– yes, you can pen test your application in Azure, this article shows you what you need to do first.

That’s all for August – looking forward to sharing with you some *really big things* after AzureCon. Make sure you register so you can find out in real time!

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

Hi (Security) Community:

We heard, loud and clear, that you’re excited about this new capability, and based on our previous post Explore Azure Disk Encryption (ADE) with Azure PowerShell, you would love to hear more on the automation and scripting you can perform using the ADE cmdlets.  Today, Sudhakar Evuri, a Senior Software Engineer in the Azure Security engineering team, is going to walk you through three more scenarios that are a bit more advanced than the scenarios described in our earlier post. The scenarios we will walk you through are:

1. How to use a key encryption key in your Key Vault to further secure disk encryption secrets
2. How to enable Azure Disk Encryption on your VMs using AAD client certificate credentials instead of AAD client secrets
3. How to enable encryption on newly attached data volumes

Prerequisites

To get you started, here’s a friendly reminder of the important prerequisites that must be completed in advance on any Azure virtual machine you wish to launch these scripts:

1. Azure subscription: A valid Azure subscription is needed to use Azure Disk Encryption. Visit https://azure.microsoft.com/en-us/pricing/purchase-options/ to get one.
2. Azure PowerShell: Interacting with Azure Disk Encryption via PowerShell needs Azure Powershell 1.0.2 to be installed on your machine. Note: that Azure Disk Encryption is not supported on Azure PowerShell SDK version 1.1.0.
3. Azure Key Vault: Azure Disk Encryption securely stores the encryption secrets in a specified Azure Key Vault. Please refer to the Azure Key Vault – Step by Step blog post for more details on how to setup a Key Vault in Azure. In order to make sure the encryption secrets don’t cross regional boundaries, Azure Disk Encryption needs the Key Vault and the VM to be co-located in the same region. Please create and use a Key Vault that is in the same region as the VM to be encrypted. If you want to use the key encryption key feature, create a key in the Key Vault by following instructions on this page. This key will be used as the key encryption key to wrap the encryption secrets.
4. Azure Active Directory Client ID and Secret: In order to write encryption secrets to a specified Key Vault, Azure Disk Encryption needs the Client ID and the Client Secret of the Azure Active Directory application that has permissions to write secrets to the specified Key Vault. Please refer to the Azure Key Vault – Step by Step blog post for more detail on how to get the Azure Active Directory Client ID and Client Secret using the Azure portal.
5. IaaS V2 VM in Azure: Azure Disk Encryption works only on IaaS V2 VMs (virtual machines created using the Azure Resource Management model). Please refer to Different ways to create a Windows virtual machine with Resource Manager for information on how to create IaaS V2 virtual machines in Azure. Please create a VM in the same region as the Key Vault. Latest gallery images in Azure are optimized to finish the encryption operation quickly. So it is recommended to create VMs using the latest gallery images.

Using a key encryption key to further secure data encryption secrets

By following the instructions in our earlier post, you would have been able to enable encryption on your IaaS VMs. Let’s take it a step further and use a key encryption key (KEK) to further secure your data encryption secrets. Azure Disk Encryption lets you specify an existing key in your Key Vault to wrap disk encryption secrets that were generated while enabling encryption. When a key encryption key is specified, Azure Disk Encryption uses that key to wrap the encryption secrets before writing to Key Vault. We’ll try this on another VM that was not encrypted earlier.

Let’s initialize some variables that are required to enable encryption on a VM and use a key encryption key.

Note: 
The key encryption key (KEK) must have been created in the same key vault where the disk encryption secrets are placed. Please refer to the article Getting Started with Azure Key Vault to learn how to create keys in Key Vault.

$rgName = 'MySecureRg';

$vmName = ‘ExtraSecureVM’;

$aadClientID = <your-aad-client-id>;

$aadClientSecret = <your-aad-client-secret>;

$KeyVaultName = 'MySecureVault';

$keyEncryptionKeyName = 'MyKeyEncryptionKey';

$KeyVault = Get-AzureRmKeyVault -VaultName $KeyVaultName -ResourceGroupName $rgname;

$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;

$KeyVaultResourceId = $KeyVault.ResourceId;

$keyEncryptionKeyUrl = (Get-AzureKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName).Key.kid;

Next, set the Key Vault access policies to allow the specified Azure AD application to write secrets to Key Vault:

Set-AzureRmKeyVaultAccessPolicy -VaultName $KeyVaultName -ServicePrincipalName $aadClientID -PermissionsToKeys all -PermissionsToSecrets all -ResourceGroupName $rgname;

Once the policies have been defined, the Azure fabric needs to access encryption secrets in order to boot the encrypted VM. Use the below cmdlet to set Key Vault access policies to allow Azure platform access the encryption secrets placed in the Key Vault:

Set-AzureRmKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $rgname –EnabledForDiskEncryption

Now we’re all set to enable encryption on the given VM and use a key encryption key to wrap the disk encryption secrets. Important:  We advise you to save your work before running this cmdlet. This cmdlet uses the variables initialized above. We also recommend that you create IaaS VMs using the latest gallery images to quickly enable encryption.

Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $rgname -VMName $vmName -AadClientID $aadClientID -AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId -KeyEncryptionKeyUrl $keyEncryptionKeyUrl -KeyEncryptionKeyVaultId $KeyVaultResourceId;

If you would like to learn more about capabilities in this area, please refer to the Set-AzureRmVmDiskEncryptionExtension cmdlet for full list of options and details. Once you have enabled and deployed an encrypted VM, the Get-AzureRmVmDiskEncryptionStatus cmdlet displays the encryption status of the OS volume, data volumes and the encryption secret Key Vault URLs of OS volume:

Get-AzureRmVmDiskEncryptionStatus  -ResourceGroupName $rgname -VMName $vmName

Based on the above, you should be able to see that both the OS volume and the data volumes are now encrypted. The OS volume encryption settings also show the key encryption key information in addition to disk encryption key information as shown below.

OsVolumeEncrypted          : True

OsVolumeEncryptionSettings : {

                               "DiskEncryptionKey": {

                                 "SecretUrl": "https://mysectestvault.vault.azure.net/secrets/36606F9D-07D9-4E68-8087-79277C83AAC2/36e832facb2f4e38990b107e03d27189",

                                 "SourceVault": {

                                   "ReferenceUri": "/subscriptions/0ee9d577-9bc4-4a32-a4e8-c29981025378/resourceGroups/MySecureRg/providers/Microsoft.KeyVault/vaults/MySecTestVault"

                                 }

                               },

                               "KeyEncryptionKey": {

                                 "KeyUrl": "https://mysectestvault.vault.azure.net/keys/Testkek/9dfdb7ca054746e48eb4dda11d108faf",

                                 "SourceVault": {

                                   "ReferenceUri": "/subscriptions/0ee9d577-9bc4-4a32-a4e8-c29981025378/resourceGroups/MySecureRg/providers/Microsoft.KeyVault/vaults/MySecTestVault"

                                 }

                               }

                             }

DataVolumesEncrypted       : True

Using an AAD client certificate instead of client secret

So far we’ve used an AAD client secret to authenticate to AAD and write encryption secrets to key vault. For security conscious users who don’t want the client secrets to be hard coded or leaked inside your script files, Azure Disk Encryption supports AAD client certificate based authentication. In this section we’ll walk you through how to use AAD client certificate credentials while enabling encryption. Please create a fresh VM or use an existing VM that wasn’t encrypted earlier for the below steps.

In order to use certificate based authentication, first a certificate needs to be created and associated with the AAD application. Install the Azure AD PowerShell module and follow the examples in the documentation of the New-MsolServicePrincipalCredential cmdlet to associate a certificate with an existing AAD application. 

After the certificate is associated with the AAD application, the private certificate (.pfx) needs to be uploaded to your key vault and deployed to the local machine’s ‘My’ certificate store in the VM. We do this so that the Azure Disk Encryption VM extension can consume the certificate deployed to the VM and authenticate to AAD and be able to write secrets to Azure Key Vault. Follow the steps in Deploy Certificates to VMs from customer-managed Key Vault to do this. You can also use the Add-AzureRmVMSecret followed by the Update-AzureRmVM cmdlets to deploy the certificate to the VM after it’s uploaded to Key Vault.

Ok, now that the certificate is associated with the AAD application and the .pfx file is deployed to the VM, we will initialize few more variables in addition to the variables initialized in the above section to enable encryption on the given VM.

$anotherVM = ‘SuperSecureVM’;

$certPath = 'C:\myaadapp.cer';

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2;

$cert.Import($certPath);

$aadClientCertThumbprint = $cert.Thumbprint;

Now we’re all set to enable encryption on the given VM using the AAD client certificate credentials and use a key encryption key to wrap the disk encryption secrets.

We advise you to save your work before running this cmdlet. This cmdlet uses the variables initialized above. We also recommend that you create IaaS VMs using the latest gallery images to quickly enable encryption.

Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $rgname -VMName $anotherVM -AadClientID $aadClientID -AadClientCertThumbprint $aadClientCertThumbprint -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId -KeyEncryptionKeyUrl $keyEncryptionKeyUrl -KeyEncryptionKeyVaultId $KeyVaultResourceId;

Please refer to the Set-AzureRmVmDiskEncryptionExtension cmdlet for full list options and details.

Encrypting newly attached data volumes

Once you have successfully enabled encryption on the OS and data volumes of a VM, you may want to attach additional data disks and enable encryption on the volumes in the attached data disk. Once the encryption operation is successfully performed on a given VM, in order to trigger the encryption operation again, a new sequence version (different from the previous) should be used. Following steps demonstrate how to do that.

First follow the steps here to attach a data disk to a VM and create volumes on the data disk. Azure Disk Encryption is a volume based encryption solution so it’s important to create volumes on new data disks to be able to encrypt them.  We will now initialize some variables:

$anotherVM = ‘SuperSecureVM’;

$sequenceVersion = [Guid]::NewGuid();

Now we’re all set to enable encryption on the data volumes in the newly attached data disks using the following command:

Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $rgname -VMName $anotherVM -AadClientID $aadClientID -AadClientCertThumbprint $aadClientCertThumbprint -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId -KeyEncryptionKeyUrl $keyEncryptionKeyUrl -KeyEncryptionKeyVaultId $KeyVaultResourceId –SequenceVersion $sequenceVersion

We hope you’ve enjoyed this update  and are able to use the advanced capabilities provided by Azure Disk Encryption. Please let us know if you have any feedback by adding a comment below.  We’ll work hard to meet your needs for additional content, tips and tricks in the future!

Sudhakar Evuri
Senior Software Engineer, Azure Security engineering

Azure Disk Encryption enables you encrypt the virtual disk files for the virtual machines that you host in Microsoft Azure. This is a great capability because it makes the virtual disks virtually unreadable if they are lost or stolen.

Also, if you use Azure Security Center (and we hope you do!), you will receive a security alert for any virtual machines that you have not encrypted. We highly recommend that you encrypt your virtual disks, and we make that clear with the Azure Security Center alert.

That said, you need to perform the virtual disk encryption using the “right” version of PowerShell. Please use the latest version of Azure PowerShell SDK version to configure Azure Disk Encryption. Download the latest version of Azure PowerShell version 1.2.1. Azure Disk Encryption is NOT supported by Azure SDK version 1.1.0.

To determine the version of Azure PowerShell you’re using, you can use the get-module cmdlet:

PS C:\> import-module azure
PS C:\> get-module azure

ModuleType  Version   Name        ExportedCommands
———-      ——-    —-           —————-
Manifest        1.2.1       azure        {Add-AzureAccount, Add-AzureApplicationGatewaySslCertificate..

If you use Azure PowerShell 1.1.0, you will see the following error:

ErrorMessage: VM has reported a failure when processing extension ‘AzureDiskEncryption’. Error message: “Failed to configure bitlocker as expected.
Exception: Expecting state ‘Element’.. Encountered ‘Text’  with name ”, namespace ”. , InnerException: , stack trace:   
at Microsoft.WindowsAzure.GuestAgent.Plugins.JsonExtensions.JsonSerialization.JsonSerializationHelpers.DeserializeJsonStringFromFile[T](StringfileName, ILogger logger)  
at Microsoft.Cis.Security.BitLocker.BitlockerIaasVMExtension.Settings.BitlockerExtensionSettings..ctor(HandlerEnvironment environment, ILoggerlogger)
at Microsoft.Cis.Security.BitLocker.BitlockerIaasVMExtension.BitlockerExtension.InitializeExtension()
at Microsoft.Cis.Security.BitLocker.BitlockerIaasVMExtension.BitlockerExtension.OnEnable()”.

Workaround:

Use a previous version of Azure PowerShell:

1. Uninstall the current version of Azure PowerShell by going into Control Panel, then Programs and Features, and uninstall Microsoft Azure PowerShell (version 1.1.0)
2. Install Azure PowerShell 1.2.1 by using the Windows Standalone.

Please let us know if you run into any issues with Azure Disk Encryption. We closely monitor the comments section below if you would like to ask here. Or, if you prefer, we also monitor the Azure Disk Encryption MSDN forum.

Thanks!

Tom

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

Prior to joining Microsoft, I was a Microsoft customer for about 15 years. I started with DOS, moved on to Windows 3.x, NT, Windows 2000 and everything after that – and then to the cloud.

During that time as a Microsoft customer, I often (really often!) thought about the things that Microsoft could do to make their products better.

I’m sure it’s the same for you. You work with Microsoft products, and if you’re reading this blog post, probably use a fair share of Azure services. Hopefully, you’re using Azure Security Center and seeing the things that it can do to help secure your Azure services.

As you’ve used Azure Security Center, have you thought about how YOU would make it better? What kind of things have you run into where you thought “hey, Microsoft really needs to do this!” or “Azure Security Center would be so much more useful if it could do that”.  We want to know!

Head on over to the Azure Security Center feedback site and let us know your ideas for making Azure Security Center better. Also, check out the ideas that other Azure Security Center users have shared – you might want to vote for one of those!

Thanks!

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

Just a quick FYI to the Azure Security community.

The Azure Disk Encryption white paper has been updated!

Some of the changes you’ll find there pertain to the Azure PowerShell version that you should be using.

We recommend that you use version 1.2.1.

Read the white paper for more information.

Thanks!

Tom

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

Managing data and services requires us to keep security of company data top-of-mind at all times. It doesn’t matter if you’re on-premises, in the cloud, or hybrid – if you don’t start with security, life is going to get complicated.

A new set of powerful tools from Microsoft Azure known as the Azure Security Center can help organizations do just that for your cloud-based infrastructure.

Tune in as Kevin Remde, Yuri Diogenes and myself walk us through the Azure Security Center from what it is, why you should use it and how to get started.

• [2:57] What is the Azure Security Center?
• [5:02] Who is the target audience for the Azure Security Center?  Why should we use it?
• [7:01]  Does Azure Security Center protect me from specific threats?
• [8:20]  How does Azure Security Center fit with Microsoft’s "assume breach" approach to security?
• [11:34] DEMO: Azure Security Center
• [25:48] Looks like some good resources.  How much does it cost?

Want to learn more about Azure Security Center? Then head on over to the Azure Security Center documentation site.

(BTW – you get 5 social credits for noticing the “Internet Security and Acceleration Server 2004” label on my fleece)

Thanks!

Tom

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

Hello Azure security community!

Yuri Diogenes (CSI Enterprise Mobility and Azure Security team) here. Recently we updated our Microsoft Antimalware for Azure Cloud Services and Virtual Machines article and had some interesting discussions regarding Azure antimalware on ARM VMs.

While our original article has many examples for antimalware deployment using PowerShell, scripts for ARM VMs were not provided.

With the great assistance of Rakesh Narayan, Azure Security PM the following sample script was developed to fill this gap:

You can also add a config file by using the line below:

Get-AzureVM -ServiceName $service -Name $name | Set-AzureVMMicrosoftAntimalwareExtension -AntimalwareConfiguration $config_string

Note:
The JSON configuration file can be customized using this article from MSDN

After deploying the antimalware using Set-AzureRmVMExtension, the antimalware user interface (UI) will not be available for the end user. As part of its setup, the Azure Antimalware extension modifies the policy to explicitly turn off the UI within the virtual machine.

This was an explicit design decision made for the Azure environment. The intent is to avoid modal dialogs and popups surfacing on unattended service machines. If you try to modify the antimalware settings via UI you may receive the following error message:

Important:
Changing the cleanuppolicy.xml file to bypass this error message is not a supported action.

Kudos also to Milind Pawar and Eric Jarvi for their contribution on this case.

Microsoft and other software and hardware vendors have dedicated significant resources over the last decade to develop more secure solutions for their customers. These efforts were driven by the increasing sophistication of the people attacking information systems. The threat environment has evolved over time and the industry has had to respond to those changes.

DOWNLOAD THE MICROSOFT CLOUD RED TEAM WHITE PAPER

This suggests that we need to consider expanding the focus of our security efforts. We need to respond to new pervasive attack methodologies that present themselves as persistent threats to our IT infrastructure and information assets.

Given the possibility that your IT infrastructure is at risk of being breached without your awareness, it could be productive to reevaluate how you prioritize your security solutions and investments. You might want to look at what value could come from devoting more of your resources to detecting and responding to breaches of your high-value assets versus trying to prevent attacks.

Security in a world where we assume a breach may have already taken place without our knowledge leads to a completely different mindset.

This is where Red Teaming becomes quite valuable. Red Teaming is above and beyond compliance accreditations or other industry requirements and provides Microsoft, and our customers, with the additional assurance that Microsoft cloud services are continuously performing security monitoring, testing, and updates to reflect the constantly changing threats that both customers and Microsoft face.

Microsoft conducts wargame exercises and regular Red Teaming to evaluate and improve Microsoft’s Assume Breach readiness. Through the modeling of real-world attacks as well as penetration tests, Microsoft can test its ability to handle attacks, identify gaps in detection and response and focus resources to address those gaps. By practicing security incident response, performing continuous monitoring, forensics and recovery, Microsoft strives to develop the critical capabilities needed to deal with breaches.

Learn more about Microsoft’s approach to assume breach and how Red Teaming is a key component of an assume breach attitude by reading the Microsoft Cloud Read Team white paper.

Thanks!

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

Last week on the Azure Blog Sarah Fender announced a collection of very cool new capabilities for Azure Security Center. There’s something for everyone there! One that caught my attention was the new ability to use Power BI to get even more visibility into the security state of your Azure deployments.

If you’re new to Azure (or even if you’re not new), you might not have heard of Power BI. From a high level, Power BI is a collection of analytics tools that are able to dig into data from multiple sources to give you interesting and intuitive dashboards that make it easier for you to interpret the information. You can also create nice looking reports to make the data "pop" and get the right points across.

This is what makes Power BI so useful in the context of Azure Security Center. Power BI gives Azure Security Center even more flexibility and customization so that you can see the things that are important to you. You can also connect information from other data sources, such as Azure Audit Logs and Azure SQL database audit logs to create visual correlates. And if you’re a friend of Excel, you can export all this information and import it into an Excel spreadsheet.

Azure Security is at RSA this this week!
If you’re at RSA, look up Sarah and learn more about Azure Security Center

Let’s see what it looks like!

First, you need a Power BI account. If you already have one, then continue on in the Azure portal. If not, use the Get started free link on Power BI page to sign up.

When you go into Azure Security Center from within the Azure portal, you’ll notice that there’s a "button" in the console that says Explore in Power BI

When you click that button you’ll be asked for what subscription you want to see in Power BI. You’re then given an opportunity to copy your subscription ID to the clipboard (which is a nice convenience). You then click the Go to Power BI link and log into Power BI.

When you get there, you’ll see the following – click Connect.

You’ll be asked to perform some authentication (make sure you use oAuth2) steps.

After you log in, the dashboard will be built and when complete, you’ll see something like this:

(click the picture to see it full size)

At the top you can see a summarized view of Security Alerts, Recommendations, Protected VMs, Protected SQL (shows "blank" because I don’t have any Azure SQL instances in this subscription), and Protected Network Resources.

There are default tiles that provide you information on Resource Security Health, Pending Recommendations Overall, VM Recommendations, Alerts over Time, Attacked Resources, and Attacker IPs.

There’s a lot of information here, and you can drill down by hovering over or clicking just about any element in the graphs. Let’s take a closer look at the Attacker IPs.

Click on an empty space in the Attacker IPs tile.

(click on the graphic to see a full view)

Here you can see:

• Alerts over time by # of Alerts and Different Attackers IPs – this is great to see attack trends
• Attacker IP by # of Compromised Entities, # of Attacks Detected, and # Of Attack Days Detected – this is useful to see where the attacks are coming from and to get a visual impression on who might be the major offenders
• Attacked Resources – lets you easily see what resources are most impacted by the attacks

If you hover over any of the bars in the graph you will see more information about that bar, and if you click the bar, you will see drill-down information, such as seen in the figure below.

(click the graphic to see the full figure)

As you can see, there’s a ton of information available in the Power BI presentation of your Azure Security Center data. I hope I was able to whet your appetite for more information on Azure Security Center integration with Azure Security Center!

To learn more about Power BI integration with Azure Security Center, check out the article Get insights from Azure Security Center data with Power BI.

Thanks!

Tom

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

What’s better than reading about Azure Security Center?

Listening to a radio show about Azure Security Center.

What’s better to listening to radio show about Azure Security Center?

Watching a video about Azure Security Center on Microsoft Mechanics!

In this video, Ryan McGee, Product Manager in Cloud Platform, takes us on a whirlwind trip around the Azure Security Center console and peppers the conversation with useful tips and tricks that will help you get a leg up on the system.

Check it out!

Thanks!

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

What’s better than reading about Azure Security Center?

Listening to a radio show about Azure Security Center.

What’s better to listening to radio show about Azure Security Center?

Watching a video about Azure Security Center on Microsoft Mechanics!

In this video, Ryan McGee, Product Manager in Cloud Platform, takes us on a whirlwind trip around the Azure Security Center console and peppers the conversation with useful tips and tricks that will help you get a leg up on the system.

Check it out!

Thanks!

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

The Microsoft Service Trust Portal is the place to go when you need audit reports on Microsoft Cloud Services, which includes our personal favorite, Microsoft Azure.

The Service Trust Portal doesn’t only give you audit reports, though. It also has information about risk assessments, security best practices, and more!

What more?

Check these out:

• SOC1 and SOC 2 auditor reports
• ISO 27001 and 27018 audit reports and scope statements
• Office 365 Information Security Management System (ISMS) guidance
• Federal Risk and Authorization Management Program (FedRamp) System Security Plan
• Governance, risk management, security assessment, and compliance white papers, FAQs, and other materials to help you perform your own risk assessment

Sound good? I thought so!

Head on over to the Microsoft Trust Center and learn more on how you can get access to all this information and more at the Microsoft Service Trust Portal.

Thanks!

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

There are a number of security measures you want to take when deploying virtual machines in any public (and private) Infrastructure as a Service (IaaS) solution.

Some of these include:

• Hardening the guest operating system
• Enabling and configuring a host-based firewall and IDS
• Configuring the appropriate user accounts and removing or disabling default accounts
• Removing or disabling unnecessary services
• And more…

That list should look pretty familiar, since it’s what we’ve done with on-premises physical and virtual machines for years. One thing not on that list is encrypting operating system and data disks. While this is something that we should do on-premises, it’s not always seen as imperative because we trust our on-premises systems (maybe a little too much?).

We realize that security is a concern in public cloud deployments, so you are more likely going to implement extra security measures. One of those security measures is encrypting the operating system and data disks in the Azure Virtual Machines.

The question is – how do you know if your Azure Virtual Machines are encrypted? Is there an easy way for you to visually determine what Azure Virtual Machines are encrypted and which are not encrypted?

YES. The answer is Azure Security Center.

When you use Azure Security Center, you can easily see which virtual machines are unencrypted and you are alerted to that fact. Just check out the figure below.

Encrypting virtual machines is easy. If you’re new to Azure and Azure PowerShell, we have a simple script that you can use to encrypt your virtual machines. The article Encrypt an Azure Virtual Machine walks you step-by-step and assumes that you know nothing about PowerShell or scripting. If you’re an accomplished PowerShell pro or programmer, then you might want to flex your command line muscles by reading the Azure Disk Encryption white paper and customizing your encryption.

Learn more about Azure Security Center by heading over to the Azure Security Center documentation hub – and make sure to keep a close eye on the Azure Security and Compliance blog!

Thanks!

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

Hello Azure security community!

Yuri Diogenes (CSI Enterprise Mobility and Azure Security team) here. In our blog post Microsoft Antimalware and Azure Resource Manager (ARM) VMs, we clarified some issues regarding Microsoft Antimalware deployment using PowerShell for ARM VMs and the supportability question regarding accessing the antimalware user interface (UI) post deployment.

As stated in that article, changing the cleanuppolicy.xml file to bypass this error message is not supported. However, you can create a custom policy in the VM itself if you want to enable the UI in the virtual machine.

If your company needs access to the UI in the virtual machine, you can create a custom policy using the example below:

<?xml version=”1.0″ encoding=”utf-8″?> <SecurityPolicy

   xmlns=”http://forefront.microsoft.com/FEP/2010/01/PolicyData”

   Name=”Microsoft Antimalware UI”

   Version=”1″

   Description=”Enables the UI for Azure Antimalware. This policy is applicable to Windows 2008 R2, Windows 2012, Windows 2012 R2.”

   IsBuiltIn=”0″

   CreatedBy=”Microsoft”

   LastModifiedBy=”Microsoft”

   >

  <PolicySection Name=”SCEP.ConfigPolicy”>

    <LocalGroupPolicySettings>

      <!—- Configure UILockdown policy key to show UI, since default is no UI—->

      <AddKey Name=”SOFTWARE\Policies\Microsoft\Microsoft Antimalware\UX Configuration” Disabled=”false”>

<AddValue Name=”UILockdown” Type=”REG_DWORD” Disabled=”false”>0</AddValue>

      </AddKey>

    </LocalGroupPolicySettings>

  </PolicySection>

</SecurityPolicy>

After creating this policy and applying, run gpupdate /force to update the local policies as shown in the example below:

D:\Program Files\Microsoft Security Client>ConfigSecurityPolicy.exe newpolicy.xml

Microsoft Security Client successfully applied policy: “Microsoft Antimalware UI”.

D:\Program Files\Microsoft Security Client>gpupdate /force

Updating Policy…

User Policy update has completed successfully.

Computer Policy update has completed successfully.

Certain Computer policies are enabled that can only run during startup.

OK to Restart?. (Y/N)

Please reboot the virtual machine to ensure the change has been applied if you are still seeing the same pop up error message.

This is a supported workaround procedure for companies that need to have access to the antimalware UI post deployment.

Kudos to Rakesh Narayan and ASM Team for their contribution testing this solution.

Hello Azure security community! Today’s blog post on anomaly detection systems is brought to you by Ram Shankar Siva Kumar from Azure Security Data Science, in collaboration with Andrew Wicker, Dan Mace and Kaidi Zhao.

The CISO of one of the premier National Labs in the country, said he is going to level with us: The lab invested millions of dollars on a bespoke security anomaly detection system that was built ground up, by their cream of the crop data scientists and sadly, the system did not yield any useful alerts. The false positive rates were just too high and for all intents and purposes, the security analyst team was being sent on a goose chase. The CISO and his team wanted to know how Azure Security Data Science, my team, would handle the alert deluge and what can we tell them from our experience, to help them whittle down the false positive rate, so that they can focus on catching attacks.

As a Data Cowboy in Microsoft’s cloud Security data science team, the stories I hear on anomaly detection systems from customers follow a particular pattern: an organization invests in SIEM, and then hires data scientists to build advanced detections from the gathered data only to find that the team of security analysts are unhappy with the results. There is more than disgruntled analysts at stake: a recent study by the Ponemon Institute[1], showed that organizations spend, on average, nearly 21,000 hours each year analyzing security false positives, wasting roughly $1.3 million per year due to inaccurate or erroneous intelligence. The immediate reaction is to invest in a newer, more complex algorithm that can reduce the false positive rate and surface better anomalies which threat analysts might not agree with.

This blog post has three takeaways:

1. The end goal of security anomaly detection systems should not be to produce anomalies but actionable security alerts, that are useful i.e. interpretable, credible and elicit downstream action
2. Increasing the complexity of the algorithm without actually instilling security domain knowledge has little effect on false positive rates
3. A framework to show how to go from noisy outliers to the end goal of security, so that you can make an honest assessment of your anomaly detection system to see where you fit in.

Before we build an anomaly detection system, we enforce the following constraints to consider the result to be “useful”

1. Interpretable: Every security risk we alert or report on must be explainable. For instance, it is not sufficient to say a process running on the host is anomalous. Instead, the detection system should alert that it has detected PowerShell.exe running in the App folder.
2. Credible: The analyst must trust in the result, when he receives additional contextual information the alert. Continuing the anomalous process creation example, the IT admin may receive the command line arguments that were passed when PowerShell was invoked.
3. Actionable: When results are interpretable and credible, they are more likely to lead to downstream action. Depending on the severity of the incident, this could be anything from rolling the credentials to getting forensics artifacts from the host machine.

Now using “Usefulness” as a dimension of comparison, our experience with anomaly detection systems can be summarized as follows:

• Blindly increasing the complexity of the system, without much security domain knowledge, does not increase the utility of the end results
• The biggest game changer happens, when we can get constant feedback from the security experts which in turn helps the data scientists to refine their behavioral detection at each step.

The following table shows how based on the complexity of the behavioral anomaly detection system and the amount of security knowledge that is instilled, we can have three different types of security alerts i.e. outliers, anomalies and “security interesting”. We chose to illustrate the table with a case of detecting suspicious activity based on login failure records alone. In practice, this could be done by monitoring the 4625 event id in the Windows Security Event Logs.

Type	Description	When to use?	Persona Involved	Example	Drawback
I: Outliers	Basic anomaly detection methods like standard deviation, and no domain information	Suitable for areas where domain knowledge is sparse and security risks are uncertain.	There is no security person involved, at this point in time ML knowledge is informal at best.	E.g: Alert when the number of failed logins deviates from three times the baseline.	Not all deviations from normal behavior are anomalies! Because of limited security domain knowledge, the system, has high False positive rate.
II: Anomalies	Increased complexity of the anomaly detection along with limited domain information.	Domain information is limited to rules or filtering of the initial data.	There is minimum interaction with Security analyst ML knowledge is more holistic and complete.	Domain Expert: “If there is an unusually high failed logins during night time, that activity is more anomalous” Anomaly Detection System: Use Holt Winters to detect seasonality of logins, and alert when patterns don’t conform to trends.	Not all anomalies are security interesting! For e.g: There may be a high number of failed logins owing to an expired credential. While this is a legitimate finding, it is a “hygiene” issue as opposed to indication of attack
III: Security Interesting Events	Focused anomalies. Requires user feedback and supervised signals to provide more focused analysis. May be based on user preferences, and different for each user.	Anomalies plus intrinsic and extrinsic signals. Additional domain information may be domain expert annotations, feedback, or prioritized heuristics.	There is a strong partnership with Machine Learning and Security Experts	Domain Expert: Provides feedback on the quality of the results Anomaly Detection System: Uses Active learning systems on top of traditional anomaly detection systems to capture the domain expert’s feedback to improve the system

What next?

• Use the framework listed above to identify if your alerts are outliers, anomalies or security interesting. You can then use the grid to evolve your results to the end goal of actionable, credible and interpretable results.
• So what does an algorithm that generates useful security alerts look like, and how does one go about building such an algorithm? Stay tuned for additional blog posts delving into these topics.

[1] http://www.ponemon.org/local/upload/file/Damballa%20Malware%20Containment%20FINAL%203.pdf

Today Microsoft announced that it has published it’s 2016 Attestation of Compliance in the Microsoft Trust Center.

Several services were added to Microsoft’s attestation, some of which are:

• Identity and access management, such as Azure Rights Management
• Analytics services, such as HDInsight
• Management and security services like Key Vault and our new Management portal
• Data services, such as Redis Cache or Redis Cache premium
• Database solutions like SQL Data Warehouse and Azure Storage Premium

There is also an expanded list of PCI-certified regions.

For more information, please see Alice Rison’s post Microsoft Payment Card Industry (PCI) Data Security Standards (DSS) revised for 2016 in the Azure Blog.

Thanks!

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

More great news in the Microsoft cloud compliance space!

Microsoft has received Cloud Security Mark (Gold) Accreditation.

Alice Rison reports on the Azure.com blog that her team worked closely with the Japan Information Security Audit Association (JASA) and the Ministry of Economy, Trade, and Industry (METI) to obtain the new certification that is based on the ISO/IEC 27017 standard.

The CS Mark promotes the use of cloud services and provides:

• A common standard that CSPs can apply to address common customer concerns about the security and confidentiality of data in the cloud and the impact on business of using cloud services.
• Verifiable operational transparency and visibility into the risks that customers face when they use cloud services.
• Objective criteria that enterprises and government can use to choose a CSP, and clarification of the security requirements that CSPs must follow to be accredited

As of February 10, 2016 – CS Mark accreditations have been received for:

• Microsoft Azure Infrastructure as a Service (IaaS)
• Microsoft Azure Platform as a Service (PaaS)
• Microsoft Office 365 (SaaS)

To learn more, check out Alice’s post Microsoft first global CSP to receive the Cloud Security Mark (Gold) accreditation.

Thanks!

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

If you had the chance to read the Microsoft Red Team whitepaper, you know that Microsoft Azure and the rest of the Microsoft cloud focuses on preventing and detecting breaches. Preventing breaches is what we’ve all been doing for decades, and we should continue to do the things we’ve been doing to make it harder for attackers to gain access to our systems and data.

With that said, we realize that trying to prevent breaches is not enough. You know that, and we know that – all you need to do is read a newspaper (or visit a news site) and see the “breach of the day”. Microsoft understands that while we can do all we can think of to prevent breaches, it’s possible that they will occur and therefore we need to assume that a breach is extant or imminent and define security policies, procedures, and response and remediation plans so that we can minimize the attacker’s lateral movement through the system and contain the breach before the attacker can do damage or steal data.

Microsoft spends a lot of time, money and effort to understand how attackers breach networks and data and we use that knowledge to help us detect potential compromise and eject the threat. We think you might find that information useful too, so I’d like to invite you to view a webinar put together by our Enterprise Cloud Security Group titled Anatomy of a breach: How hackers break in.

In this webinar you’ll learn:

• Common ways hackers get into your network, including phishing scams and targeted search results
• How hackers set up and manage long-term attacks
• Things you can do today to help prevent an attack
• The key response phases, including incident response, tactical recovery and strategic recovery
• Tips for developing an effective communications plan that won’t compromise your data’s security

I hope you enjoy Anatomy of a breach: How hackers break in and we look forward to discussing the presentation with you on this blog.

Thanks!

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

To help you comply with national, regional, and industry-specific requirements governing the collection, storage and use of controlled data, Microsoft offers a comprehensive set of certifications and attestations. Microsoft enterprise cloud services are independently validated through certifications and attestations, as well as third-party audits. You can see a comprehensive list of Microsoft certifications in the Compliance section of the Microsoft Trust Center.

With that said, I’d like to share some good news for our Azure Government customers. In the last few weeks we’ve heard a lot of you ask if we could keep you up to date on the release of Azure services to the Azure Government cloud. Your wish is our command!

Check out these services that are now available in Azure Government:

• Azure App Service: Web Apps
• Azure Key Vault
• D-Series Azure Virtual Machines for Azure Virtual Machines (Azure IaaS), Azure Cloud Services, and web/worker roles
• Azure Site Recovery
• Azure Automation
• Azure Backup
• Azure Role-Based Access Control Preview using Azure PowerShell

For more information and details on these new services in the Azure Government cloud, check out Matt Rathbun’s article Microsoft Cloud for Government extends leadership in compliance with FedRAMP High, CJIS expansion and DISA Impact Levels 4 and Level 5 investments on the Azure Blog.

To experience the power of Azure Government for your organization, sign up for an Azure Government Trial.

Thanks!

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

Hello Azure security community!

Yuri Diogenes (CSI Enterprise Mobility and Azure Security team) here. Recently we updated our Managing and responding to security alerts in Azure Security Center article to add more details regarding alerts for suspicious activities. When the Azure Security Center attack detection mechanism triggers an alert, it will show you which resource was attacked and it will provide more information about the attack.

The below is an example of what you might see:

In this particular attack, the AppServer resource was attacked using the free tool FreeRDP. Several logins (30 to be more precise) were attempted in the last 19 hours. This is a useful information and you can follow the recommendation steps to mitigate this attack.

However, in some cases the SOURCE field is empty. There’s no IP address, no utility name nor DNS name.

This occurs for the same reason that security event ID 4625 in the Windows operating system sometimes doesn’t provide the source network address as shown in the example below (notice these fields):

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 3/25/2016 1:39:56 PM

Event ID: 4625

Task Category: Logon

Level: Information

Keywords: Audit Failure

User: N/A

Computer: BYATACE

Description:

An account failed to log on.

Subject:

Security ID: SYSTEM

Account Name: BYATACE$

Account Domain: WORKGROUP

Logon ID: 0x3E7

Logon Type: 10

Account For Which Logon Failed:

Security ID: NULL SID

Account Name: Administrator

Account Domain: BYATACE

Failure Information:

Failure Reason: Unknown user name or bad password.

Status: 0xC000006D

Sub Status: 0xC000006A

Process Information:

Caller Process ID: 0xed0

Caller Process Name: C:\Windows\System32\winlogon.exe

Network Information:

Workstation Name:

Source Network Address: 0.0.0.0

Source Port: 0

Detailed Authentication Information:

Logon Process: User32

Authentication Package: Negotiate

Transited Services: -

Package Name (NTLM only): -

Key Length: 0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The Detailed Authentication Information fields provide detailed information about this specific logon request.

• Transited services indicate which intermediate services have participated in this logon request.
• Package name indicates which sub-protocol was used among the NTLM protocols.
• Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

This information is not always available because not every code path in Windows is instrumented for IP address collection or recording. You can also refer to this site for more information about this event.