Some lessons from Okta breaches

March 30, 2022

The Lapsu$ breach shows some of the consequences of not following the best practices, but also some of the hard truths of the current state of cybersecurity:

The password managers

Lapsu$ found a file named “DomAdmins-LastPass.xlsx” . There is a lot to unpack here. First, there was use of a password manager in Okta which indicates that users had a way to “securely” store credentials. This is great but I wonder how many people inside Okta really use LastPass and know the different features it offers.

We can have different technologies but if we don’t use them correctly they can lose their purpose. And this is a case of that, LastPass was not used for it’s purpose and even if they needed to share passwords there is a way to share credentials using Lastpass. Passwords in files must not exist. I believe Okta was lucky that Lapsu$ did not deploy ransomware to all computers in the domain.

meme p1

Constant event monitor

Event monitor is important, after all we cannot find what we don’t look for. But security teams have a limited amount of time in a work day and they have other projects or activities. Also security teams cannot be updated to all different APTs or TTPs found, threat intelligence is a must to start prioritization of activities.

The Okta team did not monitor the events, but nor do most of the companies in the world, it is a deficiency that attackers know and defenders should be aware of. Start automating detection and response as you go, tune your alerts to get real incidentes and not false positives and help your team to get prepared with new information and opportunities to learn.

Privilege control is still a weakness

When study how to defend a network, privilege creep and excess of privileges are always mention. I believe that Okta may have had that same problem so that they couldn’t realize that a new tenant admin was created, this encompass the lack of prover privilege control and that they missed detection over their cloud infrastructure.

On the other hand, sometimes operations can create accounts with too many privileges in order to “make it work properly” and the security team has to deal with it as some projects cannot be delayed. There should be a policy that helps prevent this, a policy that forces users to define what privileges are needed for the account but also u fear for the amount of work this policy may mean for security teams.

admin priv

Security requirements for contractors

Business partners are important for companies in order to ensure giving proper services to clients. But when a business partner has access to your infrastructure, they bring their own risk to you and you need to be aware of this. Having a policy that defines what to do in case of an infected machine or a usb with infected files can help reduce the risk in case of an incident.

If Okta would have stopped connection from the infected machine to their infrastructure until the machine was cleaned, the breach could have been avoided. I have to remember that this policy should be enforced, so this means more work for the security team and operations.

Start automating but not replacing:

Automation is a key part of security operations, we need to reduce the amount of work of the security team so they can use their time in the event that they need to monitor. But this does not mean that the security team should be replaced.

Ensure you have a highly trained team that can detect what your product does not and that can use the tools you have. That will, obviously, better results than just using a security team with no tools or tools with no security team.

is this mikiketz

These are my opinions on this breach, hope you found these helpful in some way. Until next time. Can read more of this case in this tweet


Profile picture

Written by Frog hi, hope you can find something useful in this blog - fr0g74