Summary Action Items To Help Prevent An Okta Style Attack

Below is a condensed summary of all the action items from the Deep Dive article.

Introduction

The dust has FINALLY settled on the recent Okta hack, and we have a ton more information as Okta has updated their incident response report (see old version here). Although I did cover the Okta attack initially, there is a lot more information now.

This is a deep dive not just into all the things that went “wrong” but more importantly, all the things you and your organization can do to prevent such an attack. I think if we can’t learn from our and others' mistakes, then we’re just being lazy. 

I also use quotes for the word “wrong” as I acknowledge that information security is a tough job, however that being said there are definitely expectations out there regarding information security hygiene, upkeep, and preventative medicine. This becomes doubly so when you have been hit with a breach/compromise already.

The format of this article is divided into sections that cover what the “bad” was and include a remediation section at the end of each. They are not in any particular order of priority and all are different layers to the cake. Often attacks are successful because they opportunistically exploit multiple vulnerabilities that even sometimes seem unrelated.

Although I could have combined many of the below items into larger topics, I felt it was important to granularly break each part down as each item has its own preventative medicine.

I must commend Okta, Cloudflare, and 1Password for sharing detailed incident response reports publicly. The only way we can improve is by being transparent.

Disclaimer: The below advice is meant for companies to implement in their own information security programs and is in no way an accusation of wrongdoing or neglect of Okta or any affiliated party.

For the full Deep Dive article, check it out here.

Lessons Learned - Avoid Static Passwords

Lessons Learned - Audit & Delete Old Service Accounts

Lessons Learned - Don’t Save Passwords, Insecurely

Lessons Learned - Lockdown Company managed devices

Lessons Learned - Your Logs May Not Have The Full Picture

Lessons Learned - Universally Apply Protections To All Parts Of The System

Lesson Learned - Learn From Your Mistakes

Lessons Learned - Threat Detection and Response Must Be Adequately Size To Fit Your Threat Model

Lessons Learned - Reduce Customer Friction To Security

Lesson Learned - Protect Customer Data

Download this is as PDF

Lessons Learned - Avoid Static Passwords

• Do not use usernames/passwords whenever possible. Utilize OAuth or temporary access methods whenever possible.

• If a username/password cannot be avoided, issue separate logins that are stored in a password vault (where access can be tracked).

• Automatically change service account passwords daily/weekly/monthly based on your threat profile. This can easily be automated using 1Password API’s for example.

• Ensure service account passwords/keys/secrets are only manually accessible to a few individuals. This reduces your threat footprint.

Lessons Learned - Audit & Delete Old Service Accounts

• Review service accounts in place regularly. Especially critical or high risk service accounts that either:

  • Have a lot of access / privileges to systems

  • Are widely shared

  • Have not had their credentials rotated in the last year

• Delete unnecessary/unused service accounts

• Transition service accounts to OAuth, Certificate, or non-static password model

• Break large service accounts with a lot of permissions into smaller ones with reduced privileges. This will also reduce your attack surface area.

Lessons Learned - Don’t Save Passwords, Insecurely

• Disable the offering and storage of passwords in the browser

  • TIP: Many password managers will automatically disable this setting upon installation (see below)

• Educate users often on the handling of sensitive information such as passwords, client data, financial information, and other typically restricted information

• Educate users on the use of private resources for work

Lessons Learned - Lockdown Company managed devices

On a company managed device, you will want to lock down controls as much as possible based on your threat model/risk, and tools available to you. In this case, Device Management tools are not cheap nor easy to manage. However, if you already have them, you’re probably not taking full advantage of their capabilities.

• Restrict the use of personal accounts on highly sensitive devices and users

• Provide additional training on the use of work devices for personal use and browsing

• Limit the installation and use of apps, extensions, and other unapproved software

• Limit  which browsers can be used on the device and configured browsers accordingly

• Limit access to corporate systems from corporate devices only

• Deploy machine and user certificates on machines and utilize BOTH for authentication 

Lessons Learned - Your Logs May Not Have The Full Picture

• When capturing logs for analysis, ensure your filters are not too narrow where they may miss some IOC (Indicators of Compromise)

Lessons Learned - Universally Apply Protections To All Parts Of The System

• Apply security controls to all parts of an application ecosystem, including Administrative logins and portals

Lesson Learned - Learn From Your Mistakes

• Learn From Your Mistakes Quickly

• Update and Test Your IR Plans Frequently

Lessons Learned - Threat Detection and Response Must Be Adequately Size To Fit Your Threat Model

• Ensure you have adequate detection and response capabilities and mechanisms in place analog to your threat model and incident history

• Have your IR plan updated often based on your threat profile

• Build excellent detection systems and conduct red team exercises often to keep your blue teams on their toes

• Never be complacent

Lessons Learned - Reduce Customer Friction To Security

• Ensure all employees and contractors know where to go to report a security incident and how to do so

• Ensure anyone reporting an incidents feels SAFE (emotionally, financially, or physically) to do so

• Update your IR plan frequently

• Reduce any friction for reporting security incidents

Lesson Learned - Protect Customer Data

• Do not request sensitive information from a customer unless absolutely necessary and there is no other workaround

• Clearly inform the customer if there are any security considerations or implications of your requested actions and receive acknowledgement accordingly

• Guide the customer to reduce any risk to their data as a result

• Create technical mechanisms such, as an impersonation feature, to reduce the need for mechanisms such as the HAR file

• Train your CS teams on the implications of sensitive files and ensure processes are followed accordingly

• Ensure any file with highly sensitive information is handled and secured to the highest level:

  • Encrypted out of band file transfer (not email)

  • Extra encryption with either Customer Managed Keys or unique, temporary, and rotating keys to access files

    • Basically, these files should not be simply stored in a ticketing system or any file system with general access. Extra decryption mechanisms should be required to access these types of files. This will reduce your chances of illegitimate access.

  • Delete files within as short of a time frame as possible based on the sensitivity of information

  • Create mechanisms to extract the necessary information and discard the original information

• Tools for safe HAR file handling:

  • HARmor 

  • Introducing HAR Sanitizer: secure HAR sharing (Cloudflare)

  • Note: Kinda ironic to upload sensitive files with authentication credentials to the cloud to be sanitized 🤔

Download this is as PDF