Archive for the ‘Microsoft Azure’ Category

Virtualization-based security (VBS) memory enclaves: Data protection through isolation

The escalating sophistication of cyberattacks is marked by the increased use of kernel-level exploits that attempt to run malware with the highest privileges and evade security solutions and software sandboxes. Kernel exploits famously gave the WannaCry and Petya ransomware remote code execution capability, resulting in widescale global outbreaks.

Windows 10 remained resilient to these attacks, with Microsoft constantly raising the bar in platform security to stay ahead of threat actors. Virtualization-based security (VBS) hardens Windows 10 against attacks by using the Windows hypervisor to create an environment that isolates a secure region of memory known as secure memory enclaves.

Figure 1. VBS secure memory enclaves

An enclave is an isolated region of memory within the address space of a user-mode process. This region of memory is controlled entirely by the Windows hypervisor. The hypervisor creates a logical separation between the normal world and secure world, designated by Virtual Trust Levels, VTL0 and VT1, respectively. VBS secure memory enclaves create a means for secure, attestable computation in an otherwise untrusted environment.

VBS enclaves in Microsoft SQL Server

A key technology that will leverage VBS secure memory enclaves is Microsoft SQL Server. The upcoming SQL Server secure enclave feature ensures that sensitive data stored in an SQL Server database is only decrypted and processed inside an enclave. SQL Servers use of secure enclaves allows the processing of sensitive data without exposing the data to database administrators or malware. This reduces the risk of unauthorized access and achieves separation between those who own the data (and can view it) and those who manage the data (but should have no access). To learn more about the use of secure enclaves in SQL Server, see the blog post Enabling confidential computing with Always Encrypted using enclaves.

Data protection

One of the major benefits of secure memory enclaves is data protection. Data resident in an enclave is only accessible by code running inside that enclave. This means that there is a security boundary between VTL0 and VTL1. If a process tries to read memory that is within the secure memory enclave, an invalid access exception is thrown. This happens even when a kernel-mode debugger is attached to the normal process the debugger will fail when trying to step into the enclave.

Code integrity

Code integrity is another major benefit provided by enclaves. Code loaded into an enclave is securely signed with a key; therefore, guarantees can be made about the integrity of code running within a secure memory enclave. The code running inside an enclave is incredibly restricted, but a secure memory enclave can still perform meaningful work. This includes performing computations on data that is encrypted outside the enclave but can be decrypted and evaluated in plaintext inside the enclave, without exposing the plaintext to anything other than the enclave itself. A great example of why this is useful in a multi-tenant cloud computing scenario is described in the Azure confidential computing blog post. This move allowed us to continually make significant innovations in platform security.


Attestation is also a critical aspect of secure memory enclaves. Sensitive information, such as plaintext data or encryption keys, must only be sent to the intended enclave that must be trusted. VBS enclaves can be put into debug mode for testing but lose memory isolation. This is great for testing, but in production this impacts the security guarantees of the enclave. To ensure that a production secure enclave is never in debug mode, an attestation report is generated to state what mode the enclave is in (among various other configuration and identity parameters). This report is then verified by a trust relationship between the consumer and producer of the report.

To establish this trust, VBS enclaves can expose an enclave attestation report that is fully signed by the VBS-unique key. This can prove the relationship between the enclave and host, as well as the exact configuration of the enclave. This attestation report can be used to establish a secure channel of communication between two enclaves. In Windows this is possible simply by exchanging the report. For remote scenarios, an attestation service can use this report to establish a trust relationship between a remote enclave and a client application.

One feature that relies on secure memory enclave attestation is Windows Defender System Guard runtime attestation, which allows users to measure and attest to all interactions from the enclave to other capabilities, including areas of runtime and boot integrity.

Figure 2. Windows Defender System Guard runtime attestation

Elevating data security

There are many secure memory enclave technologies in the industry today. Each have pros and cons in capabilities. The benefit of using a VBS secure memory enclave is that there are no special hardware requirements, only that the processor supports hypervisor virtualization extensions:

Additionally, VBS enclaves do not have the same memory constraints as a hardware-based enclave, which are usually quite limited.

