I’ve been an Okta customer for over 15 years; both my Enterprise Security teams at Adobe and Cisco deployed their services and partnered with Okta on external facing services. Now, I’m a happy customer as we (Banyan) also leverage their services.
With all of the mud being slung regarding the Okta breach recently, I found it important to state that I’ve got huge respect for Todd and the team, as well as David Bradbury, their CSO. So, reading their post on the latest breach, I was pleased to see transparency and an effort to keep the faith. The reality is we are all under attack, and the greater your success, the bigger a target you become.
Okta Breach Takeaways for the Broader Community
A few things jumped out to me that I think would make common sense for not just Okta, but all of their customers:
- The opening sentence, “Okta Security has identified adversarial activity that leveraged access to a stolen credential to access Okta’s support case management system.” Wait a minute, stolen credentials? If Okta (or your company) deployed device registration, passwordless, and device posturing, then stolen credentials are useless. I was sure Okta even sells this dream to their customers. It’s something that my team deployed in Adobe in 2017 as part of our ZEN project. In 2019, we refined the architecture as part of becoming a customer of Banyan Security.
- Storing data unnecessarily is a topic security and privacy professionals talk about a lot. This incident is a reminder not to store data if you can help it. If the case is closed, could the data be deleted, or at least could the higher-risk data be protected? Similar to “just in time” (JIT), the data can be erased once it’s been leveraged for its function. There’s certainly a balance of running the business with the least amount of friction, especially in a customer support scenario. But, deleting any files uploaded by customers once the ticket is closed would be something worth investigating.
- It was also mentioned that “Okta recommends sanitizing all credentials and cookies/session tokens within a HAR file before sharing it”. Is this displayed to the customer before they submit the HAR file? In addition to protecting higher-risk data and deleting files after a ticket is closed, we have to let the customer know to sanitize the HAR file from cookies and session tokens that can be used to impersonate a valid user. Even if an attacker was able to access the file, they would not have access to the customer’s sensitive information.
To repeat, I’m a huge fan of Okta, so this isn’t a pile on them; we’re all under attack. Rather, if step one is to use stolen credentials, then let’s move faster to blocking that attack vector. This was something my Enterprise Security team at Adobe tackled in 2017, replacing passwords with certificates tied to the user and device, requiring a device be registered in order for a user to log in, and enforcing a security posture on the device.
This means a bad actor is unable to log in as your users, even with stolen credentials. It’s how my Adobe team met Banyan and something Banyan has delivered to its customers for over six years. So, as a kind of rant I guess, this sh*t doesn’t need to happen… oh, and we integrate seamlessly with Okta, but also any other SAML or OIDC IDP.
If you need some strategic guidance on getting started down this path, drop me a line.
Den Jones
CSO, Banyan Security
