Some topics that I get asked about by customers frequently include whether they can do penetration testing on Microsoft cloud services, whether Microsoft does its own penetration tests, and how the cloud impacts customers’ ability to perform forensic investigations on systems they have in the cloud. I thought I’d cover all three of these topics in one article in our series on cloud security controls.

Microsoft Enterprise Cloud Red Teaming
Let’s look at Red Teaming first. Let me provide some context for this topic before diving into it. Microsoft takes many steps to secure both on-premises software and cloud services. The objective of this work is to reduce the number and severity of vulnerabilities in software and services. This living methodology and tool-set is what we call the Microsoft Security Development Lifecycle (SDL). The security and privacy requirements in the SDL are updated regularly to stay ahead of the tactics that attackers use. This approach makes our software that runs in our customers’ on-premises environments and in Microsoft’s datacenters, harder to successfully attack and more resilient. We have been leveraging and maturing the SDL at Microsoft for over 10 years and the results are reassuring. The graphs below illustrate that despite releasing a steady stream of new software, Microsoft’s portion of industry-wide vulnerability disclosures has trended between 3% and 8% (source: Microsoft Security Intelligence Report volume 18), while the exploitability of critical rated vulnerabilities has decreased by more than 70% since 2011.

For enterprise cloud services that are managed in Microsoft datacenters, in addition to the SDL, there is another set of security requirements called Operational Security Assurance (OSA). Microsoft uses OSA to minimize risk by ensuring that ongoing operational activities follow rigorous security guidelines and by validating that guidelines are actually being followed effectively. OSA prescribes key security controls that Microsoft has seen to be effective in mitigating known attacks and previously unknown vulnerabilities. Simply put, OSA helps make Microsoft cloud-based services’ infrastructure more resilient to attack.

In addition to the aforementioned preventative measures, Microsoft continuously develops capabilities that help to detect and respond to attacks. This approach supports a more holistic security strategy than preventative measures alone. The underlying assumption of a “Prevent Breach” security strategy is that teams will be so good at preventing breaches that they don’t have to spend time planning for post-breach scenarios. On the other hand, an “Assume Breach” security strategy requires teams to spend time and resources not only on prevention, but also detection and response capabilities. Assume Breach is a security strategy developed at Microsoft and is now industry-recognized.

Microsoft uses Red Teaming and performs live site penetration testing on Microsoft cloud services as part of its “assume breach” security strategy. Red teaming is used at Microsoft to simulate real-world breaches. During these exercises, teams are continuously monitoring security and practicing security incident response to test and improve the security of Microsoft cloud services. Such tests are performed on Microsoft cloud services infrastructure and platforms, as well as Microsoft’s own tenants, applications and data. Customer tenants, applications and data hosted in Microsoft cloud services are never targeted in these exercises. Red Teaming tests Microsoft’s abilities to respond to targeted and persistent attacks with the goal of significantly reducing the Mean-Time to Detect (MTTD) and Mean-Time to Recovery (MTTR).

If you are interested more detail on how Microsoft uses Red Teaming as part of its cloud security strategy, you are in luck! Several resources are available on this topic including an excellent whitepaper:

Red Teaming: Using Cutting-Edge Threat Simulation to Harden the Microsoft Enterprise Cloud
Microsoft Enterprise Cloud Red Teaming (whitepaper)
Red vs. Blue – Internal security penetration testing of Microsoft Azure (video)

Customers Performing Penetration Testing on Cloud-based Applications
Over and above the Red Teaming and live site penetration tests that Microsoft does on its cloud services (for example, as part of maintaining numerous compliance accreditations such as FedRAMP and Service Organization Controls (SOC)), many customers I talk to ask about how they can do their own penetration testing. Many organizations use penetration testing as part of their application development and deployment processes. To support this, Microsoft has established a policy for customers to follow in order to safely and efficiently carry out authorized penetration testing on their applications hosted in Microsoft Azure. The process is straight forward – customers send a request to Microsoft which will notify the appropriate security teams that your organization plans to perform penetration testing on an Azure based application.

Security teams at Microsoft will review the nature and scope of the planned tests and approve or deny the request. This process is required so that Azure security teams can distinguish between customer penetration tests and attacks against customer applications or the Azure service. Please plan to provide at least 7 days advanced notice for penetration tests; some standard tests get expedited review including testing for OWASP top 10 web vulnerabilities, fuzz testing and port scanning endpoints.

Important note: Denial of Service (DoS) attacks are strictly prohibited.

You can read the terms and conditions (very important) and submit a penetration testing request here: Azure Penetration Test Approval Process

Customers Performing Forensics Investigations in Microsoft’s Cloud

Finally, let’s take a brief look at forensics in the cloud. I worked on Microsoft’s customer facing incident response team many years ago, long before many of today’s modern forensics tools were available. Over the years, new forensics tools made it easier to do investigations and many customers built their own incident response teams which investigate compromised systems in their environments. Some of these investigations seek to answer basic questions such as, is the system compromised, when did the system get compromised, how did the system get compromised, and how do we prevent it from happening again? Other investigations are done with the goal of finding and prosecuting the attackers.

When customers that have their own incident response teams consider leveraging the cloud for Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS) they naturally have questions about how this will impact their incident response processes and tools.

Specifically, most of the questions I get asked are about how collecting evidence from systems in the cloud is different from collecting evidence from systems on-premises. It turns out that collecting evidence from virtual machines hosted in Microsoft Azure isn’t really much different from collecting evidence from remote systems in a typical enterprise environment. In some respects, Azure makes it easier to collect evidence because it has features that make it very easy for administrators to copy or capture entire virtual machine images and drives.

An excellent in-depth article is available on this topic on the Azure Security, Privacy & Compliance team blog: How I learned to stop worrying and love the cloud: Azure Forensics for the Security Responder

Another related topic that you might want to learn about is how to collect and analyze security logs from Azure: How to Collect and Analyze Azure Security Logs.

Tim Rains
Chief Security Advisor
Worldwide Cybersecurity & Data Protection