Are you freaking out about the Okta breach? Allow me to make some suggestions about actions you can take to ensure the security of your organization. But first, I think we all could use a puppy (and kitten!) video.

Alright, everyone. Time to check your 2022 dance cards.

• BA.2 Omicron variant.
• Putin invades Ukraine.
• Inflation.
• Gas prices.
• US Supreme Court nomination hearings.
• Okta breach.

Wait, what?

Understand How the Okta Breach Happened

According to TechCrunch and others, the hacking group Lapsus$ compromised the account of an Okta “sub-processor.” I know, I had to look that up as well. Think of a sub-processor as a contractor that Okta hires to handle some of the business processes needed to deliver the Okta service.

It appears that hackers took over an employee account at one of these sub-processors and used it to launch the Okta breach. Okta originally said they doubted that a breach occurred. But when hackers released screen shots of the Okta network, Okta changed its tune. Yes, the Okta breach occurred. But it happened a long time ago (January) and appears to have been confined to four or five days. And, trying to be helpful I guess, Lapsus$ said that it was not targeting Okta itself, just its customers.

Forgive me if I am not comforted.

Take These Steps to Protect Your Organization

Come on, you can do this! Remember one of the key principles of a Zero Trust security approach?

Assume breach.

Now that you know the Okta breach happened, take some of these steps to confirm the security of your information assets.

• Change all the Administrator passwords. Or go passwordless. Devote some devices to administration and configure them to use facial recognition, a fingerprint reader, or a hardware key to authenticate.
• This Okta breach may be a compelling reason to update your MFA process. Drop the “send a code to SMS” in favor of “use an authenticator app.”
• Check your logs. Focus on the activities that seem unusual. Did you have a bunch of failed login attempts, all in a short time? Were people accessing the network late at night or from IP addresses you do not recognize? Are there users accessing applications or sites they would not normally access?
• Review your recent support tickets. Are there tickets from users asking about “unusual activity” on their devices? Anyone reporting a computer whose CPU seems to constantly run?
• Check your firewall. Have there been attempts to contact known hacker “command and control” sites? Do you see any computers using lots of bandwidth over extended periods? Check to see if the Okta breach has led to a malware attack.
• Spin up a phishing awareness campaign.
• Think about tightening down your Conditional Access policies. Maybe you move from warning people about bad behavior to locking them out until you can clean up any messes. Of course, let people know this is coming first!
• Check to see if anyone has email forwarding set to an address outside the organization.
• Apply any system and device patches or security updates.

Some Longer-Term Lessons to Consider

Realize what just happened here: a public cloud company announces in March that it looks like it was hacked in January. But, it says, not to worry. It doesn’t look like anyone was compromised.

Of course, this is what Okta could be expected to say. I get that Okta would not want to speculate or suggest that the situation was worse than reported. But from a customer point of view, these blandishments are neither actionable nor comforting.

What are the lessons here?

• You will not find out about an event like the Okta breach until well after it has occurred. There is no opportunity for a fast response.
• A service provider like Okta will not know for some time whether your data was compromised. Waiting to hear back is not really an option for you. Rather, you will need to go out and look for yourself.
• As we saw with the Log4.js vulnerability, the supply chain for cloud services is lengthy. There are numerous links in the chain where a hacker might gain access and do some damage. You have a responsibility to understand (at a high level) the supply chain of your cloud service providers. These providers owe it to you to demonstrate that they have appropriate security controls and processes in place to harden security along their supply chains.
• You are still better off moving identity management (along with most everything else) to the cloud. Events like the Okta breach are bad, no doubt. And they get media play because “look, a cloud company got hacked!” The cloud companies will get better because their business model requires them to do so.
• The Okta breach is why you put the work into constructing your Zero Trust “defense in depth.” We are protecting information assets that live in complicated habitats. As a result, we need more than one layer of protection. That is why you do the work.

Because the Okta breach shows you it was (or is or will be) worth the effort.