VBS secure memory enclaves provide hardware-rooted virtualization-based data protection and code integrity. They are leveraged for new data security capabilities, as demonstrated by Azure confidential computing and the Always Encrypted feature of Microsoft SQL Server. These are examples of the rapid innovation happening all throughout Microsoft to elevate security. This isnt the last youll hear of secure memory enclaves. As Microsoft security technologies continue to advance, we can expect secure memory enclaves to stand out in many more protection scenarios.



Maxwell Renke, Program manager, Windows

Chris Riggs, Principal Program Manager, Microsoft Offensive Security Research


Cloud security controls series: Rights Management

September 14th, 2015 No comments

I talk to a lot of executives about various security topics. These days, when I talk to senior executives about leveraging cloud computing in their organization, the conversation they want to have tends to start with Rights Management and Rights Management Services (RMS). Top of mind for them is protecting their organization’s sensitive information from unauthorized access and exercising some control on how information is used within their organization and by their partner organizations.

This is where RMS can help. If you’ve been reading this blog series on cloud security controls, you have already read about some of the security controls that protect data when it’s in-transit and when it’s at-rest. RMS helps protect data at all times including when it’s in-transit and when it’s at-rest; with RMS protection is persistent whether the data is within your on-premises environment, in the cloud, or shared with people outside of your organization.

Many enterprise customers have been using RMS for many years via Active Directory Rights Management Services (AD RMS) on Windows Server and Information Rights Management (IRM) with Microsoft Office services. New capabilities evolved and flourished over time as RMS offerings matured – which resulted in a lot of great capabilities and acronyms. Today, collectively all of these RMS offerings are referred to as Microsoft Rights Management or Microsoft Rights Management Services.

The diagram below illustrates how RMS works to protect a document with confidential information in it. Essentially the document is encrypted on the client system that is sharing it, i.e. the RMS service doesn’t get to see the data, it only manages the policy and encryption key exchanges. Encrypting the document helps maintain the confidentiality and the integrity of the information. The policy that is also applied to the document dictates who can open the document and what they can do with it. When someone tries to open the document, their application will need to contact the RMS service for authentication and authorization. The application will only provide the functions allowed by the policy – for example permitting the user to open the document, forward it, print it, edit it, etc. Since the application must contact the RMS service to open the document, the RMS service can log potentially useful information about the request including who tried to open the document, where, when, etc.  This centralized authentication and policy enforcement model also enables your organization to better manage the lifecycle of protected data. For example, you can put an expiration date on the document after which it is no longer accessible by anyone, regardless of where the document is.

A great addition to Microsoft Rights Management capabilities is Azure Rights Management – frequently abbreviated to Azure RMS. To understand the difference between Azure RMS and AD RMS that you might be running on-premises, this article has a table that will show you the differences between the two.

For many of the enterprise customers I have talked to, I think a big advantage of using Azure RMS is how easily it enables them to share protected data with external partner organizations. To do this using AD RMS on-premises requires that trusts must be explicitly defined in a direct point-to-point relationship between two organizations by using either trusted user domains (TUDs) or federated trusts that you create by using Active Directory Federation Services (AD FS). Many organizations have built this type of federated environment.

Azure RMS enables implicit trust between organizations and users in any organization. This means that protected content can be shared between users within the same organization or across organizations when users have Microsoft Office 365, or Azure Rights Management, or users sign up for RMS for individuals. i.e. most of the work to federate directories with partner organizations is done for you using Azure AD as a “trust fabric.” For those of you that are familiar with directory federation – you likely agree that this will save organizations a lot of time, work and complexity.  Essentially, organizations federate once with Azure AD which then operates as a claims broker between them and all their external partners who have also federated with Azure AD. An example is illustrated in the diagram below.

Besides securely sharing data with external trusted partners, another key scenario that Azure RMS can help organizations with is sharing data across devices and platforms. This is key when organizations have a BYOD environment or when trusted partner organizations have a diverse population of devices and platforms. Azure RMS has tight integration with Microsoft Office applications (Word, Excel, PowerPoint, and Outlook, from Office 365 ProPlus, Office 365 Enterprise E3, Office Professional 2013, and Office Professional 2010) and services (Exchange Online and Exchange Server, SharePoint Online and SharePoint Server). It extends support for other applications by using the RMS sharing application. In addition the Microsoft Rights Management SDK provides developers and software vendors with the APIs they need to write custom applications that support protect data via Azure RMS. This combination enables Azure RMS to protect data across devices and platforms including Windows-based devices, Mac OS, iOS-based devices like iPads and iPhones, and Android-based devices.

