In April 2016 an issue was discovered in the Microsoft Office 365 implementation of SAML 2.0, which could allow...
attackers to potentially bypass authentication for the platform and ultimately lead to potential unauthorized access to users' accounts. The root cause was a failure to properly validate the subject of the SAML, or Security Assertion Markup Language, assertion provided when a user goes through the authentication process. While the stakes for this issue where high, the issue itself was fixed relatively quickly -- within seven hours -- Microsoft had published an update that remediated the issue.
This might not seem like an overly noteworthy issue or significant event; it was fixed quickly, there was little -- if any – long-term fallout as a result of it and most organizations didn't notice the hiccup. However, there's still an important reason to discuss the Office 365 SAML flaw: because of what it can teach enterprises -- from a cloud customer standpoint -- about the service providers they use and how they respond to events like this one. Specifically, events like this provide a useful opportunity for enterprises to get a better understanding of its own posture and draw conclusions about how it can improve. Across a few dimensions, enterprises can analyze an event like this one and use what they learn as a mechanism to prepare for future events that may not be as easily resolved.
Risk decisions presuppose understanding of operation
The first lesson enterprises should learn from the Office 365 SAML flaw has to do with the degree to which organizations understand the cloud services they employ technically (i.e. the architecture of the product.) This might not sound like rocket science, but keep in mind that the cloud model makes it easy to ignore or overlook this. Specifically, cloud is valuable in part because it allows enterprises to gain distance from the underlying maintenance, support and technical substrate upon which services rest. For example, in the case of SaaS, the majority of the stack below layer seven, the application tier, is typically a black box from a customer point of view. As a result, the temptation can be to ignore how the application operates at a technical level. There are few circumstances where an organization would field a legacy client/server or web app without an understanding of architecture, but they are much more likely to do so in the case of cloud.
It's easiest to see this in action by looking at it through the filter of this particular issue. In this case, the issue was the Microsoft SAML assertion generated during the authentication process used by Office 365. To what degree do most customers of cloud services who rely on SAML have a detailed understanding of how those identity federation mechanics operate? Typically, not that much since they don't need to do so in order to use the service. However, the ability to react to an event like the Office 365 SAML one -- to contextualize it and to make risk decisions as a result -- relies on having enough understanding about the service technically to make informed decisions.
Enterprises might need to decide, for example, whether they will refrain from using the service until a given issue is remediated -- if the situation is dire enough to take action or if refraining from usage will have an impact at all in light of the issue. In the case of a smaller or less technically-savvy provider (i.e., one that might not have a fix in place in the next seven hours), enterprises might want to evaluate ancillary countermeasures if a fix might not be forthcoming rapidly. Decisions like those are harder when the information about how the service operates at a technical level is unknown or inaccessible.
This doesn't mean enterprises should have their employees spend every waking moment unpacking how each cloud service they employ operates in extreme detail. Instead, document sources to reliable architectural information in an easily accessible place. For example, if an enterprise keeps an inventory of the cloud services it employs, it might record as part of the entry a link to architectural documentation of that service. This ensures the information can be retrieved in a hurry, but doesn't require hours agonizing over it unless it's truly warranted. In fact, often organizations request and review this information anyway as a byproduct of service provider integration or vetting. Keeping a record of it saves time in the event there is an issue; not to mention that the service provider will have bigger fish to fry than sending this documentation if it is impacted by a vulnerability event.
Evaluating notification processes
The second lesson to draw from an experience like the Microsoft Office 365 SAML one has to do with how a security team is apprised and educated about this kind of situation. It's important to recognize that an individual service provider might have different methods for how it notifies customers of a vulnerability. It might send a maintenance or security alert email, it might post the alert to a status page or on its user forums and others might contact a liaison or internal point of contact. Does the enterprise know where to look? Is it confident that the internal points of contact are appropriate? Do those points of contact know what to do should they be contacted? If the answer to any of these things is no or if you're not sure, there might be some work to do.
It is important to understand on a per service-provider basis whether their alerting processes are for vulnerabilities or security events. Again, this is the kind of thing that makes for a useful entry in an application inventory -- and it is likely something that's already being collected in the course of implementing new service providers. If enterprises don't already have this information collected somewhere, they should consider doing some reconnaissance ahead of time to get the point where it does. Because an enterprise can't react to what it doesn't know about -- and unless it has some way to ensure it's being notified in a timely manner and potentially test those notification processes -- the enterprise may not have full visibility.
It's never great news for an organization when a service it employs is impacted by a vulnerability like the Office 365 SAML flaw, but sometimes there can be valuable learning opportunities that arise from it.
Learn why Microsoft Azure is the backbone of Office 365
Find out how to make single sign-on simple and secure
Discover how to prevent authentication flaws in enterprise applications