Microsoft Azure Security and Compliance

Certificate Transparency

Thomas W Shinder - MSFT — Wed, 25 Apr 2018 13:57:55 GMT

Certificate Transparency (CT) is a new Internet standard that addresses the concern of mis-issued certificates and certificate repudiation by making the Transport Layer Security (TLS) ecosystem publicly auditable. Without CT, as a domain owner, there was no way to be aware of certificates issued to your domain by the various public CAs, unless you yourself requested it from each CA. With CT it is easy to audit the quality of the certificates that certificate authority (CA) issued and determine if they conform to the standards enforced by the CA and Browser Forum (CAB Forum). https://tools.ietf.org/html/rfc6962 Google Chrome is one of the first browsers to enforce from April 30^th 2018 onwards that every TLS/SSL certificates are in approved CT logs in order for it to be trusted. Soon other browsers are going to adopt the same standard. Google Chrome browser will require a signed certificate timestamp (SCT) in order to trust the certificate without displaying an error message. SCT confirms the log server will add the certificate to the list of known certificates. https://groups.google.com/a/chromium.org/d/msg/ct-policy/wHILiYf31DE/iMFmpMEkAQAJ Microsoft supports the Certificate Transparency initiative, and all certificates issued to Microsoft properties will contain SCT extension from April 12^th onwards. Microsoft’s CT support includes the following:

Microsoft CA or Active Directory Certificate Service (ADCS) now supports pre-certificates to facilitate CT logging. https://support.microsoft.com/en-us/help/4093260/introduction-of-ad-cs-certificate-transparency
Azure Key Vault supports enrollment of certificates from Digicert, GlobalSign and DTrust and these CAs have added the support to add SCT extensions in certificates issued by them.
At the same time we understand that there can be times when Azure customers do not want to have SCT extension in their certificate as it might lead to information disclosure of domain names. The above integrated CAs provides the capability at the account level to disable or enable CT logging.

Rashmi Jha Program Manager, Azure Key Vault

Azure Disk Encryption with EncryptFormatAll feature for Data disks on Linux IaaS VM

Devendra Tiwari, Principal PM Director, Azure Engg — Thu, 30 Nov 2017 20:10:45 GMT

In this blog, we will introduce you to the new Azure disk encryption feature parameter EncryptFormatAll. It is a new feature parameter to reduce encryption times for Storage backed data disks on Linux VMs. The EncryptFormatAll support is available starting with Azure PS SDK release 5.0.0 and Azure CLI 2.0.17 releases. When the Linux Disk Encryption extension is deployed with the EncryptFormatAll parameter, it will go through all the partitions and encrypt format each partition which:

Is not a root/OS/boot partition
Is not already encrypted
Is not a resource disk/BEK volume, and
Is mounted

The partition will be formatted with its current file system and will be remounted back to where it was before EncryptFormatAll was executed. If there is a data disk that you don’t want formatted and it happens to satisfy all the conditions above, you can exclude it from EncryptFormatAll by unmounting it. If you’re setting this option while updating encryption settings, it might lead to a reboot before the actual encryption. In this case, you will also want to remove the disk you don’t want formatted from the fstab file. Similarly, you should add the partition you want encrypt-formatted to the fstab file before initiating the encryption operation. NOTE: You should first try out the EncryptFormatAll first on a test VM, understand the feature parameter and its implication before trying it on the production VM. The EncryptFormatAll option formats the data disk and all the data on it will be lost. FAQ: Q. How do I test the EncryptFormatAll feature parameter using ARM template A. To test the EncryptFormatAll option, you may take any pre-existing ARM template that encrypts a Linux VM and change the following fields for the AzureDiskEncryption resource:

Change “EncryptionOperation” from “EnableEncryption” to “EnableEncryptionFormatAll”

Here is an example template that can be used to encrypt-format-all a running Linux VM: https://github.com/vermashi/azure-quickstart-templates/tree/encrypt-format-running-linux-vm/201-encrypt-running-linux-vm Q. How do I test the EncryptFormatAll feature parameter using Azure disk encryption PS cmdlet? A. You can use the Azure disk encryption 'Set-AzureRmVMDiskEncryptionExtension' cmdlet [see the Azure PS SDK release link above] with the ‘-EncryptFormatAll’ parameter to encrypt the data disk using the ‘-EncryptFormatAll’ parameter. Q. I have multiple data disks. How do I Encrypt-Format only some of them? A. EncryptFormatAll will skip all disks which are:

