Onelogin, a cloud based identity and access manager, reported being hacked on May 30th. This is the challenge with cloud based IDaaS managers.
WARNING: Normally I try to make my posts non-techie. I failed at this one. Sorry! If the post stops making sense, then just stop reading. I promise that tomorrow’s post, whatever it is, will be much less techie.
Onelogin’s blog post on the subject of the breach said that an attacker obtained a set of Amazon authentication keys and created some new instances inside of their Amazon environment. From there the attackers did reconnaissance. This started around 2 PM. By 9 PM the attackers were done with their reconnaissance and started accessing databases.
The information the attackers accessed included user information, applications and various kinds of keys.
Onelogin says that while they encrypt certain sensitive data at rest, at this time we cannot rule out the possibility that the hacker also obtained the ability to decrypt the data. Translating this into English, since Onelogin could decrypt the data, it is possible or even likely that the hacker could also decrypt the data.
That is all that Onelogin is saying at this time.
Motherboard says that they obtained a copy of a message that Onelogin sent to their customers. They count around 2,000 companies in 44 countries as customers. The message gave instructions on how to revoke cloud keys and OAuth toktens. For Onelogin customers, this about as bad as it can get. Of course, Onelogin is erring on the side of caution. It is possible – but no one knows – that all the attackers got was encrypted data before they were shut down. It is also possible that they did not have time to send the data home. But if they did get the data home, they have the luxury of time to decrypt the data, hence the reason that Onelogin is telling to expire anything and everything from keys to certificates to secret phrases – everything.
The way Onelogin works, once the customer logs into Onelogin’s cloud, Onelogin has all the passwords needed to be able to manage (aka log in to) all of a company’s cloud instances and user accounts. In fact, one of the reasons that you use a system like Onelogin is that it can keep track of tens or hundreds of thousands of user passwords, but to do that, it needs to be able to decrypt them. Needless to say, if they are hacked, it spells trouble.
One thing that is important to distinguish. Consumer password managers like LastPass also store your passwords in the cloud to synchronize them between devices, but those applications NEVER have the decryption keys. If the encryption algorithm is good and the passphrase to protect them is well chosen, even with a lot of resources, it will take a while to decrypt.
For those people (like me) who are extra paranoid, the simple answer to that problem is to not let the password manager sync into the cloud. It still works as a local password manager, it just won’t synchronize between devices.
Gartner vice president and distinguished analyst Avivah Litan says that she has discouraged the practice of using services like that for years because it is like putting all of your eggs in one basket. I certainly agree with that. However, it also is convenient. A lesser risk scenario would be to have the system that manages those passwords completely under your control. You get to control the security and if an instance is attacked, only one customer is affected, instead of thousands.
This does not spell the end of cloud computing as we know it.
It is, however, a reminder that you are ultimately responsible for your security and if you choose to put something in the cloud (or even in your own data center), you need to first understand the risks and accept them and then put together and test an incident response plan so that when the worse case scenario happens, you can respond.
For a customer of Onelogin with even just say a thousand users and say those users only have ten passwords each, that means that 10,000 passwords across hundreds of systems likely have to be changed. Many of their customers are ten times or fifty timesAnd those changes have to be communicated to the users.
Incident response. Critical when you need it. Unimportant the rest of the time.