EXPEL BLOG

Top 7 recs for responding to the Lapsus$ breach claims

Security operations · 2 MIN READ · JONATHAN HENCINSKI · MAR 23, 2022 · TAGS: MDR

By now, you’ve likely heard about the situation that unfolded yesterday around Okta and the Lapsus$ breach claims.

As of today, March 23, 2022, Okta’s investigation is ongoing.

While the new information and more limited scope may reduce the risk to organizations, Okta’s investigation continues and the situation remains fluid. This post will walk you through our recommendations for immediate and strategic steps you can take to protect yourself and your org.

Here are our top 7 recommendations:

  1. Rotate privileged Okta passwords and Okta API tokens.
  2. Unless a business need exists, we strongly recommend disabling of the following Okta configurations:
    • Give Access to Okta Support
    • Give Directory Debugger Access to Okta Support
  3. Review Okta logs looking at admin authentications and activity for the past four months (January 1 through March 22, 2022 is a good time frame). During this same chunk of time, check out any Okta admin activity to ensure it aligns with expected activities and sources. Specifically, review these events:
    • eventType eq “user.mfa.factor.deactivate”
    • eventType eq “user.account.update_password”

    For these types of events, you’ll need to review entries generated by non-admin users or events marked as “Okta System.”

    If an Okta account was found to have had MFA disabled during the January through March 22 timeframe, ask these two questions: Who was the user? What was the root cause of the disablement? Once you answer those, re-enable MFA for those accounts.

    From there, enable MFA on initial Okta login and on all individual applications. Consider how your organization might replace legacy MFA solutions (SMS text and digital tokens) with a FIDO compliant solution.

  4. Based on your organization’s geographical presence, consider configuring Okta network zones to deny authentication from countries your organization would consider atypical.
  5. Take some time to plan. Establish terms and conditions for incident response services before a security incident by executing an Incident Response (IR) retainer. This proactive approach can significantly reduce response time and impact. Use this as an opportunity to test your incident response plan (IRP). Don’t have an IRP? It’s time to make one. Then test it, and test it again.
  6. Communicate transparently about what you’re doing and what you’ve done to your internal and external stakeholders. The clearer you are up front, the less confusion arises as you deal with quick changes that might have a wide effect within your org.
  7. When communicating during a fluid situation, it’s important to set expectations and prepare stakeholders for change. In your communications, be clear on what decisions you’ve made, what you know, what you don’t know, and when you’ll be in touch next.

Like many of you, we’re watching the situation closely. If you have any questions about our recommendations, chat us anytime.

Blog home