A recent security incident involving the compromise of Salesloft Drift, a popular marketing automation tool, has affected a large number of organizations.
During this event, threat actors stole and replayed the OAuth tokens that connect the Drift tool to Salesforce, Google Workspace and many other applications, leading to widespread exfiltration of data.
This incident has impacted many of our technology peers. These events naturally raise questions for our customers and partners: "Was Okta impacted?" and "What is Okta doing to protect our data?"
We want to be crystal clear: Okta was not impacted by this incident.
Our security team thoroughly investigated our systems and confirmed that while we observed evidence of attempts to access our resources using stolen tokens, our defenses worked as designed to prevent a breach.
Defense in practice: The impact of a single control
When our team learned of the Salesloft Drift compromise, we immediately reviewed our logs. We discovered attempts to use a compromised Salesloft Drift token to access an Okta Salesforce instance. These attempts failed. When we later compared these attempts to the Indicators of Compromise (IOCs) from the Google Mandiant blog post, the data confirmed that we were indeed a target.
The single most important control that prevented this breach was our enforcement of inbound IP restrictions. The threat actor attempted to use a compromised token to access our Salesforce instance, but the attack failed because the connection originated from an unauthorized IP address. This security layer proved essential, blocking the unauthorized attempt at the front door before any access could be gained.
Our security strategy is to apply this fundamental control to all of our SaaS applications. However, our ability to implement this is often limited, as it's entirely dependent on whether the SaaS vendor provides this capability. Unfortunately, many providers in the cloud-first world do not offer this foundational security feature, creating a significant challenge for protecting interconnected systems.
For an application as critical as Salesforce, which does support this feature, we undertook the significant effort required to configure these restrictions for both APIs and users. This deliberate investment, made as part of the Okta Secure Identity Commitment, included the work to ensure all Okta employees use a cloud-based VPN with private IP exit nodes to create a trusted corporate network. This foundational step ensures that for our most vital applications that support this feature, we can enforce the network-level security necessary to defend against this type of attack.
Beyond IP restrictions: Securing tokens with DPoP
Another pillar of the Okta Secure Identity Commitment was to create market-leading, secure identity products and services. As a result of that commitment, both Auth0 and Okta built support for DPoP (Demonstrating Proof of Possession) for application developers using our services.
Where IP allowlisting constrains the use of a token by IP, DPoP can constrain the use of a token to a specific client. This security mechanism cryptographically binds an access token to the specific client that requested it. In simple terms, it's like a key that is uniquely paired with its lock. Even if an attacker stole the key (the token), they couldn't use it because it wouldn't work on their own machine (the wrong lock). This control prevents the replay of stolen tokens, which was the central issue in this supply chain attack.
Building a resilient SaaS ecosystem with IPSIE
This incident is a stark reminder that a breach of one service can have a ripple effect across today's interconnected SaaS ecosystem. To defend against this, we must move beyond securing applications individually and ensure they are all part of a unified identity security fabric. Such a fabric, built on open standards, is what allows organizations to detect and respond to identity-based threats with the required speed and scale.
This is why, almost a year ago, Okta announced our commitment to driving a new industry standard called the Interoperability Profile for Secure Identity in the Enterprise (IPSIE) in partnership with other members of the OpenID Foundation. IPSIE aims to create a baseline for security and interoperability across SaaS applications.
Two of the fundamental controls that are part of the IPSIE framework are particularly relevant to the Salesloft Drift incident:
Shared signals: This allows for real-time communication of security events between applications. For example, if a user's account is compromised in one application, that information can be instantly shared with all other connected applications, which can then take action to protect the user's data.
Token revocation: This provides a standardized way to revoke access tokens. In the case of the Salesloft Drift incident, if a token was known to be compromised, it could be instantly revoked across all integrated applications, severing the attacker's access.
These are just a few examples of the many ways that IPSIE helps to create a more secure and resilient SaaS ecosystem.
A call to action for the SaaS industry
The Salesloft Drift incident is a wake-up call for the entire SaaS industry. We can no longer afford to operate in silos. We must work together to establish and adopt a common set of security standards.
The future of SaaS security is already here, it's just not evenly distributed.
We urge all SaaS companies to join us in supporting the IPSIE initiative. By working together, we can make the entire SaaS ecosystem safer for everyone.
What you can do to protect your organization
This isn't just a problem for vendors to solve; all organizations have a critical role to play in raising the bar for the entire ecosystem. Here’s how you can act now:
Demand IPSIE from your vendors. The security of the interconnected SaaS landscape is a shared responsibility. As a customer, your voice is the most powerful driver of change. Ask your vendors about their roadmap for adopting open standards like IPSIE. When providers know that security and interoperability are key purchasing criteria, they will prioritize them. Your demand is what will turn these standards from a good idea into an industry-wide reality.
Implement an identity security fabric. While we push for better industry-wide standards, it is imperative that you act to secure your own digital environment. The days of treating identity on an app-by-app basis are over. By implementing a unified identity security fabric, you can weave together access control, threat detection and response, and governance across all your applications and identity types. This provides a single, consistent layer of defense, allowing you to proactively secure your organization from the inside out.
To learn more about IPSIE, please visit the OpenID Foundation website.
