Okta CEO Todd McKinnon
Photo: David Paul Morris/Getty Images/Protocol

Can Okta be trusted again?

Protocol Enterprise

Hello and welcome to Protocol Enterprise! Today: Okta CEO Todd McKinnon tells Protocol what went wrong with the Lapsus$ breach and why it can never happen again, ServiceNow makes a bold revenue pledge, and college students rebuilt this legendary World War II machine in a semester with modern tech.

Spin up

Communication problems could be the easiest route for AI technologies into the mainstream enterprise. According to new research from Red Box, 42% of business leaders think AI could help them understand accents and different languages, which is a tricky problem for customer-support organizations.

Just please use MFA

Okta co-founder and CEO Todd McKinnon agrees with you: Disclosing a breach that impacts customer data should not take months.

In January, the hacker group Lapsus$ found its way on to the laptop of an engineer at a third-party Okta support provider — initially thought to have given the group access to potentially hundreds of Okta customers. A later investigation that incorporated additional information found that just two customers were impacted, according to Okta.

But the breach itself was never the main concern anyway. Many honed in on the fact that it was Lapsus$, not Okta, that told the world about the incident, posting screenshots as evidence on Telegram in March. This raised more than a few questions about Okta's handling of the months-old breach.

Protocol spoke to McKinnon about the customer concerns, how the breach's impact turned out to be a lot lower than previously feared and the security changes Okta has made in response.

This interview has been edited and condensed for clarity. A longer version can be found here.

Looking back on Okta’s handling of the incident, what could you have done better?

The top thing in my mind is making all of the environments completely secure for the support people who are accessing Okta. We've spent so much effort making sure the Okta product and platform are secure, and then making sure the employees of Okta operate in secure environments. The third-party support organization was in another ring outside of that. So we need to make sure that's secure as well.

Sitel didn’t use Okta, and that was part of the problem?

Exactly. We know this after the fact, because they brought in a forensic firm to do a full breach assessment. What we learned from that was, the way the attacker got in originally was through a VPN gateway, which didn't have multifactor authentication on it. So the most basic thing you do when you implement Okta is you make sure that all of your systems, whether it's email, or VPNs, or any of your SaaS apps, or your cloud infrastructure — all use an authentication policy that's strong. And MFA is the basic [policy] there. And then once [Lapsus$] got in, they were able to use a bunch of Windows vulnerabilities to move around and escalate privileges. They were also able to get into Office 365 — because again, it didn't have multifactor authentication on it. One of the basic things Okta does is it puts multifactor authentication on Office 365. So it's very ironic.

This went from a five-day incident potentially affecting 366 customers to a 25-minute incident affecting two customers. Could you explain the discrepancy there, why it’s such a big change?

It’s [due to having] more information. There were two [investigation] reports. There was the original report that was done for Sitel. And then there was the report that we've sent to our customers, that was done by a different firm, that had access to all of the forensics information across both services — Okta and everything inside of Sitel.

The original report, that established the five days and the 366 customers — the forensics firm didn't understand the potential impact to Okta. So they didn't drill into all those detailed forensics that could narrow down this impact. They just saw which machines were compromised and which Office 365 accounts were compromised. So we're actually thankful to Sitel for collaborating and giving that information to this third party, to further narrow down the impact.

One of the things I'm proud of is that, I think throughout this, we did make decisions that were helpful for customers. It would have been really easy, after the first 24 hours, to just take a super optimistic and narrow view of what the potential impact could be — given that we didn't have all the information that came out over time. We could have easily said, "It's probably just a few customers" — hoping that would be true. But we said, “The full, maximum potential impact is these 366 customers,” knowing that there was probably a 99% chance that it was going to be less than that.

As you said, this wasn’t an uncommon reaction by customers to feel concerned about Okta’s handling of the disclosure.

I understand why they thought that. Because whether it's Okta, or a partner, or a third party — when there's a compromise like this where an attacker can see any kind of Okta support information, or customer user IDs, or email addresses — if that happens in January, customers can't be finding out about it in March.