- OS or boot partitions - LVM/RAID disks - Already encrypted disks - Currently unmounted disks

You can unmount the disks you don’t want to encrypt-format during encryption. Note that the encryption process involves rebooting the VM, so you must also temporarily remove the disk from /etc/fstab. If you want to encrypt these disks without formatting them, you can run the encryption command again without the ‘-EncryptFormatAll’ switch. Q. How do I use EncryptFormatAll with LVM? A. We recommend an LVM-on-crypt setup. This can be done as follows:

- Add the data disks that will compose to the VM - Format, mount and add these disks to the fstab file

# For all the following examples replace the device-path and mountpoints with whatever suits your use-case. # Format the newly added disk. Note that we use symlinks generated by azure here mkfs -t ext4 /dev/disk/azure/scsi1/lun0* * The reason for doing this is to avoid problems related to device names changing. Please see this link for details - https://docs.microsoft.com/en-us/azure/virtual-machines/linux/troubleshoot-device-names-problems # Mount the disks mount /dev/disk/azure/scsi1/lun0 /mnt/mountpoint # Add to fstab echo "/dev/disk/azure/scsi1/lun0 /mnt/mountpoint ext4 defaults,nofail 1 2" >> /etc/fstab - Run the cmdlet with ‘-EncryptFormatAll’ to encrypt these disks # Enable encryption on the VM with ‘-EncryptFormatAll’ Set-AzureRmVMDiskEncryptionExtension -ResouceGroupName "myresourceGroup" -VMName "myVMName" -DiskEncryptionKeyVaultUrl "https://mykeyvault.vault.azure.net/" -EncryptFormatAll - Set up LVM on top of these new disks Note that currently, the encrypted drives are unlocked after the VM has finished booting. So, the LVM mounting will also have to be subsequently delayed.

Announcing Azure Disk Encryption Preview for Virtual Machine Scale Sets

Devendra Tiwari, Principal PM Director, Azure Engg — Thu, 28 Sep 2017 21:24:01 GMT

Today, we are excited to announce the public preview of Azure Disk Encryption (ADE) for Virtual Machine Scale Sets (VMSS). With this announcement, Azure disk encryption can be enabled for Windows and Linux VM Scale Sets in Azure public regions to enable customers to help protect and safeguard the Scale Sets data at rest using industry standard encryption technology. The solution is deployed in all Azure public regions. Additional details on supported and unsupported scenarios, interfaces and how you can use the disk encryption technology preview to encrypt your VM Scale Sets and validate your scenario is documented below.

Pre-Requisites:
1. Self-Registration - VMSS disk encryption preview requires self-registration in order to use
2. You can self register your subscription by running the following steps:
  1. Register-AzureRmProviderFeature -ProviderNamespace Microsoft.Compute -FeatureName "UnifiedDiskEncryption"
  2. Wait around 10 minutes until the state as 'Registered'. You can check the state by running the following command:
    1. Get-AzureRmProviderFeature -ProviderNamespace "Microsoft.Compute" -FeatureName "UnifiedDiskEncryption"
  3. Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Compute
3. Azure Key Vault - Create a KeyVault in the same subscription and region as the VMSS and set the access policy 'EnabledForDiskEncryption' on the KeyVault using its PS cmdlet. You can also set the policy using the KeyVault UI in the Azure portal:
  1. Set-AzureRmKeyVaultAccessPolicy -VaultName $keyVaultName -EnabledForDiskEncryption
Supported scenarios:
1. VMSS encryption is supported only for scale sets created with managed disks, and not supported for native (or unmanaged) disk scale sets
2. VMSS encryption is supported for OS and Data volumes for Windows VMSS. Disable encryption is supported for OS and Data volumes for Windows VMSS
3. VMSS encryption is supported for Data volume for Linux VMSS. OS disk encryption is NOT supported in the current preview for Linux
4. VMSS VM reimage and upgrade operations are not supported in current preview
  1. The VMSS ADE preview is recommended only as try out in test environment. Do not try out preview or use in production environments where you might need to upgrade your OS image in an encrypted scale set

Supported Interfaces:

Using ARM templates:
1. Enable ADE on Windows VMSS
  1. Create a Windows VM ScaleSet and enable encryption: 201-encrypt-running-vmss-windows
  2. Enable encryption on a running windows VM ScaleSet: 201-encrypt-vmss-windows-jumpbox
  3. Disable encryption on a running windows VM ScaleSet: 201-decrypt-vmss-windows
