An Alternative Take on the Lapsus$ / Okta Security Incident

Allow me to offer you an alternative viewpoint on the Okta security issue. By way of background, I spent over a decade as an incident response expert, responding and supporting over 1,000 incidents - said another way, I've seen some things. In my current role as a CISO, I work the other side of the coin - doing everything I can to prevent an incident from occurring.

Here's my take. With the information that Okta had in January, they responded appropriately. Again, the key here is the information they had in January. At that time, all indications showed the incident being a run of the mill failed account takeover attempt. Any company of Okta's size addresses hundreds, if not thousands, of those attempts every year. At the time, it was a non-issue - nothing to report. It's the equivalent of when one of your employees has an attempted account takeover.

It's easy to think that they went months without notifying their clients but that wasn't the case. In January, there was no knowledge of an incident. Let's also not lose sight that Okta detected and contained the incident within 70 minutes of identifying the failed MFA attempt. Compare that to Mandiant's 2021 M-Trends report, where the average dwell time before detection was 24 days.

Could Okta have done things better? Sure, there's always things we can do better. Was the backlash warranted? I don't think so. For their overall response efforts, I'd give Okta a B+. Here's why.

Background

On March 22, 2022, news from the Lapsus$ hacking group's alleged Okta hack spread like wild fire. Before you could spit the coffee out of your mouth, speculation and accusations began to fly. IT and Security professionals grabbed the digital pitch forks and torches and took to social media in protest. At initial glance, it felt warranted given the potential impact.

Why was the Internet Upset

The potential impact of a security incident with Okta can difficult to wrap your head around. Okta serves as the main identity provider for many companies. They are the source of truth for account authentication for many companies. Your Okta accounts provides access to other company resources - from email to various SaaS applications your use on a daily basis. A compromise of Okta, could mean the compromise of all of your company data and assets - that would make for a very bad day.

For many security professionals, the key issue came down to a perceived breakdown in communication and ultimately trust. For Okta, trust is critical. Initial communication from Okta could be perceived as choppy, though I think allegations of that were overblown. Okta released a full breakdown and analysis within 24 hours - that's impressive given the investigation that had to happen to get to the point where they could come out with real information. Breach communication is always a balance between speed and accuracy of information.

Many people latched onto the January time frame. Allegations of waiting months to report the incident fueled the anger. Again, my personal feeling on this is that the reaction was not warranted, especially as the detailed blog post came out with a full explanation.

To help put people at ease, it's important to look at the time line of activity.

Detailed Timeline of Activity

• January 16, 2022 00:33: Lapsus$ gained access to a Sitel system (Okta third party provider). There was no additional activity until January 19, 2022.
• January 19, 2022 - January 20, 2022: Lapsus$ connected to a Sitel system using RDP and began performing reconnaissance of their environment. This was standard attack activity of escalating privileges, grabbing passwords, etc.
• January 20, 2022 23:02:41: Lapsus$ authenticated to a Sitel (Sikes) Office365 account. This is where things really start to heat up.
• January 20, 2022 23:18: Okta Security received an alert around an MFA challenge from a new location. The attempt was unsuccessful. The account was tied to a customer support engineer at Sitel, an Okta third party vendor.
• January 20, 2022 23:46: Within 28 minutes, the Okta security team investigated the alert and escalated it to a security incident. Very impressive response time, in my opinion.
• January 21, 2022 00:28: 70 minutes after the failed MFA challenge, Okta suspended the user account and terminated all active sessions. This effectively contained the account takeover issue. This is where Okta's sphere of knowledge lived at the time - there was no knowledge of the larger issue at Sitel.
• January 21, 2022 18:00: Less than 24 hours later, Okta shared the indicators of compromise with Sitel about a potential incident in their environment.
• January 21, 2022 - March 10, 2022: Sitel performs an investigation into their environment with Mandiant. Oof, that's a long time - and with zero communication back to Okta.
• March 17, 2022: Okta receives a summary report from Sitel. It's important to note that most summary reports do not contain useful information.
• March 22, 2022: Lapsus$ leaks screenshots from the compromised Sitel employee's system. The Internet goes wild.

How Should We Look at This?

Let's take a second to breath here and assess what really happened.

• Lapsus$ gained access to an Okta third party provider, Sitel, who performed customer support services. That is where the real security lapses occurred. While Sitel had access to Okta resources (Slack, customer support tools, etc.), the impact was relatively small. Okta designed their systems with least privilege in mind. This means that a low level customer support engineer would not have access to do much of anything. There was no unauthorized access to Okta's production systems that manage authentication for their customers.
• Okta detected and contained the incident within 70 minutes of an unauthorized logon attempt. Mandiant's M-Trends 2021 report highlighted the average dwell time of attacks was 24 days. This stood out to me as one of the more impressive things of the incident and gets lost in the other noise.
• Sitel, the Okta third party provider who Lapsus$ compromised, took 48 days to investigate their environment. That's a really long time and with no communication back to Okta. In opinion, this is the breakdown in the entire situation. Given the initially perceived mundane nature of the account activity, I completely understand why there wasn't follow up. That doesn't excuse what happened, but security teams operate with a limited set of information at times and the response feels appropriate for what was known.
• The 366 potentially impacted customers of this is a very conservative approach. The number is all of Sitel's employees access to Okta's resources between January 16, 2022 and January 21, 2022. That's well outside the time of activity Lapsus$ was active in the environment.

Lessons Learned

With the luxury of not having a serious security incident, we have the opportunity to get some great lessons from what occurred here. Here are my takeaways:

• Third party risk management is difficult. Ensuring that your vendors have the proper security controls is critical before an incident occurs. You can manage this by enforcing secure access to your environment and the vendors. Ensure that the controls you enforce for your employees is also met by the third party vendor's own environment. Security is transitive in nature - their risk extends to you.
• When an incident with a third party provider happens, ensure you receive answers in a timely fashion. Quantify the risk appropriately and push to get the answers you need to understand the potential risk. This is easier said than done.
• In incident response communications, you can have speed or you can have accuracy. Balancing the two is very difficult. Attempt to own the conversation early on. Okta's CSO's response was great - he took ownership, acknowledged the breakdowns, and went out of his way to provide opportunities to connect with clients. This is not easy to do when you operate at Okta's size.

Additional Resources

Okta's detailed blog from March 23, 2022

Leaked Mandiant Summary Report