Microsoft Publishes White Papers on Incident Response and Shared Responsibility for Azure Cloud Customers
Incident response is a hot topic. The cloud is a hot topic. But how do you respond to incidents in the cloud for which you may have no knowledge? It’s a difficult issue that could cause problematic relations between enterprises and the big clouds like Microsoft Azure, Amazon Web Services (AWS) and Google.
Now Microsoft is setting the ground rules with two new documents: Shared Responsibilities for Cloud Computing, and Microsoft Azure Security Response in the Cloud.
The first specifies Microsoft’s view of its own responsibilities (and therefore, by omission, the enterprise CISO’s responsibilities); while the second gives an outline of how Microsoft will actually respond.
Microsoft believes that there is a fairly fundamental split in responsibility. The cloud provider is responsible for the physical aspects of the cloud IT infrastructure and the software that it provides. The customer is responsible for its own data.
It sounds simple, but there will inevitably be problems. Forensic proof will become important. If a customer’s data is modified via a flaw in Microsoft software that Microsoft doesn’t recognize, there could be issues.
This is where the CISO needs to understand both documents – because there are some incidents that Microsoft will not report to the customer. For Azure, Microsoft defines a security incident as “illegal or unauthorized access that results in the loss, disclosure or alteration of Customer Data.” But it adds, “Microsoft Azure does not monitor for or respond to security incidents within the customer’s area of responsibility.”
So, put very simply, if Microsoft does not recognize the incident as being within its own area of responsibility, it cannot be expected to tell you about it. This, in turn, means that every IaaS customer will still need its own incident response plan covering the entire sequence from detecting incidents, through containment, evaluation, disclosure and crisis management. And as every CISO knows, visibility into the cloud is not always 20/20.
Having suggested that Microsoft’s definition of its and its customers’ responsibilities could cause operational difficulties, the remainder of the Incident management document is informative and valuable. It first outlines the roles that should be involved in a response, and then describes the plan itself.
Seven separate roles are described. There should be more in an enterprise plan. The Microsoft roles stop with an Executive Incident Manager – but an enterprise role should continue with a Crisis Management Team (possibly brought in from outside) to handle relations with public and press.
The plan itself involves five stages: Detect, Assess, Diagnose, Stabilize, and Close. Again, a sixth stage for enterprises should include something we could describe as ‘Manage Fallout;’ that is, crisis management.
Microsoft operates a separate function called Customer Security Incident Notification. “The goal of the customer security incident notification process,” says Microsoft, “is to provide impacted customers with accurate, actionable, and timely notice when their customer data has been breached. Such notices may also be required to meet specific legal requirements.”
This appears to be a ‘breach disclosure’ to the enterprise customer, not a breach disclosure to regulatory authorities. Interestingly, this follows the data protection responsibility outlined in the new European laws. Microsoft is the data processor. The enterprise customer is the data controller. Primary responsibility will always fall on the data controller; that is, legally a cloud customer cannot pass responsibility to its cloud provider. That should be a basic understanding for all enterprises moving their infrastructures into the cloud.
Related: Security Challenges of SDN and Cloud: The Critical Role of Visibility