Summary: Combined Lessons From The Okta, 1Password, Cloudflare hack
Below is a condensed summary of all the action items from the Deep Dive article.
Ayman Elsawah
November 19, 2023
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:
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
Subscribe to keep reading
This content is free, but you must be subscribed to Last Week As A vCISO to continue reading.