 |
As I talk to customers who are looking into leveraging cloud Identity services and are thinking about issues around how and where user data is stored and processed, I sometimes come across a customer who throws up their hands and says something like “the identity data is already in the cloud anyway –at the service providers – so why does it matter?” This is a valid question. I think it’s important that folks understand that the answer is more nuanced than they might initially think – as is clearly demonstrated by the recent hack of the OneLogin service A SaaS application may store a username, credential, and some profile information for its own purposes – to enable users to authenticate to them directly and access application functionality. So, if a bad actor is able to compromise the user database, they now have access to the functionality that application provides. The result is that the compromise of one security domain (the SaaS provider) enables a bad actor to perform operations within that security domain. An Identity as a Service (IDaaS) solution is different though. It contains the credential information for users at multiple security domains. If it were to be compromised the result would be that a bad actor would be able to perform operations within many different security domains – a much bigger vulnerability with much bigger consequences. As a result, IDaaS solutions are a more valuable target for bad actors, and as such receive a lot more “attention” (in the form of attacks) from them. So, I think that the argument that “the identity data is already in the cloud anyway” really doesn’t hold water –in fact it sounds to me like “we’ve already got one server directly connected to the internet, why not connect some more?” The answer is that both extra identity accounts and extra internet connections represent an attack surface that can be leveraged by bad actors. It’s critical to consciously reduce that attack surface when possible, not increase it. With this in mind, it’s important that we take a close look at how IDaaS solutions are handling user data, and understand the security implications. Not all IDaaS solutions are created equal; some were built for companies that are ‘all-in’ with cloud technology, while others were built with a hybrid deployment model in mind – one that leverages existing enterprise identity capabilities. In an enterprise environment that has existing user directories and processes for maintaining them, an IDaaS solution should leverage those existing capabilities in place, as opposed to replicating them in the cloud – ultimately creating yet another “Island of Identity” that increases the attack surface. So, it’s important to ask questions about where an IDaaS solution stores and processes users’ network credentials to understand how the adoption of that service will impact your Identity attack surface and potential risks. Interested in more topics like this? Subscribe here! The post Recent Breach Highlights Differences in IDaaS Approaches appeared first on Speaking of Security - The RSA Blog and Podcast. |
