How OneLogin Was Compromised and the Lessons for the Rest of Us As painful as breach incidents are for the service provider and affected companies, they also offer a teaching moment.
By Dimitri Sirota Edited by Dan Bova
Opinions expressed by Entrepreneur contributors are their own.
Last week, OneLogin, one of the leading U.S. Cloud Single Sign-On (SSO) services, suffered a major breach, compromising U.S. customer data. The good news was that OneLogin was able to identify the compromise within hours and respond by shutting down the rogue instances responsible for the service failure. However, highlighting the swiftness with which these attacks can take place and have effect, that was still enough time for the thief to likely purloin customer data and more ominously, their login credentials for accessing cloud services and even their encryption keys for decrypting data in those cloud services.
As painful as breach incidents are for the service provider and affected companies, they also offer a teaching moment that can help inform future behaviors and defenses. In the case of OneLogin, because the attacks intersected a service that essentially managed passwords in a central location in the cloud that can be configured through an API, there are many lessons at the nexus of many modern challenges including cloud, API, consumer passwords, privileged administrator identities, event notifications, breach mitigation and breach response regulations.
Related: Just Being Proactive Isn't Enough: What Entrepreneurs Should Do During a Cyberattack
The inherent risks of centralizing keys to the kingdom in the cloud
The cloud has revolutionized how businesses consume IT services over the last seven years. It offers on-demand flexibility, no startup cap-ex and ease of use. However, it comes with its own set of risks. Cloud SSO services symbolize both the convenience and risks of the cloud. Firstly, accessing cloud services using an on-premise credential management system is extremely challenging. There are firewall issues, connector update issues and operational complexities. Running a cloud SSO service from the cloud makes sense on many technical and business levels. However, it of course creates a single point of failure by placing all credentials in a central place that acts as an attractive honey pot for bad actors. This means both SSO providers and their customers need to take extra precautions.
Managing the administrative logIns for the logIn service
For the service provider, the simplest and most critical security that can be built around the service is to protect against potential administrative hijacking of the service. That is apparently what felled OneLogin; an attacker was able to steal an administrative credential that was then used to provision a rogue service that then accessed provisioning/admin APIs to copy customer credentials to the rogue instance. As it happens, technology exists to limit risk around stolen administrative credentials and protect APIs. PIM, or Privileged Identity Management, tools provide single use password vaults for administrative accounts that limit their access and utility if stolen. Similarly, API security products exist that can provide stronger access protections and detection of unusual activity around administrative APIs and shut down sessions before they can prove damaging.
Related: What Happens When Your Small Business Is Hacked
Splitting keys, stepping up authentication
For customers, there are also actions they can take if their service provider is compromised. The simplest is to split encryption key management from access credentials. Isolation and separation of duties is always a good security strategy. So is stronger authentication. Many services now offer authentication based on not just something you know, like a password, but also something you have or bring, like a mobile phone or fingerprint. The latter are far harder to compromise because the possession of passwords alone is insufficient to access a client account. In this day and age, with the prevalence of mobile phones and biometric authentications, there are no excuses for not insisting on stronger authentication from your service provider.
Related: The Worst Hacks of 2017 -- So Far
After the breach
Now, while the OneLogin incident provides many lessons to both service providers and their customers on how to prevent or limit fallout from a similar attack, it also tells a story on what needs to be done in response to a breach.
For a service provider, of course the top concern is detecting the breach and limiting any damage. Good audit/security information and event management (SIEM) tools can help here, especially if they offer anomaly detection to detect strange activities. But, then comes the step that arguably is the most difficult and costly: understanding who was affected and making appropriate notifications and responses.
Fast breach response
Today 48 U.S. states and most foreign countries have laws on breach response requiring a specific type of notification within a prescribed time period. What makes this difficult for service providers (and the affected companies) is that they rarely track customers by residency and almost never have an inventory of that person's or organization's data so they can properly audit who was compromised and what data was taken. To answer this problem, new tools exist in the privacy management space that can map data for every customer by state or country and make legal response easier while also helping the service provider audit what was taken.
Related: Security for Startups: Protection on a Budget
For the affected companies, there is a similar need to understand the scope of damage from a compromised service provider. Keeping an inventory of what sensitive data is accessed through what service can insure impacted downstream users can be adequately forewarned to take appropriate actions before damage can spread.
The lessons of OneLogin
There is a saying that no bad experience should be experienced without something learned. What happened at OneLogin was painful for both the service provider and affected companies. However, rather than run away from using cloud services, for the affected companies there are many takeaways that can be learned to limit future fallout and impact. For the service provider, there are similar lessons around extending the protective umbrella to administrative accounts and APIs. OneLogin showed how even a security service can be compromised by one set of credentials; therefore it's recommended to always take extra steps to protect your most vital assets.