The diagram below illustrates how Azure RMS works as a Rights Management solution for Office 365 as well as for on-premises servers and services, across end user devices that run Windows, Mac OS, iOS, Android, and Windows Phone.

This is what those senior executives I mentioned earlier typically want to talk about. Does Microsoft’s cloud make it easier for them to securely share sensitive emails and documents with trusted partners regardless of whether their information workers use Windows-based devices, Mac, iOS-based devices or Android devices, or combinations of all of them? They simply want to know that their data is protected regardless of where it is – Azure RMS helps them do this.

When those executives ask their CISOs questions about who had access to specific emails, documents or files, they’ll get the answers they are looking for using Azure RMS Document Tracking. For example, the screen shots below show the web hosted document tracking site with a list of all prior sharing sessions, a summary of all document sharing activity, and even a map view showing the location of the users attempting to access the protected content.

Notice the “revoke access” button in the screen shot above. This will help control the lifetime of protected content. Once access has been revoked, as seen in the screenshot below, the content will be inaccessible.

I’ve really only scratched the surface with this introduction to Azure RMS. But there is plenty of great content published:

Azure Rights Management
What is Azure Rights Management?
Terminology for Azure Rights Management
Requirements for Azure Rights Management
Azure RMS Security Evaluation Guide
Office 365 Information Protection using Azure Rights Management
The Official RMS Team Blog
Azure Rights Management: What It Is, New Features, and a View into the Roadmap (video)
Azure Rights Management Services Core Skills (video)

Tim Rains
Chief Security Advisor
Worldwide Cybersecurity & Data Protection

Cloud security controls series: Encrypting Data at Rest

September 10th, 2015 No comments

In the last article I wrote in this series on cloud security controls I discussed controls that help protect data while its in-transit between Microsoft’s cloud services and our cloud service customers. Many of the customers I talk to are also interested in understanding the controls that are available to help manage the security of data stored and processed in Microsoft’s cloud services.

There are many controls available that help mitigate different threats to data at rest, whether the data is stored online or offline. I’ll discuss some of these controls in this article. Given very high customer interest in this topic area, new features/functionality that provide customers control over data at rest are frequently announced and introduced into Microsoft cloud services. This article isn’t intended to be a complete list – it’s just an introduction.

When it comes to data at rest, there are at least a few different categories of threats that enterprise customers tend to be interested in discussing with me when they first start evaluating cloud services. Some examples include:

  1. The threat that attackers are able to compromise a cloud service and gain access to their data that is processed by and/or stored in the Cloud.
  2. The “insider threat” where a malicious or rogue administrator steals a physical disk drive or server that contains data the customer has in the cloud service.
  3. The threat that a government uses a subpoena or warrant to get access to the customer’s data in the cloud without their knowledge.

In all of these scenarios, encrypting customer data and properly managing the encryption keys can help mitigate the risk of unauthorized access to that data. While I’m going to discuss encryption controls in this article, it’s important to note that there are additional security controls such as physical security, access control, auditing, logging, key management, etc. that are used in concert with encryption options to mitigate some of these risks; I won’t be discussing these other controls in any detail in this already lengthy article.

For example, the insider threat risk I mention above is also mitigated by all the physical security controls (gates, guards, locks, cameras, biometrics, etc.) that prevent unauthorized access and control authorized access to Microsoft datacenters. For the aforementioned insider threat scenario, the combination of all the physical security controls and data encryption controls make the probability of someone stealing a disk drive or server from a Microsoft datacenter and getting access to any customer data on it, very remote.

Now let’s look at some of the encryption controls for data at rest that are available to customers.

For some of the customers I talk to that are evaluating the security of Infrastructure as a Service (IaaS), they want to know about encryption options available to them in Microsoft Azure. There are several encryption related solutions that customers can choose from depending on the risks they are trying to mitigate. Let’s look at a few of these solutions.