2. Enable ADE on Linux VMSS
  1. Create a Linux VM ScaleSet and enable encryption: 201-encrypt-running-vmss-linux
  2. Enable encryption on a running Linux VM ScaleSet: 201-encrypt-vmss-linux-jumpbox
  3. Disable encryption on a running Linux VM ScaleSet: 201-decrypt-vmss-linux

Using Azure PowerShell cmdlets: Install the latest version of Azure SDK from Azure PowerShell release. The following are the VMSS ADE cmdlets to enable (Set) encryption, retrieve (Get) encryption status and remove (disable) encryption on VMSS instance.

CommandType	Name	Cmdlet Version	Source
Alias	Get-AzureRmVmssDiskEncryptionStatus	3.4.0 or above	AzureRM.Compute
Alias	Get-AzureRmVmssVMDiskEncryptionStatus	3.4.0 or above	AzureRM.Compute
Cmdlet	Disable-AzureRmVmssDiskEncryption	3.4.0 or above	AzureRM.Compute
Cmdlet	Get-AzureRmVmssDiskEncryption	3.4.0 or above	AzureRM.Compute
Cmdlet	Get-AzureRmVmssVMDiskEncryption	3.4.0 or above	AzureRM.Compute
Cmdlet	Set-AzureRmVmssDiskEncryptionExtension	3.4.0 or above	AzureRM.Compute

Using CLI command: Install latest Azure CLI 2.0 which has the new encryption commands. The CLI commands example are included below:
1. Create VMSS az vmss create -g -n --instance-count 1 --image Win2016Datacenter --admin-username --admin-password
2. Enable encryption on VMSS instance az vmss encryption enable -g -n --disk-encryption-keyvault
3. Update VMSS instances az vmss update-instances -g -n --instance-ids
4. Show encryption status az vmss encryption show -g -n
5. Disable encryption (For Windows VMSS only) az vmss encryption disable -g -n
End to end batch file example for Linux scale set data disk encryption - This will creates resource group, VMSS, mounts a 5GB data disk, encrypts the Linux VM scale sets

For additional details on Azure Disk Encryption service, refer to ADE documentation here

Disabling Server Message Block Version 1 (SMB v1) in Azure

Thomas W Shinder - MSFT — Fri, 18 Aug 2017 13:34:51 GMT

Microsoft has always considered security to be priority #1. Whether it be in the cloud, on-premises, or across hybrid deployments, security is part of our DNA and we do whatever we can to help protect our customers and our platform. This is especially true when it comes to the Azure public cloud, where Microsoft has committed new energy, focus, and resources to make sure that we can protect, detect, and respond to threats better and faster than ever before.

Many of our customers have recently had to deal with the threat of ransomware attacks due to issues with the Server Message Block version 1 (SMB v1) protocol. While specific vulnerabilities were patched against the likes of WannaCrypt, the reality is that any Windows operating system with SMB v1 enabled is susceptible to this kind of attack. As such, we strongly believe that SMB v1 should be disabled – as it now has limited usefulness.

For this reason, the Azure security team has made the decision to disable SMB v1 by default on all Windows operating system images available in the Azure Marketplace for creating new Azure Virtual Machines, effective August 2017.

Note:
Disabling SMB v1 by default on new Azure Virtual Machines (VMs) that are created from Azure Marketplace Windows operating system images has no effect on existing VMs that are already running on Azure, or new Azure VMs based on customized images uploaded to Azure. Learn how to disable the SMB v1 protocol on already running virtual machines later in this article.

Which Windows Operating System Images will have SMB v1 ‘Disabled by Default’?

The following Windows operating system images now have SMB v1 disabled by default:

HPC Pack 2012 R2 Compute Node with Excel on Windows Server 2012 R2
HPC Pack 2012 R2 on Windows Server 2012 R2
Windows Server 2008 R2 SP1*
Windows Server 2012 Datacenter
Windows Server 2012 R2 Datacenter
Windows Server 2016 - Nano Server
Windows Server 2016 Datacenter
Windows Server 2016 Datacenter - with Containers
[HUB] Windows Server 2008 R2 SP1*
[HUB] Windows Server 2012 Datacenter
[HUB] Windows Server 2012 R2 Datacenter
[HUB] Windows Server 2016 Datacenter
[smalldisk] Windows Server 2008 R2 SP1*
[smalldisk] Windows Server 2012 Datacenter
[smalldisk] Windows Server 2012 R2 Datacenter
[smalldisk] Windows Server 2016 Datacenter

