Okta and the Lapsus$ breach: 5 big questions

We certainly have more details on the Lapsus$ breach of a third-party Okta support provider than we did yesterday at this time. But some major unanswered questions still remain.

David Bradbury, CSO at the prominent identity and access management vendor, released two more updates and gave a webinar presentation during the past 24 hours. Microsoft also released its own findings on the Lapsus$ hacker group, offering some clues about the threat actor’s tactics and motives.

But numerous questions remain, including about the timing for the disclosure of the incident; the first few days of the hacker group’s access; the potential impact on customers; the “blast radius” of the attack; and the motives of the Lapsus$ hacker group.

I’ve compiled details on these five questions below, after connecting today with a Forrester analyst and a number of security vendor executives who’ve been following the situation closely.

Okta did not have a response to these questions, saying that its public statements on the Lapsus$ breach are contained in its blog posts.

On Tuesday, Okta acknowledged that Lapsus$ — a group that has also hacked Microsoft, Nvidia and Samsung —had accessed the account of a customer support engineer, who worked for a third-party provider, in January.

“The Okta service has not been breached and remains fully operational,” Bradbury said in one of the posts.

Okta has identified the breached third-party provider as Sitel, which provides Okta with contract workers for customer support. Sitel, in its own statement, said the breach was contained to “parts of the Sykes network” — referring to Sykes Enterprises, which was acquired by Sitel last year.

What follows are details on five of the biggest remaining questions about Okta and the Lapsus$ breach.

1. Why didn’t Okta disclose the incident sooner?

The actual answer, of course, is that Okta didn’t have to disclose anything (though that may not be the case for much longer, if the U.S. Securities and Exchange Commission adopts proposed rules for cyber incident disclosure).

But that doesn’t mean that Okta couldn’t have disclosed that something had happened, says Andras Cser, vice president and principal analyst for security and risk management at Forrester.

Okta’s timeline of events shows that on January 20, the company investigated an alert related to the cyber incident. (The alert was prompted by a new factor being added to the Okta account of a Sitel employee in a new location.) Okta escalated it to a security incident that same day, and the next day, Sitel reported that it retained “a leading forensic firm” to do a full investigation of the incident.

Okta, however, did not disclose anything about the incident until Tuesday, after Lapsus$ posted screenshots on Telegram as evidence of the breach.

“The moral of the story is that if you have a problem [of this magnitude], you might want to just disclose this when it’s fresh — and not wait two months,” Cser said.

For Okta, “that [delay in disclosure] is why this is this is bad, right?” he said. “It’s not because they got breached — that happens. The fact is that they did not make any sort of disclosure.”

And while companies in this position are not always legally required to disclose anything, “a lot of companies actually choose to do so,” Cser said.

The bottom line is that “if you have a security incident, maybe it’s worth disclosing it to the public and getting it over with. Because otherwise, something like this can happen,” he said.

Bradbury has said he was “greatly disappointed” by how long it took for Okta to receive a report on the incident, but has not indicated he believes Okta should have disclosed the incident sooner. The closest he came was to say that after Okta received a summary report about the attack on March 17, “we should have moved more swiftly to understand its implications.”

Cser said that much of the backlash about Okta’s lack of disclosure stems from the fact that the company is a prominent vendor in the cybersecurity industry, and thus is being held to a higher standard than some other companies might be. Okta’s stock price plunged 10.8%, or $17.88 a share, today.

A disclosure doesn’t need to be substantial, Cser noted. It can be as simple as saying, “We saw this problem, we are investigating — and once we know more, we’ll let everybody know what happened,” he said.

Security researcher Runa Sandvik said on Twitter that some may be “confused about Okta saying the ‘service has not been breached.’”

“The statement is purely a legal word soup,” Sandvik said. “Fact is that a third-party was breached; that breach affected Okta; failure to disclose it affected Okta’s customers.”

“The moral of the story is that if you have a problem [of this magnitude], you might want to just disclose this when it’s fresh — and not wait two months.”

Andras Cser, principal analyst for security and risk management, Forrester

2. What happened from January 16-20?

In Bradbury’s original blog post Tuesday on the Lapsus$ breach, he said that the threat actor was able to access the third-party support engineer’s laptop for five days in January. This five-day window occurred from January 16-21, he said.

This information was based on the report from the cyber forensic firm, according to Bradbury.

Subsequently, Bradbury shared the Okta post featuring a timeline of events surrounding the incident. The timeline starts at January 20 (at 23:18 UTC), which is when Okta received the alert about the new factor being added the Sitel employee’s Okta account.

However, that leaves several days unaccounted for, noted Ronen Slavin, cofounder and CTO at software supply chain security firm Cycode. Perhaps the timeline doesn’t start until January 20 because that’s when Okta first got involved — but regardless, the forensic firm presumably has gathered information on what happened prior to January 20.

In terms of what happened before that point, “we do hope to learn more from Okta,” Slavin said. “We are eager to learn what occurred during the days prior.”