Some of the customers I talk to that are interested in moving some or all of their infrastructure into the cloud want to ensure that the virtual machines (VMs) they manage in the cloud are secured at rest and only boot and operate when their organization authorizes them to do so. They want to mitigate the risk that if someone managed to steal one of their VMs from the cloud, attackers could siphon off data stored in the VM using an offline attack or boot the VM with the intent of stealing data or modifying the VM in some way. Encryption can help manage these types of risks; without access to the encryption keys, the VMs stored in the Cloud won’t boot or provide easy access to data stored in them.

Azure Disk Encryption
Whether you are creating a new IaaS VM from the Azure gallery or migrating existing encrypted VMs from your on-premises operations, Azure Disk Encryption can help you manage encryption of disks used with Windows or Linux VMs. Using Azure Disk Encryption, Windows VMs can be encrypted using native BitLocker Drive Encryption which many enterprise customers already use to protect data stored on their on-premises Windows-based systems.  Those customers leveraging Linux VMs in Azure can protect them using DM-Crypt technology with a passphrase they provide.

The BitLocker encryption keys or Linux DM-Crypt passphrases that are used to encrypt and decrypt the VM drives are stored in Azure Key Vault which provides protection for the keys via FIPS 140-2 Level 2 validated hardware security modules (HSMs). This means, among other things, that the HSMs that store customer keys and secrets have tamper-evident seals to protect against unauthorized physical access and role-based authentication for administration. This helps mitigate the risk that someone with physical access to the HSMs inside the heavily protected datacenter could easily tamper with HSMs or steal keys from them.

The theft of a VM that has been protected this way would not allow an attacker to boot the VM or harvest data from it.

Native BitLocker encryption for VMs running in Azure is something that many enterprise customers have asked me about and Azure Disk Encryption is what they are looking for. A preview of Azure Disk Encryption will be available soon – keep a look out for related announcements in the near future.

Here are more resources where you can get more information on Azure Disk Encryption and Azure Key Vault:
Azure Disk Encryption Management for Windows and Linux Virtual Machines
Enabling Data Protection in Microsoft Azure (video)
Azure Key Vault
Introduction to Microsoft Azure Key Vault (video)
Azure Key Vault – Making the cloud safer

CloudLink SecureVM
CloudLink SecureVM by EMC also provides native Windows BitLocker and Linux OS encryption for VMs running in Microsoft Azure. It emulates Trusted Platform Module (TPM) functionality to provide pre-boot authorization. CloudLink SecureVM allows you to define a security policy that permits VMs to start, verifies their integrity and helps to protect against unauthorized modifications. It also provides the ability to store the encryption keys to reside inside customers’ own datacenters.

You can find CloudLink SecureVM in the Microsoft Azure Marketplace as I have highlighted below.

More information is available in the Microsoft Azure Market place, as well as:
Encrypting Azure Virtual Machines with CloudLink SecureVM
Azure Virtual Machine Disk Encryption using CloudLink
Guest Post: CloudLink Secures Azure VMs via BitLocker and Native Linux Encryption (video)
Deploying CloudLink SecureVM from the Microsoft Azure Marketplace (video)
CloudLink SecureVM Administration Guide

StorSimple is a hybrid-cloud storage appliance that you can put into your datacenter and connect to the Azure Storage service. This solution provides many benefits and security controls, but for data at rest, StorSimple systems encrypt data stored in the cloud with a customer-provided encryption key using standard AES-256 encryption that is derived from a customer passphrase or generated by a key management system.
09102105_Figure2 09102105_Figure3

You can use the Azure Portal (as seen below) or Windows PowerShell for StorSimple for some management activities and there’s a StorSimple Adapter for SharePoint available.

You can get more information from these resources:
Introducing Microsoft Azure StorSimple
StorSimple Hybrid cloud storage security
Cloud Storage Security Best Practices
Episode 159: StorSimple with Ahmed El-Shimi (video)

Client-Side Encryption for Microsoft Azure Storage
Client-Side Encryption for Microsoft Azure Storage enables you to encrypt data contained in Azure Storage accounts including Azure Table storage, Azure Blob storage and Azure Queues. This feature enables developers to encrypt data inside client applications before putting in into Azure Storage. It also allows developers to decrypt the data stored in Azure Storage while downloading it to the client.

For some customers, the advantage of this approach is that they completely control the keys used for encrypting and decrypting the data stored in Azure Storage. The Azure Storage service doesn’t have the encryption keys, only the customer does. Even if the customer’s Azure Storage Account keys were compromised, the data encrypted using client-side encryption would still be secure. This feature also supports integration with Azure Key Vault, which I mentioned earlier in this article.