*Requires a reboot after installation completes

Note:
At this time, Windows Server 2016 Core continues to have SMB v1 enabled by default. We will update this blog when that situation changes

What about Linux ?

The service that enables the SMB protocol in Linux, Samba, is not installed by default on gallery images. If you choose to install Samba, CVE-2017-7494 provides information on vulnerabilities in Samba 3.5 and onward (current version at the time of writing is 4.6.7). Security updates are available. Advice in CVE-2017-7494 states that you should update as soon as possible.

Will Disabling SMB v1 have Adverse Effects?

SMB v1 has been superseded by SMB v2 and SMB v3 – both of which are significantly more secure than SMB v1. There are few modern use cases for SMB v1, however there is still a small number of applications and services that require this protocol. You can find a list of some of these services in the article SMB1 Product Clearinghouse.

Note:
While this list of products requiring SMB v1 is updated regularly, it should not be considered exhaustive. Always check with vendor documentation to determine if SMB v1 is required.

What about Virtual Machines Already Running in Azure?

We understand that having SMB v1 disabled on new VMs created from the Azure Marketplace images is just the first step. We are also strongly encouraging our customers and partners to disable SMB v1 in their environments – regardless of whether machines are running in Azure, in other public clouds, or on-premises.

After you have identified the virtual machines that have SMB v1 enabled, you can use the instructions in the article How to enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server to disable SMB v1. That article also has instructions on how to use PowerShell to determine if SMB v1 is enabled on a virtual machine.

In addition, we are planning to provide baseline settings in Azure Security Center that will check your environment for existing VMs with SMB v1 enabled, and alert customers to this. We will let you know when this is available in future updates on this blog. Finally, we will have information to share with you regarding SMB v1 and Azure Cloud Services (classic) VM services soon – make sure to follow the RSS for this blog so you know when that article is published.

Tom Shinder
Program Manager, Azure Security

Microsoft Encryption of Data-at-Rest White Paper

Thomas W Shinder - MSFT — Fri, 04 Aug 2017 01:08:35 GMT

There are essentially 3 types of encryption you want to think about when working with a cloud service provider:

Encryption at Rest

Encryption in Flight (network encryption)
Encryption in processing (application data encryption)

Encryption at rest is about protecting data on disk. You need to make sure that an attacker who might to acquire a hard drive (spinning or solid state) will not be able to pull data off that drive. The most common way of doing this is to mount the disk offline.

Of course, when we’re talking about a public cloud service provider like Microsoft Azure, the chance of such an occurrence is vanishingly small. Therefore, a more compelling reason for making sure data is encrypted at rest is so that you can satisfy compliance mandates.

However, in the end, encryption at rest is just another commonsense measure you should employ as part of your defense in depth strategy.

With this in mind, we think you’ll want to know what we do, and what we help you to do, with encryption at rest in Azure.

Just click the page below to find out!

Thanks!

Tom

Applying updates to a encrypted Azure IaaS Red Hat VM using Yum Update

Devendra Tiwari, Principal PM Director, Azure Engg — Thu, 13 Jul 2017 01:57:09 GMT

In this post, we will describe the steps you must take before you apply the updates (patch) to an already encrypted Azure IaaS Red Hat VM using yum update or newly encrypted IaaS Red Hat VM using yum update. Lets take a look at the below two scenarios: A. Deploying new encrypted IaaS Red Hat VM in Azure and applying updates using yum updates

Create a RHEL 7.3 VM from Azure gallery image
Attach/mount data disks
Encrypt all disks using the Azure disk encryption (ADE) supported scenarios and interfaces from ADE located here
Reboot when ADE PS cmdlet Get-AzureRmVmDiskEncryptionStatus returns "VMRestartPending" (for OS disk encryption)
Run the command "Yum update" on the VM (this should update both kernel and Dracut modules)
Run the commands on the VM from https://gist.github.com/mayank88mahajan/38faf934c86b89ad766c4c16dcd5f4aa

The above step 6 will generate a new initramfs image corresponding to the new kernel version with the patched up version of Dracut module

Reboot the VM