Okta specified that it “received the complete investigation report” on the breach from Sitel on Tuesday.

3. How were customers impacted?

On Tuesday, Bradbury said that as many as 366 customers may have been impacted by the Lapsus$ breach (roughly 2.5% of Okta’s 15,000 customers).

In the webinar on Wednesday, the Okta CSO clarified that the company has, in fact, “identified 366 customers … whose Okta tenant was accessed by Sitel during that period” of January 16-21.

These customers’ data “may have been viewed or acted upon,” Bradbury said in one of the blog posts, without offering further specifics.

The statements by Okta so far have not explained how customers have been affected by the breach, according to Emsisoft threat analyst Brett Callow. “The impact is not yet clear,” Callow said in a message to VentureBeat on Wednesday.

And while Sitel says it has not found evidence of a data breach of customer systems, “absence of evidence is not evidence of absence,” Callow said.

In the past, customers disclosed by Okta have included JetBlue, Nordstrom, Siemens, Slack and T-Mobile. In 2017, Okta said that the U.S. Department of Justice was a customer.

4. Why is Okta defining the “blast radius” in this way?

In cybersecurity parlance, the term “blast radius” refers to the impact that a certain cyberattack has delivered. Okta has contended the the blast radius of the Lapsus$ breach was limited to a “small percentage of customers.”

“In trying to scope the blast radius for this incident, our team assumed the worst-case scenario and examined all of the access performed by all Sitel employees to the SuperUser application for the five-day period in question,” Bradbury said in a blog post.

Thus, the 366 customers that may have been impacted by the Lapsus$ breach represent all of the Okta customers that Sitel had access to during the five-day period in January.

What isn’t clear, however, is why Okta has chosen to define the “blast radius” in this way.

“If the incident was isolated to one support engineer at Sitel, we’d like to understand why the blast radius is not limited to what that individual accessed,” Slavin said.

Okta has specifically stated that their “SuperUser” app for support engineers did not have “god-like” functionality — couldn’t access all users — and was built with least-privilege as a core principle, Slavin noted. Based on what is now known, it makes sense that the blast radius should be isolated just to what Sitel could possibly have accessed, he said.

And yet, least privilege is a concept for individual users, not teams. “This begs the question of why Okta’s scope [included] everything the team could access, rather than everything the individual did access,” Slavin said.

Okta’s statements that it has done this out of “an abundance of caution” — and in an interest in conveying the worst-case scenario — are “perfectly valid answers,” Slavin said. However, “we are simply hoping to see more clarification as the investigation unfolds.”

5. What was Lapsus$ trying to accomplish?

Perhaps most perplexing of all is the question of the threat actor’s motive in the Okta attack. Unlike cybercriminals focused on breaching a system to eventually solicit a ransomware payment, for instance, the actions taken by Lapsus$ to breach Okta’s service provider did not have an obvious financial angle.

If the hacker group was trying to gain access to Okta customers, in order to monetize that down the road, publicly disclosing the attack wouldn’t make any sense, said Stel Valavanis, founder and CEO of managed security services firm OnShore Security.

In terms of the goal of the attack, “I’d say it was a way to gain a foothold into other organizations. But then why be so vocal about it?” Valavanis said.

It’s also noteworthy that Lapsus$ did not make any demands at all — at least not on its Telegram channel — prior to posting the screenshots this week.

The closest thing to a clue on motive is the group’s statement, in the Telegram post about Okta, that “for a service that powers authentication systems to many of the largest corporations (and FEDRAMP approved) I think these security measures are pretty poor.”

Lapsus$ followed up with another post on Tuesday, criticizing Okta for a number of its security measures.

Cser said these statements suggest that, at least in the Okta incident, Lapsus$ has been aiming to deliver reputational damage to Okta for some reason.

“It may be that they want to try to weaken Okta’s position in the market, and try to tarnish their brand image,” he said.

That, of course, just leads to another question: Why? And at their own behest, or someone else’s?

The possible answer to those questions would require some wilder speculation, so I won’t go there. But the fact that some in the industry are even speculating about these sorts of possibilities is evidence that Lapsus$, so far, is proving very difficult to read.

Across the group’s series of recent attacks, there has been “a mix of financial targeting and some hacking of IP,” said Oliver Pinson-Roxburgh, CEO at cybersecurity services firm Bulletproof. “There is no one clear direction or motive for the group.”

Researchers at Microsoft — which confirmed this week that it has been among the Lapsus$ victims — believe that Lapsus$ is “motivated by theft and destruction.” The group has in some cases extorted victims to prevent the release of data, but in others has leaked data without making any demands, the researchers said.

Based on the evidence so far, there’s also another possibility, said Demi Ben-Ari, cofounder and CTO at third-party security management firm Panorays.

The approach by the group seems to signify that, at least in part, “their tactics here are for fun,” Ben-Ari said.

Though any “fun” — connected to a series of incidents that has now impacted at least four global tech powerhouses, in the span of a month — has most definitely been one-sided.