Okta has denied that the hacker group LAPSUS$ breached their service and performed malicious exploits, while LAPSUS$ claims it has gathered significant Okta customer data over the past several months—enough for additional exploits. No matter which claim is found to be accurate, it should still be sounding alarms that looming supply chain attacks are always brewing that could hit an organization’s interlinked business-critical SaaS applications across customers and the high-value data stored in these services. Such attacks rely heavily on risky, over-privileged integrations between services to maneuver across accounts and services, wrecking havoc along the way.
Whether this specific incident leads to supply-chain attacks remains to be seen, but as we increasingly trust third-party vendors to perform business critical functions, including ones like Okta that many organizations highly trust, so does the potential risk of attackers like LAPSUS$ targeting them as the “weakest link” to gain access to a broader mesh of integrated SaaS services increase. This goes double for unvetted and unsanctioned SaaS apps adopted by business units due to the democratization of IT, typically onboarded without security team review or oversight. These third-party apps may have significant vulnerabilities and misconfigurations, or be integrated with business-critical apps (like Microsoft 365, Salesforce, and Google Workspace) through over-privileged integrations that can provide the keys to the kingdom.
It has almost become axiomatic that, in the cloud, “Identity is the new perimeter” to be defended with robust Zero Trust controls. But SaaS security solutions to date have mostly focused on human identities, not non-human identities like direct APIs, SaaS marketplaces, and no/low code platforms (such as Zapier, Workato, Mulesoft, and others), that make the integrated mesh of business applications possible. This oversight significantly expands the potential blast radius of any exploit through the lateral movement of threats once the “weakest link” has been breached.
To address this oversight, IT security teams need to ensure robust Zero Trust security controls on the access they, or other business units, provide third-party vendors into corporate environments. What does this mean?
- Maintain Compliance Visibility & Auditing for Third-Party Apps and Integrations
Regularly audit your SaaS services to uncover shadow integrations, high-risk apps, and over-privileged integrations. This provides compliance visibility and auditing trails both if a breach occurs, and to maintain constant visibility even if one doesn’t. It also helps baseline your risk level as you move to reduce your third-party integration risks and monitor for changes over time, such as the unsanctioned adoption of new services and integrations or instances of privilege drift, which continually occur.
- Offboard Unnecessary & Risky Integrations
As a necessary second step, you should quickly offboard any unnecessary third-party vendors and integrations. This includes ones that have been abandoned after initial evaluation but never turned off, the departure of the app owner/admin, or just plain falling into disuse, as well as those apps and integrations that have been vetted and found to be high risk. This will reduce your potential non-human attack surface by reducing the number of unnecessary or high risk integrations into your sanctioned business-critical SaaS apps that can be exploited in the event of a supply chain attack.
- Maintain a State of Least Privilege Access for All Third-Party Integrations
The third step is to apply least privilege policies to ensure integrations have only the level of permissions necessary to function nominally. The truth is most business users tend to over-privilege their integrations, increasing the opportunity for bad actors to perform damaging cross-service exploits. This includes both continuous monitoring for application and privilege changes, but also auto mitigating the risks.
One often overlooked point is that such a security regime is most effective when you democratize SaaS integration risk mitigation, since they are the ones adopting these services in the first place. Alerting the application owners when a risky app or over-privileged integration is discovered, and guiding them to mitigate them themselves, will not only help build awareness around the need to prevent risky adoption of integrations going forward, but also avoid disruptions in business continuity that can be caused by over-vigilant security personnel cutting off an integration without the collaboration of the service owner.
.jpg)
