Four ways security teams can learn from the Okta breach

The recent Okta incident has created a bunch of fear, uncertainty, and doubt. The reactions from the media, vendors and industry professionals alike have expressed the disappointment in how this situation was handled. In all the ruckus, we seem to have lost sight of some important lessons from this incident that the industry could benefit from.

The real lesson: the Okta breach is not specific to identity or security providers – it could have happened to any company that offers a SaaS product.

In Okta’s case, the breach was tied to an internal application, named SuperUser, which allows its support engineering team to administer tenants on behalf of the customer. A support engineer’s device was compromised, and the hacker gained access to SuperUser – Okta estimates the hacker could have accessed the Okta tenant of 366 customers via the SuperUser interface. Every single SaaS provider has one or more SuperUser-like administration interfaces for its internal staff to provide support across multiple customer accounts. These administration interfaces are restricted to a specific set of users because unauthorized access could seriously compromise multiple customer environments.

Once a SaaS provider reaches a certain size, it starts leveraging third parties – partners, vendors, business process outsourcers – to serve its customer base. These third parties need access across customer environments to perform their jobs so more administration interfaces are operationalized. This further increases the associated risk.

The Okta incident has prompted a deeper discussion among SaaS providers on how they should deliver least-privilege access to their administration interfaces, especially those used by third parties. Here are four security principles all SaaS providers should employ to secure their administration interfaces:

Many administration interfaces are secured with shared usernames and passwords that are included in administrative scripts, which are difficult to change. The LAPSUS$ group specifically recruited employees and contractors who had access to these types of privileged static credentials.

Instead, administration interfaces should use authentication tied to single-sign-on (SSO) via the corporate identity provider, and combined with multi-factor authentication (MFA). Okta has implemented SSO and MFA for its SuperUser application, and that’s what allowed it to contain this security incident.

Security teams can also rotate credentials via a password manager, if they decide it’s not a priority to configure a dedicated SSO for internal-only administration interfaces.

As we saw in the Okta incident, it’s all too easy to compromise a device. Most device compromises occur over the network, so all devices used for admin access should have their firewalls enabled. Further, ensure remote access servers (such as RDP and SSH) are turned off on these devices. To enforce this, ensure a user can’t even sign on to a service from an unregistered device where the security team can’t validate device posture.

Security teams enable device trust by whitelisting access to certain IP addresses they can only obtain via a VPN client that checks device posture. Many organizations use this technique, but it fails if multiple users use the same network and share an IP address. In the case of a breach, it’s not possible to map the IP addresses in logs to specific devices, so the team has to assume every single device in that shared network has been compromised.

Employ a device certificate stored in a secure enclave on the device. This technique allows the team to uniquely identify a compromised device regardless of the network it’s on.

Admin interfaces often need to interact with multiple systems in a SaaS provider environment. Support teams often automate these interactions: for provisioning (AWS), ticketing (Jira), and chat (Slack).

These application-to-application interactions authenticate via API keys and are typically exempted from the policies and audits that are applied to human-initiated interactions. API keys are a threat vector that attackers always look to exploit. Okta never mentioned it in its report, but the LAPSUS$ hackers claimed on Telegram that they explicitly searched for, and could find, AWS access keys in Okta’s Slack channels.

API keys used to build administration interfaces are particularly sensitive. Don’t exempt programmatic access from policies and audit – make sure these are also authenticated and authorized consistently.

The two-man rule stands as a time-tested protocol for sensitive operations and security teams should not reserve it only for nuclear submarines. Tying privileged admin access to an approval workflow can significantly reduce the risk of breach.

Traditionally, approval workflows have been associated with tedious bureaucracies and waterfall-style development. However, modern solutions use just-in-time provisioning with API integrations that support Slack webhooks and Jira tickets, making approval workflows easy to operationalize and not-too-onerous to use. Any time a user elevates to super admin privilege should trigger an approval flow.

What happened at Okta could have happened at any SaaS vendor. The industry should learn from this incident and better secure its administration interfaces using these four principles.

Tarun Desikan, co-founder and COO, Banyan Security