Last Thursday, Okta announced that unknown attackers had used stolen credentials to access their customer case management system. The attackers were able to access HAR (HTTP archive) files routinely shared with Okta by their customers for troubleshooting single sign-on issues. Though Okta advises customers to sanitize these HAR files, the files often contain credentials, cookie IDs or session tokens which can allow malicious actors to impersonate legitimate accounts.
At least one Okta customer has uncovered evidence of stolen session data being used against them. Okta claims that about 1% of customers are potentially affected by the incident and has provided Indicators of Compromise for customers to check against their logs. But even for those not immediately endangered, this incident serves to highlight the level of trust organizations routinely place in third-party providers and the dangers that can result.
We live in a world of SaaS, and few organizations can seriously contemplate a future where they don’t rely on third-party apps and services, but there are steps you can take to protect yourself against fallout from a compromised vendor. Here are three lessons to take away from last week’s news.
1 – Never share an unsanitized HAR file
The most immediate practical takeaway from this attack is that an HAR file, especially one intercepted shortly after being recorded, is a gift to potential attackers. Unfortunately, the occasions when you might be asked to share an HAR file are often time-sensitive: troubleshooting an SSO issue that is keeping you from logging into required systems and being able to do your work. In these circumstances, it’s hard to slow down—insisting on security can make an employee feel like a roadblock to their own and others’ productivity.
However, organizations need to educate their employees never to share an unsanitized HAR file, even with a trusted partner. Even tech-savvy employees should not attempt to sanitize a HAR file themselves as it is easy to miss sensitive data, or accidentally remove data that is needed for troubleshooting. Furthermore, while there are free tools that claim to help remove sensitive data from HAR files, these may not correctly identify all sensitive data, and should not be relied upon as anything more than a first step. Instead, establish a procedure for employees to tag in your security team if asked to share a HAR file.
Establishing solid protocols for sharing HAR files can protect you even if your SSO provider is compromised.
2 – Protecting your production app isn’t enough
In the wake of the incident, Okta was at pains to point out that their production service had not been impacted by the attack. However, SaaS and other digital service providers need to remember that your production app is not the only repository of sensitive customer data in your organization. Customer support and case management systems in particular—including Zendesk, Salesforce, Jira, and others—can be treasure troves of data, perhaps neglected by security teams. Attackers know the value of these systems, as evidenced by the number of recent breaches that leverage customer support platforms.
Your security and governance strategy needs to encompass not just your production services, but every system that touches customer data, including SaaS and customer support apps. Do agents have access only to information on customers they directly work with? Or is broad access given to all agents? Okta says that only 1% of customers were affected by the compromised case management credentials. In the aftermath of a breach, knowing exactly what data and accounts are potentially at risk is vital to responding swiftly and containing the damage. In an ideal world, credentials would never be compromised. But if they are, 1% of accounts affected is a lot better than 100%.
3 – Identity is the weakest link in security
Perhaps the most important takeaway from last week’s news is a reminder that an “assume breach” mentality remains essential for any organization managing sensitive data. While CISOs can and should invest in employee training, multi-factor authentication and other forms of identity protection, identities can never be completely safeguarded. Even if you do everything right, a compromised third-party may still allow attackers a way in.
That doesn’t mean the situation is hopeless. The “assume breach” mindset takes a practical and proactive approach to identity security: begin with the assumption that any human or machine identity will be compromised. When it is, the damage caused is determined by what permissions that identity holds to apps, infrastructure, and data.
With most cloud infrastructure accounts using less than 3% of the permissions they’re granted, a renewed focus on implementing least privilege is the single most impactful step you can take to protect your organization from catastrophic breaches.
How Veza can help
Veza’s next-gen IGA solution is designed specifically to help you answer the vital question of “who can, and should, take what action on what apps and data?” Veza helps you prevent risky access permissions and achieve least privilege by:
- Providing visibility into the granular permissions of users, translated into simple and understandable language: create, read, update, delete.
- Continuously monitoring for excess privilege and automating remediation through integration with ITSM and notification tools.
- Enabling intelligent access reviews, based on the real, effective permissions of human and non-human identities, that lead to actionable outcomes, automated to reduce the burden on IAM teams and the managers who approve access.
To learn more about how Veza can help you pursue Least Privilege, schedule a demo today.
