The recent breach at Sisense started with an AWS access token to a Gitlab repository and has led to all Sisense customers having to rotate any access token they’ve ever given to Sisense. While most headline-grabbing breaches involve personal information, the ramifications of stolen business information and trade secrets can be just as devastating to your company.
Sisense is a business intelligence tool that aggregates data from the third-party services you use into consolidated dashboards. Since businesses often use a wide variety of SaaS applications and API-driven software, the value of aggregating the data from all of these tools into a single dashboard is enticing. By automating this data collection, humans can spend more time doing data analysis and less time doing data collection.
In practice, the API connections between Sisense and the third-party services use an API key. Sisense has many built-in data connectors to various SQL and NoSQL data sources. Making an API call to Sisense can be done with a variety of API key form factors:
-
JSON Web Token (JWT), which does not require an enterprise identity provider
-
SAML 2.0, which does require an enterprise identity provider
-
OpenID Connect (OIDC), which is based on OAuth 2.0
-
Web Access Token, which is a read-only access token
Once an API credential is set up and you see the data flowing to the aggregation tool, it’s easy to think your job is done and forget about this service-to-service connection, especially if the API credential is a “forever” token. As we know from the human side of authentication, long-lived passwords without any lifecycle management or policy enforcement is an inevitable security threat. The same rigor around human authentication needs to make it into machine authentication.
The core of this Sisense breach is leaked API secrets. This showed up in a multitude of ways throughout the breach:
-
The Gitlab repository was able to be accessed by the attacker
-
The S3 credentials that were stored in Gitlab were simple API keys
-
Customer credentials given to Sisense were located in the accessed S3 buckets
Modern human identity and access management principles heavily rely on things like credential rotation, secrets management, least-privileged access, and multiple factors of authentication. These principles should be applied to machine credentials as well, but have been either slowly applied or are non-existent in most IT organizations. By giving these access tokens to a third-party aggregation tool like Sisense, the need for stronger controls and lifecycle management on these access tokens becomes magnified. In fact breaches like this and Github’s recent leak of auth secrets calls for a stronger approach to API identity and authentication.
CISA notes that credential rotation as a remediation is not enough and a reactive way to address a credential breach. Unfortunately, that is the only remediation step that can be offered by Sisense. As Brian Krebs explains:
“The breach also makes clear that Sisense is somewhat limited in the clean-up actions that it can take on behalf of customers, because access tokens are essentially text files on your computer that allow you to stay logged in for extended periods of time — sometimes indefinitely. And depending on which service we’re talking about, it may be possible for attackers to re-use those access tokens to authenticate as the victim without ever having to present valid credentials.”
Based on this breach, IT organizations must treat these access tokens the same way they treat user passwords. Frequent rotation should be utilized at a bare minimum to prevent long-term access. Limits to data access for these tokens should be implemented and reviewed. Ideally a stronger story approach to API identity and authentication and securing machine-to-machine communication with more than secrets is long overdue.
About Chris Parlette
Chris is a Senior Solutions Architect at Corsha. He has a diverse background encompassing activities such as working with both on-premises and Software as a Service (SaaS) solutions, utilizing cloud and monitoring tools, offering consulting and professional services, conducting demonstrations and Proof of Concepts (POCs), managing Requests for Proposals (RFPs), contributing to marketing endeavors like blogging, participating in trade shows and conferences, engaging on social media platforms, navigating sales processes, providing customer support, handling custom integrations, and much more.
About Corsha
Corsha is an Identity Provider for Machines that allows an enterprise to securely connect, move data, and automate with confidence from anywhere to anywhere. Corsha builds dynamic identities for trusted machines and brings innovation like automated, one-time-use MFA credentials to APIs. This ensures automated communication across clouds, data centers, or shop floors is pinned to only trusted machines and helps an organization move past outdated, costly secrets management and reimagine identity and access for machines.
