Security standards in Azure

Microsoft manages the Azure infrastructure. At the most, users can manage the operating system inside a VM, but they do not need to administer, edit, or influence the under the hood infrastructure. They should not be able to do that at all.

Therefore, Azure is a shared environment. This means that a customer's VM can run on the same physical server of another customer and for any given Azure Service, two customers can even share the same VM (in some Platform as a Service (PaaS) and Software as a Service (SaaS) scenarios).

From the point of view of a customer, a shared environment could sound bad but also good, since there less is to manage and fewer errors might rise. As a consequence of this, Microsoft manages some rings of security, pursues other goals, and the availability of the shared environment.

Note

Incidents and business continuity:

Incidents may occur, even for super-skilled people who are working in a Microsoft Azure datacenter. Incidents are caused by human faults (pressing the wrong button, inadvertently stumbling upon a power generator with coffee, and so on), by software bugs (a piece of code of a VM management tool crashes on January 1), and by a mix of both (a user forgot to renew an SSL certificate, which leads to the unexpected behavior of the application). When an incident occurs, the consequence could be a downtime in the customers' services. If the incident is not properly addressed, it could lead to a disaster.

Microsoft Azure, like many Cloud computing suites, guarantees a Service Level Agreement (SLA) on its building blocks. The key focus of the SLA is not what happened to the system, but how much time the system was unavailable in a given timeframe (usually a year). This indicator is measurable and it is also a contractual constraint, which is financially backed.

SLA is directly connected to business continuity: an e-commerce operator's interest is to reduce the risk of unexpected periods of unavailability that cause immediate loss of profits.

Implementing security, privacy, and compliance

Microsoft Azure implements the most recognized standards about security and privacy and implements effective practices about compliance. The Microsoft Azure Trust Center (http://azure.microsoft.com/en-us/support/trust-center/) highlights the attention given to the Cloud infrastructure in terms of what Microsoft does to enforce security, privacy, and compliance. Let's discuss these in detail.

Security

Part of Microsoft's attention to security is also about processes and management, by implementing a series of measures:

• Security centers: Microsoft implemented internal units for security, such as the Microsoft Digital Crimes Unit, Microsoft Cybercrime Center, and Microsoft Malware Protection Center
• Security Development Lifecycle (SDL): Microsoft implemented SDL to provide a software development process that is more secure from a security perspective

  Note

  More information about SDL can be found here: http://www.microsoft.com/security/sdl/default.aspx, including a training path to implement our own process.

• Incident task force: Microsoft documentation often states that infrastructures are designed to react, assuming there is a breach, fielding a task force of security experts who are available 24 x 7

The first point of interest is the management of the datacenter, where Microsoft takes care of everything including:

• Physical security: Microsoft assures that the datacenter buildings are designed to be monitored and controlled in the case of physical attacks (environmental or criminal).
• Software updates: For each managed service running on Azure (PaaS and SaaS services, at least), Microsoft applies the latest security updates (as long as there is malware protection), in order to avoid security breaches to its customers.
• Hacking countermeasures: Azure implements techniques to detect software intrusions and Distributed Denial of Service (DDoS) attacks, and performs periodic penetration tests to constantly ensure these requirements are met.
• Isolation: Since resources are shared, isolation between tenants (customers, but also different subscriptions) is implemented by design. Network activity between VMs is restricted (except the cases intentionally left for customers solutions).

In the rest of the book, we will discuss what we should do to implement security from a user perspective; while Azure manages the datacenter, users must manage the application's security.

Privacy

Microsoft Azure is a public Cloud product so, to ensure adoption, it must adhere to most of the security and privacy standards and/or regulations to be used worldwide. We can choose our own region to store applications and data and Microsoft assumes that for the services implementing geo-replication, data won't ever leave the geo-political area.

Note

What does the term geo-political area mean? Let's, for example, choose west Europe as the location for our deployment. In some cases, Microsoft, to ensure availability, creates replicas in another datacenter, preventing the supposed downtime in the case of a disaster in the primary one. However, a customer would not want the data replicated outside the political boundaries he or she has chosen. This is why there are often (at least) two datacenters in the same political region (that is, in Europe) where rules are accordant.

While privacy is also enforced at the personnel level (no one inside Microsoft can access resources, except for customers who request assistance), Microsoft offers strong contractual agreements to the enterprise customers and does not use data to sell advertisements anywhere.

Compliance

Previously in the chapter, you saw how security is mostly about processes instead of technology. We introduced the importance of standards, while implementing the proper controls and measures to be adequately safe. While avoiding unnecessary details, you must know that Microsoft Azure is certified for ISO/IEC 27001, while it is audited yearly.