To take advantage of this capability, developers use a new open-source Azure Storage Client Library for .NET that’s interoperable across a number of programming languages. The storage client library uses Cipher Block Chaining (CBC) mode with AES to encrypt the data.

Many details you’ll need are available including code samples:
Get Started with Client-Side Encryption for Microsoft Azure Storage
Client-Side Encryption for Microsoft Azure Storage – Preview
Microsoft Azure Storage Client-Side Encryption Goes into General Availability

I’ve covered a lot of ground in this article on protecting data at rest in Microsoft’s cloud. Frankly, there is a lot more I could write about here including SQL database encryption (Transparent Data Encryption (TDE), Cell Level Encryption (CLE), SQL Server Encrypted Backups, SQL Server Extensible Key Management (EKM), Office 365 encryption controls, OneDrive security controls, custom application encryption, etc. But this article provides a starting point for those customers evaluating the data protection controls available in Microsoft’s cloud.

Tim Rains
Chief Security Advisor
Worldwide Cybersecurity & Data Protection

Cloud security controls series: Encrypting Data in Transit

August 10th, 2015 No comments

Whether organizations store and process data on-premise, in the cloud, or use a combination of both, it is important that they protect that data when it is transmitted across networks to information workers, partners and customers.

For example, when an administrator is using the Microsoft Azure Portal to manage the service for their organization. The data transmitted between the device the administrator is using and the Azure Portal needs to be protected. Another example is protecting both outbound and inbound email. When you send an email to someone when using, your email is encrypted and thus better protected as it travels between Microsoft and other email providers that also support email encryption.

Microsoft is using encryption to protect customer data when it’s in-transit between our customers and our cloud services. More specifically, Transport Layer Security (TLS) is the protocol that Microsoft’s data centers will try to negotiate with client systems that connect to Microsoft cloud services. There are numerous benefits to using TLS including strong authentication, message privacy, and integrity (enables detection of message tampering, interception, and forgery), interoperability, algorithm flexibility, ease of deployment and use.

Perfect Forward Secrecy (PFS) is also employed so that each connection between customers’ client systems and Microsoft’s cloud services use unique keys. Connections to Microsoft cloud services also take advantage of RSA based 2,048-bit encryption key lengths.

The combination of TLS, RSA 2,048-bit key lengths, and PFS makes it much more difficult for someone to intercept and access data that is in-transit between Microsoft’s cloud services and our customers, than previously employed encryption technologies. Since no encryption suite is truly unbreakable, the goal of these protections is to make it extremely time consuming and expensive for would-be eavesdroppers to intercept and decrypt data that is transmitted between client devices and Microsoft datacenters. I have included some references at the bottom of this article if you are interested in learning more about PFS and TLS, and how Windows clients negotiate encryption protocols when connecting to servers. Besides using a newer version of Windows, there isn’t any action customers need to do to secure data in-transit between them and Microsoft’s cloud services.

Since seeing is believing I thought I’d show you what is actually happening on the wire when a client system connects to a Microsoft cloud service. Figure 1 and Figure 2 are screen shots of a network monitor trace I took while I was logging into the Azure Portal. This trace shows the Windows system I used to log into the Azure portal negotiated a secure connection that uses TLS and Elliptic curve Diffie–Hellman (ECDH) for PFS, and that the subsequent data communicated between the client device and the portal is encrypted and unreadable if intercepted.

Figure 1: A network monitor trace of a Windows 10 client negotiating an encrypted connection to the Azure Portal

Figure 2: Continuation of a network monitor trace of a Windows 10 client is sending encrypted data to the Azure Portal

In this article I provided some details on how Microsoft protects data in-transit between our customers’ client devices and Microsoft’s cloud services. But there are numerous additional encryption controls that customers can choose to use to protect their data depending on the type of service they are using and the risk they are trying to mitigate. I will cover some of these controls in future articles in this series on cloud security controls.

Some dated, but useful background information on how TLS works:
What is TLS/SSL?
How TLS/SSL Works
TLS/SSL Cryptographic Enhancements

Some newer useful content:
Speaking in Ciphers and other Enigmatic tongues…
How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll
Protecting against the SSL 3.0 vulnerability
How to Disable SSL 3.0 in Azure Websites, Roles, and Virtual Machines
Associating a custom domain and securing communication with Microsoft Azure

Tim Rains
Chief Security Advisor
Worldwide Cybersecurity & Data Protection


Cloud security controls series: Azure AD Privileged Identity Management

July 23rd, 2015 No comments

Securely managing access to privileged accounts has been a challenge for many of the CISOs I talk to. Many of these CISOs worry that their organizations have too many permanent accounts with high levels of privilege in their environments. Some examples of the threats that keep these people up at night include malicious or rogue administrators, administrator credentials leaked via phishing attacks, administrator credentials cached on compromised systems, user accounts granted temporary elevated privileges that become permanent.  More and more organizations are realizing that they have to strictly manage privileged accounts and monitor their activities because of the risk associated with their misuse. But many organizations are struggling to truly embrace the principle of least privilege across their large, complicated environments. I frequently get asked for best practices for managing and monitoring administrator accounts.

Working with privileged accounts in the Cloud is no different; using the principle of least privilege with Cloud resources makes as much sense as it does for on-premise resources. This is an area where Azure AD Privileged Identity Management can help. Azure AD Privileged Identity Management will help you discover the Azure Active Directory privileged administrator roles and the user accounts they are assigned to. It will also enable you to revoke permanent privileged access and provide a mechanism that manages on-demand, time-limited access for Azure Active Directory privileged accounts. This is the “just in time administration” functionality that so many CISOs I have talked to have been looking for. Azure AD Privileged Identity Management also provides reports on administrator access history and changes in administrator user account assignments.

You can get Azure AD Privileged Identity Management in the Azure Preview Portal as seen in Figure 1. Note that you’ll need the Premium edition of Azure to get this feature – yet another important security feature that justifies getting the Premium edition.

Figure 1: In the Azure Preview Portal click “New”, “Security + Identity”, “Azure AD Privileged Identity”; once installed it will appear on the Startboard in the Azure Preview Portal
0723 Figure 1

One feature of Azure AD Privileged Identity Management that I’ll highlight here is the “just in time” administrator functionality that I mentioned earlier. Azure Active Directory enables granular administrative control of resources. Users can be given privileged roles that enable them to do different administrative functions for their organization. Examples of these roles include Global Administrator, Billing Administrator, Compliance administrator, Service Administrator, Password Administrator, User Administrator, and others. Many customers will take advantage of Office 365 workload specific roles such as Exchange Administrator, SharePoint Service Administrator, and Skype for Business Administrator. When managed by Azure AD Privileged Identity Management, user accounts that have these roles assigned to them are essentially non-privileged users until they are activated into their assigned privileged role. When the user needs to perform an administrative activity that requires the privileges that their privileged role provides, they simply start Azure AD Privileged Identity Management in the Azure portal and activate their membership in the role they have been pre-assigned. Now they will be able to perform the administrator function for a limited period of time before the activation expires. Figure 2 is an example of the privileged account activation process in Azure AD Privileged Identity Management.

This process provides a few important advantages over the standard administrative model. First, it helps minimizes the number of accounts that have standing administrator privileges. The fewer administrators surfing the Internet and reading email, using privileged credentials, the better.  The second advantage of this approach is that it minimizes the amount of time that privileged accounts are active – they are only used when they need to be used and are otherwise dormant. This makes an audit trail that has less noise and that can actually be used to understand when and how privileged accounts were used. Another big advantage of this approach is that it provides an excellent place to enforce multi-factor authentication that will help mitigate the risk of leaked administrator credentials. Forcing users to use multi-factors to authenticate when they need to activate their privileged roles also provides a level non-repudiation that helps manage the “insider threat” scenario that so many of the CISOs I talk to worry about. If administrators know they are being monitored and their activities are being logged and are easy to audit, they are less likely to take liberties or be sloppy with the privileged credentials they have been entrusted with.

Figure 2 (left): I activated my role as a Security Administrator in Azure AD Privileged Identity Management which gave me the privileges of that role for 50 minutes; Figure 3 (right): each privileged role has settings that can be configured that define the activation duration, whether to automatically send notifications on activation, and whether to require multi-factor authentication for activation
0723 Figure 20723 Figure 3

Azure AD Privileged Identity Management has a lot more functionality than I covered here; the Azure team has published some good resources so that you can learn more:

Azure Cloud App Discovery GA and our new Privileged Identity Management service
Azure AD Privileged Identity Management
Azure AD Privileged Identity Management (video)
Privileged Access Management for Active Directory

Tim Rains
Chief Security Advisor
Worldwide Cybersecurity & Data Protection

Cloud security controls series: Azure Active Directory‘s Access and Usage Reports

July 13th, 2015 No comments

Over the past several months I have had many, many conversations with business customers and governments about the security benefits of Microsoft’s Cloud service offerings. This video from the RSA Conference earlier this year will give you an idea of the types of topics we have been discussing with customers. These conversations have increasingly become less about whether the Cloud can be trusted, and more about the innovative security and privacy features and functionality that are being constantly introduced into Microsoft’s Cloud services. Many of the CISOs and CIOs I have talked to recently have come to the conclusion that their own data centers will not keep pace with the level of innovation that they see happening in Microsoft’s Cloud services.

Subsequently I thought it was a great time to write a series of articles focused on some of the security features and functionality built into Microsoft’s Cloud services. Since most of the conversations I have been having with customers have been about controls in Office 365 and Microsoft Azure, specifically Infrastructure as a Service (IAAS), these articles will focus on security controls in these areas.

To get an idea of the type of innovation I’m talking about, in a security context, simply peruse Azure Active Directory‘s access and usage reports. Figure 1 below is a screenshot of Active Directory‘s access and usage reports in the Azure portal. To get to this place in the Azure portal simply click on “Active Directory” in the left-hand navigation bar, then click on the active directory in the list you want to get reports on, and then click on “REPORTS” tab.

Figure 1: Azure Active Directory‘s access and usage reports

Typically when CISOs see this list for the first time, they get very interested in learning more about these reports. In order for you to get access to all the same reports that you see in Figure 1, you need the Premium edition of Azure Active Directory. You can get information on the different editions of Azure Active Directory here. Some of these reports are available in the free edition of Azure Active Directory, and thus available as part of every Azure subscription. Some examples of reports that are available in the free edition of Azure Active Directory include “Sign ins from unknown sources”, “Sign ins after multiple failures”, and “Sign ins from multiple geographies”. As I mentioned, some of the other reports seen in Figure 1 require the Premium edition of Azure Active Directory including “Sign ins from IP addresses with suspicious activity”, “Anomalous sign in activity”, “Sign ins from possibly infected devices”, and others. You can see the current list of reports and which edition of Azure Active Directory they are available in, here.

I have written a couple of articles that will give you more details on some of these reports and why they are potentially so valuable:

Sign ins from possibly infected devices
From the Cloud Security Alliance Congress EMEA: How IP addresses associated with malware infected devices help protect Microsoft cloud customers

Users with leaked credentials
The Risk of Leaked Credentials and How Microsoft’s Cloud Helps Protect Your Organization

The Azure Active Directory team has provided an article that documents each report including example screenshots:

Each report in Figure 1 can be downloaded in comma separated value (CSV) format for archiving or further analysis. An example of a file that has been downloaded from the Azure portal is provided in Figure 2.

Figure 2: Example audit report downloaded from the Azure Portal

There are also activity reports for users and groups available. This makes it possible for your organization’s Azure administrators to review sign in activity for users; this report includes information like the application the user signed into, the type of device the user used, the device’s IP address, and the location the sign in was from. Figure 3 is an example of a user activity report. To get to this report in the Azure portal simply click on “Active Directory” in the left-hand navigation bar, then click on the active directory in the list you where the user account resides that you want to get an activity report on, then click on the “USERS” tab, then click on the user in the list you’d like to review activity for, then click the “ACTIVITY” tab.

Figure 3: Example of an Azure Active Directory user activity report from the Azure Portal

Most of the CISOs I talk to tell me that they really don’t want yet another console or “pane of glass” to search for useful information in. Many of them already have numerous consoles for anti-malware software, IDS/IPS solutions, patch management, and in some cases one or more Security Information and Event Managers (SIEMs). There are a couple of additional features that will help security professionals that are in this category. Email notifications are automatically sent to all of the global admins associated with your Active Directory when it encounters 10 or more anomalous sign in events within a span of 30 days or less. This email will be sent from This feature is enabled by default – you can see this setting by clicking “Active Directory” in the left-hand navigation bar, then click on the active directory in the list you want to check the setting on, and then click on “CONFIGURE” tab. The setting is called “Email Notification of Anomalous Sign Ins” as seen in Figure 4.

Figure 4: Azure Active Directory notification settings in the Azure portal

Another useful bit of functionality that will help reduce the number of consoles security staff need to monitor is the Azure AD Reporting API. This API gives you the ability to programmatically export the data in these reports so that they can be consumed by your SIEMs and other data collection and analytics software. The Azure Active Directory team has provided a sample PowerShell script that illustrates how to access data from any of the available reports in JavaScript Object Notation (JSON), Extensible Markup Language (XML) and text formats. You can get more information on the REST APIs that provide read-only access to the Azure AD access and usage reporting data from this page on MSDN. There is also a whitepaper available called Microsoft Azure Security and Audit Log Management that contains more details on generating and collecting security logs from services that are deployed in Azure.

Figure 5: Output from a PowerShell script that I used to access events in the Audit Events report in my Microsoft Azure subscription’s Azure Active Directory

One of the reasons many CISOs get excited about these reports is that they don’t have similar capabilities in their on-premise environments or have to pay for a third party service to provide something similar. These reporting capabilities are built into the Microsoft Azure platform; so whether you are running applications based on the Azure platform (PaaS) or running your own virtual machines in Azure (IaaS) you’ll have the option of using these reports to help spot potential security issues.

Tim Rains
Chief Security Advisor
Worldwide Cybersecurity & Data Protection

A cornerstone to trust in technology – compliance – proves foundational as more U.S. government organizations adopt cloud services

April 13th, 2015 No comments

Government agencies want the economic benefits of cloud computing, but this alone isn’t always enough to make the case for change. To move forward, decision makers want to understand the security, privacy and compliance commitments of their cloud service provider. We continue to track and complete a number of attestations and compliance certifications, confirming controls are in place that help enable cloud solutions for government organizations. And, while compliance represents a necessary set of requirements for many governments prior to Cloud adoption, customers also tell us that these investments are helping increase IT security and are therefore integral to decision-making.

One recent example in the United States, is the Criminal Justice Information System (CJIS), a division of the U.S. Federal Bureau of Investigation that operates systems to provide state, local, and federal law enforcement, and criminal justice agencies, with access to criminal justice information. In April, the California Department of Justice confirmed that Microsoft Azure Government cloud solutions complied with CJIS standards for handling criminal justice information in the cloud. In addition to the State of California, Microsoft has signed CJIS agreements for Office 365, Azure, or Dynamics CRM Online in 11 states, including Texas, Michigan, Kansas, and Pennsylvania, and more are still to come.

To outline how U.S. government IT departments are using the cloud to become more secure, we’ve also produced an infographic. For U.S. government entities who want to learn more about the cloud in general, and the cloud services available today, I encourage a visit to our dedicated site.

Obtaining new certifications or updating current ones can be a complicated task. Whether CJIS requirements, FedRAMP, IRS 1075, or HIPAA, organizations rely on their cloud service provider to adhere to these requirements as well as provide the tools necessary to confirm compliance. If you’re interesting in learning more about what we’re doing in the area of compliance, the Azure Trust Center, the Office 365 Trust Center and the Dynamics CRM Trust Center all provide summary level and detailed information.

Microsoft achieves globally recognized ISO/IEC 27018 privacy standard

February 16th, 2015 No comments

Today Microsoft announced its continued commitment to further protect customers’ privacy by obtaining the globally recognized ISO/IEC 27018 privacy standard for Microsoft Azure, Office 365, and Dynamics CRM Online. This achievement is designed to help assure customers of all sizes, that their most sensitive personal data will receive the strong privacy protections detailed in this standard.

We know that our customers rely on us as their cloud service provider, to continually enhance security, ensure data privacy and manage compliance expectations. There are a lot of certifications to pursue; you can be confident we’ll cut through the clutter and focus on what’s important. Microsoft’s achievement of the ISO 27018 standard will ensure additional practices are put in place to help protect your data. For more details on this important milestone, please read Brad Smith’s blog.