So the first step, as I mentioned, is: We can't have the support application used in insecure environments. We’ve got to make sure we're not in that situation. And the second step is: If there are any issues, we have to make sure that we follow up on it. [In the January incident] our security operations center detected a failed account takeover attempt, and we notified the third party that there was something going on. Now these failed account takeover attempts happen pretty frequently. But if we detect one of these in our own environment, we [need to] make sure we run it down and make sure that there's nothing going on there.

The most important thing of all of this is that customers understand how seriously we're [taking this], and making sure this doesn't happen again.

— Kyle Alspach (email | twitter)

A MESSAGE FROM LOGITECH

In the New Logic of Work, solutions meet people where they are now, not where they were last year or even last week. And it means providing tools and experiences tailored to different people and roles in an organization. At Logitech, our products create opportunities for people and organizations to thrive.

Learn more

ServiceNow doubles down in Vegas

LAS VEGAS - The software industry is in the midst of a tumultuous time. But at ServiceNow, CEO Bill McDermott is nothing but optimistic about the vendor’s outlook.

On Tuesday, at a company conference in Las Vegas, McDermott outlined new financial targets. ServiceNow now expects to hit $11 billion in revenue by FY 2024, higher than the $10 billion that McDermott previously forecasted. It also expects to hit $16 billion by FY 2026, up from the prior estimate of $15 billion.

“We couldn't be more excited or more positive about where ServiceNow is going,” McDermott said. The company “has established itself as an enduring platform.”

The numbers are a clear attempt by McDermott, the consummate salesman, to separate ServiceNow from other software companies like Zoom that saw a boom in sales in the pandemic but are now struggling to maintain that momentum.

The rosy estimates come as ServiceNow aggressively expands beyond its core IT business into new verticals like low-code application development and ERP, as well as industry segments like manufacturing, which is helping the company sell higher-priced contracts.

Under McDermott, the company has also struck lucrative partnerships with industry giants, big-name consulting firms and up-and-coming vendors like Microsoft, KPMG and Celonis.

The proof — at least, so far — is in the numbers. ServiceNow continues to report strong financial results. In the three months through March, overall revenue grew to a better-than-expected $1.72 billion. However, its stock has dropped 40% since a November 2021 high amid a broader Wall Street sell-off of software stocks.

— Joe Williams (email | twitter)

Spies like them

During WWII an Allied intelligence project called Ultra helped decypher messages sent by the Nazis via their Enigma encryption machine. The project was so crucial to the Allied success on the battlefield that its existence wasn’t publicly disclosed until decades later.

Earlier this month, three students taking a microcontroller design course at Cornell re-created the machine used by the Allies to decrypt messages encoded with the Enigma machine on a hardware platform designed around a programmable chip, or FPGA. Called the Bombe machine, the original design was developed by Alan Turing in the U.K. A recent attempt to make a replica took 13 years but the students made their version in a semester.

According to the students, the goal of their project was to see how much more quickly a digital version of the original mechanical device would decrypt Enigma messages.

To do so, they coded a version of the Enigma machine — the Bombe is basically several Enigmas stitched together — and then coded a version of the original decryption algorithm in modern hardware. Doing so “shortened computation time tremendously,” the students wrote. It sounds like the system is pretty simple to use, and requires one manual step to get the final decrypted message that, given more time, could be automated.

— Max A. Cherney (email | twitter)

Around the enterprise

Nvidia showed off reference designs for its Grace Arm server processors as well as some liquid-cooled server designs at Computex, the chip industry’s annual confab in Taiwan.

Microsoft introduced new virtualized developer instances for companies that want to minimize the complexity of supporting hardware for their developers.

A MESSAGE FROM LOGITECH

We help individuals and teams feel seen and heard regardless of location, so they can do their best work, their way. Our solutions comprise a complete ecosystem of video conferencing hardware, software, services, and world-class partnerships. From boardrooms to living rooms, hot desks to huddle spaces—we’ve got you covered.

Learn more

Thanks for reading — see you tomorrow!

Recent Issues

The SEC vs. CISA