B. Applying updates using yum updates to existing (running) encrypted IaaS Red Hat VM in Azure

Run the command "Yum update" on the VM (this should update both kernel and Dracut modules)
Run the commands on the VM from https://gist.github.com/mayank88mahajan/38faf934c86b89ad766c4c16dcd5f4aa

The above step 2 will generate a new initramfs image corresponding to the new kernel version with the patched up version of Dracut modules

Reboot the VM

Deprecating Azure disk encryption preview extension for Linux IaaS VMs

Devendra Tiwari, Principal PM Director, Azure Engg — Wed, 12 Jul 2017 23:31:18 GMT

The Azure Disk Encryption engineering team has deprecated the Linux security extension "Microsoft.OSTCExtension.AzureDiskEncryptionForLinux". This extension was published for Azure disk encryption preview release. You should not use the preview version of the extension in your testing or production deployment. For deployment scenarios like Azure Resource Manager (ARM), where you have a need to deploy Azure disk encryption extension for Linux VM to enable encryption on your Linux IaaS VM, you must use the Azure disk encryption production supported extension "Microsoft.Azure.Security.AzureDiskEncryptionForLinux". For deployment scenarios using Azure PowerShell SDK, you must use the latest version of the Azure PowerShell SDK. Download the latest version of Azure PowerShell release, which deploys the latest supported version of Azure disk encryption extension "Microsoft.Azure.Security.AzureDiskEncryptionForLinux" For more details on Azure Disk Encryption solution and supported deployment scenarios, refer to the ADE whitepaper located at https://docs.microsoft.com/en-us/azure/security/azure-security-disk-encryption

Azure Network Security Whitepaper/Article Released

Thomas W Shinder - MSFT — Fri, 30 Jun 2017 17:54:15 GMT

One of the biggest challenges we have when learning about a new cloud service provider is trying to figure out what that provider has.

In fact, it’s hard even if you’re already using that cloud service provider!

For example, “what does Azure have that’s related to my network security concerns?”

The answers would come pretty slowly if you had to sift though dozens or hundreds of articles on your own – nobody has time for that!

That’s why we created the new Azure Network Security whitepaper/article.

In this article we discuss:

Basic network connectivity options and capabilities
Hybrid connectivity and security issues
Security controls to consider through Azure networking
Network security validation through logging and auditing

We hope you find the Azure Network Security whitepaper/article useful – please let us know if there are areas that need more coverage or if we need to include new topics. We’re living in the age of the agile cloud, so continuous improvements and updates define how we do docs now! Help us, help you!

Thanks!

Tom

Azure Logging and Auditing–Turn Chaos into Order

Thomas W Shinder - MSFT — Thu, 29 Jun 2017 20:50:00 GMT

Azure is a big thing – so big that a lot of you tell me it’s hard to keep up. But you’re also IT pro’s, you’re used to learning new things – IT definitely isn’t the profession you chose to not learn new things. Indeed – this is the life we’ve chosen. And that’s a good thing. But help is appreciated – especially when it comes to Azure Logging. Azure Logging can be complex – there’s a lot of moving parts and a lot of different types of logs. Wouldn’t be good to have a basic schema, a basic understanding, of all the different types of logs and how you can use all those logs? That’s where the Azure Logging and Auditing comes in! We heard you – your challenges, frustrations, blockers and overhead generators. We thought about those and put this paper together to ease your challenges, reduce your frustrations, remove your blockers and lower your overhead. Check out Azure Logging and Auditing and let us know what we need to add! And if you like it, let us know about that too Thanks! Tom Tom Shinder Program Manager, Azure Security @tshinder | Facebook | LinkedIn | Email | Web | Bing me! | GOOG me

New Azure Security Whitepapers–A Security Bonanza!

Thomas W Shinder - MSFT — Thu, 22 Jun 2017 00:42:33 GMT

They’ve been a long time coming – the Azure Security White Paper collection.

This isn’t just a white paper or two.

This isn’t marketing stuff and fluff.

This isn’t just click-this and click-that.

This is the real deal – information you can use to understand what Azure has to offer when it comes to security.

No more searching around for the Azure security information you need – it’s all in the white papers!

Here they are:

Of course, I’ll have a lot more to say about each one – but for all you early adopters, here’s your chance to get started.

And they’re more coming! Stay tuned to this space for more cool stuff, like Azure security overviews, Azure security best practices, and Azure security best practices checklists.

HTH,

Tom