I have written about Okta for many years, back when they were an upstart single-sign-on security vendor coming of age in the era of cloud access and identity. By way of perspective, back in 2012 (when I wrote that first Network World review when I gave them high marks for their product), most of Okta’s competitors offered on-premises servers and the cloud was more of a curiosity than a sure bet. Seems very quaint by today’s standards, when the cloud is a foregone conclusion.
However, you can count me now as one of their detractors. This is why my hed says when it comes to cybersec practice, don’t be Okta.
Let’s look at the timeline over the past couple of years. During 2022 alone, they experienced a phishing attack, another major breach, and had their GitHub source code stolen. Then last year they saw two separate supply chain attacks that affected most of their customers, along with leaked healthcare data on almost five thousand of their employees. And last fall yet another attack on MGM and Caesars resorts was blamed on a flaw in their software. It is almost too hard to keep track, and I can’t guarantee that I got all of them.
Some of these attacks were due to clever social engineering, which is embarrassing for a cybersec company to fall into. Now, all of us can have some sympathy over being so compromised, and I know I have almost fallen for this trick, particularly when it comes in the form of a rando text message that asks how I am doing or something that appears innocent. But still: Don’t Be Okta. Spend less time multitasking, particularly when you are on your phone, and focus on every message, email, and communication that you receive to ensure that you aren’t about to play into some hacker’s hands. Pay attention!
Some of these attacks were due to bugs in how Okta set up their software supply chain, or poor identity provisioning, or a combination of things. Okta’s CSO David Bradbury was interviewed over the weekend and promised to do better, rolling out various security controls in an announcement last week. That’s great, but why has it taken so long?
One weakness that was repeatedly exploited by attackers was Okta’s lack of attention when it came to provisioning admin-level users. They are now making MFA required for all customer admin consoles. They are also requiring passwordless access for all internal employees. It has taken them, what 15 years and multiple hacks to figure this out? Neither of these things are heavy lifts, yet I still talk to many folks who should know better who have resisted implementing these tools to protect their personal account logins. Don’t Be Okta!
How about better and more transparent breach reporting? Some of those supply chain attacks took months to figure out the depth, nature, and cause — and then for Okta to properly notify its customers. As an example, the September attack was initially estimated to impact one percent of its customers, before being revised to 100%. Oopsie. That doesn’t bode well for having a trusted relationship with your customers. The EU requires breach notification in two days. Was someone asleep or was management at fault for taking its sweet time getting the word out?
Buried in all the good cheery messaging from last week was this little tidbit: “As more features are rolled out in early access mode, the company intends to turn the controls deemed most beneficial on by default.” Ruh-oh. Turn them all on by default, right now! You want security by design?
Bradbury ironically admitted that security has never been a value historically for the company, and claims that almost half of their engineers are now working on security, apart from an actual security team. Just adding bodies isn’t necessarily the right move. Everyone needs to be focused on security, so I ask what are the other half of the devs doing that gives them a pass?
This isn’t the way forward. Don’t Be Okta! Take a closer look at your own security practices, and ensure that you have learned from their mistakes.