Okta comes under scrutiny for withholding Lapsus$ hack in January

"On January 20, 2022, the Okta Security team was alerted that a new factor was added to a Sitel customer support engineer's Okta account." This is how Okta began a timeline detailing a data breach report published on March 25 — two months after the breach. The identity management company handles profile and interaction data for hundreds of clients, including big firms such as Hewlett Packard, Zurich, Standard Life and Renault, but states that only a very small percentage (2.5%) were affected in the hack. That may seem minimal, but when the company has an estimated 15,000+ customers, this is potentially a huge amount of data at risk.

A stethoscope beside a computer keyboard with a padlock on it.
Not speaking out about a data breach can cost companies in reputation, just as much as in resources.

So why has it taken so long for Okta to come forward? It looks like the admission has been somewhat forced by hacker group Lapsus$, who have publicly taken credit for the January breach. Posting on Telegram, the group has divulged information about hacks to big brand tech companies Nvidia, Samsung, Ubisoft and Microsoft, as well as Okta. In a statement issued by David Bradbury, Chief Security Officer, Okta initially made clear that their "service has not been breached and remains fully operational." Bradbury revised this with an addendum later in the day, assuring that a thorough investigation was underway to verify the claims made by Lapsus$, and that they had indeed identified some customers who may have been impacted. Those customers had been contacted directly and Bradbury personally hosted live webinars to provide more technical information privately.

How was Okta breached?

While apologizing to its customers for not being sufficiently forthcoming, Okta has also made it clear that the primary breach occurred elsewhere; a "sub-processor" company utilized by Okta called Sitel.

Okta asserts that in January a Sitel employee's Okta account was compromised with the addition of a suspicious password. This password failed a multi-factor authentication (MFA) challenge and was flagged and escalated to a security incident, which Sitel acted upon by engaging a forensic firm to investigate further. A summary report of that investigation didn't become available to Okta until mid-March. Perhaps coincidentally, it was within just days of receiving that report that Lapsus$ then shared screenshots of the breach online.

The conclusion made by Okta from reviewing the investigation is that a Sitel support engineer's computer was compromised using remote desktop protocol (RDP). The mechanics of this access have been likened by Bradbury in a subsequent article to "walking away from your computer at a coffee shop, whereby a stranger has (virtually in this case) sat down at your machine and is using the mouse and keyboard." He goes on to explain the level of access permitted to a support engineer, reassuring readers that despite its title of "Super User" it "does not provide 'god-like' access" and any actions the perpetrator could undertake were exceptionally limited.

What to learn from this incident

This case excellently illustrates how the integration of systems from one company to another can have such a significant impact on security. It is evident that Okta maintains the line of having confidence in their own protocols, but in this case it had not factored in the mechanics of how these synchronize — or not, as the case may be — with peripheral organizations and systems, such as the "sub-processor" Sitel. Terminologies like streamlining are freely used in relation to collaborations between organizations, but to really implement succinct processes and to synchronize fluidly requires a great deal of work. Work that is well worth the effort to avoid such complications as experienced by Okta.

Had the initial occurrence been handled differently in January, with a swifter and more comprehensive coordination with Sitel, Okta may not be receiving the negative backlash that it now faces. The fallout factor must be considered here. Compare the public sentiment for Okta against that of competitor Microsoft, as VentureBeat has done in a follow-up article. Microsoft was named by Lapsus$ as another breach victim around the same time as Okta, but you can see a distinct difference in how the world — and particularly customers — took the news. An open letter to Okta, posted on LinkedIn by Tenable CEO and Okta customer, Amit Yoran summarizes the feelings he believes he shares with many in the same situation. Inevitably, fear and frustration permeate for those concerned when information is lacking. "Trust is built on transparency and corporate responsibility, and demands both," states Yoran. This is often true in regard to breaches of this nature; customers want and need to know the details so that they can act accordingly. Even if all the information isn't immediately available, clients are put at ease when a service provider informs them of an incident and what steps are being taken to investigate and/or remedy the situation.

Needless to say, Okta will have some repairs to make not only to internal processes and security protocols, but also to the company's image as a trusted provider of secure services.

Here at the Inventu Corporation, we equip organizations of all sizes with a revolutionary web terminal emulation tool called Inventu Viewer+, a high performance emulation solution that is built with C at its core. Inventu Viewer+ supports SAML 2.0 and other identity technologies to enable securing your critical mainframe applications. This allows deployment of reliable and safe software using clean HTML and JavaScript hosted on secure Windows servers. All in all, the Inventu Viewer+ web terminal emulation meets employer and staff expectations in a way that feels both familiar and simple. Contact us today and see how Inventu can help you integrate your active terminal emulation with the best web identity frameworks available.