Sisense April 2024: Why CISA Issued an Emergency Directive

Threat Intelligence

The Sisense breach in April 2024 prompted one of CISA's rare emergency directives to private sector customers. A practitioner look at what was exfiltrated, what customers had to rotate, and why this one was treated as a strategic threat.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 9, 2024 · 7 min read

On April 11, 2024, CISA issued an unusually pointed alert about Sisense, a business intelligence vendor whose customer base includes financial services, healthcare, and critical infrastructure operators. The text was direct: rotate every credential, secret, and certificate that had ever been provided to or used to access Sisense. The directive language is what made this newsworthy. CISA rarely names a private vendor by name and tells customers to assume total compromise of integrated systems.

Timeline of disclosure

1. Late March 2024: Sisense discovers unauthorized access to its development environment via a self-hosted GitLab repository.
2. April 10, 2024: Sisense notifies impacted customers privately. The breach involves theft of access tokens, API keys, JWT secrets, and customer-provided credentials stored in the development environment.
3. April 11, 2024: CISA issues Alert AA24-102A urging all Sisense customers to rotate credentials.
4. April 12 to 18, 2024: Investigative reporting from Brian Krebs identifies the entry point as credentials stored in a GitLab repository, leading to S3 buckets containing 'several terabytes' of customer data.

Root cause: credentials in source control, escalated to cloud storage

The forensic narrative reported publicly (Sisense did not publish a detailed post-mortem) is consistent with a familiar pattern. An attacker obtained access to a self-managed GitLab instance, found a token to AWS S3 in repository contents or CI/CD variables, and used it to access customer data buckets. Those buckets contained customer-uploaded data connectors, including credentials that Sisense customers had given Sisense to connect to their own systems: Salesforce tokens, Snowflake credentials, database passwords, SSO certificates.

What customers had to rotate

• Any password, API key, or token a customer had ever pasted into a Sisense connector configuration.
• SSO SAML signing certificates if Sisense was a service provider in the customer's IdP.
• Any JWT signing secret shared with Sisense for embedded analytics.
• Cloud IAM access keys used by Sisense connectors (AWS, GCP, Azure).
• Database service accounts whose credentials were stored in Sisense data source definitions.

Detection signals customers should have run

If you were a Sisense customer in April 2024, the right hunt was not for Sisense IOCs (the operators worked from cloud storage, not from your network). It was for unexpected use of the rotated credentials before rotation completed. Look for read operations against your data sources from IPs and user agents that were not Sisense's published egress ranges. Look for unfamiliar Snowflake or BigQuery sessions authenticating with the connector service account. Look for SAML responses signed with the old certificate after the rotation timestamp.

Lessons on integrated SaaS posture

The Sisense pattern, which we are now seeing repeat across analytics, RPA, and iPaaS vendors, is that the vendor itself is rarely the high-value target. The credentials the customer gave the vendor are. Three operational practices changed in our client base after this incident. First, no more long-lived service-account credentials in SaaS connectors; rotate to short-lived federated identities (AWS STS AssumeRole with external ID, GCP Workload Identity Federation, Azure managed identity) wherever the vendor supports it. Second, vendor-specific egress IP allow-lists at the data source so that connector credentials cannot be replayed from anywhere else. Third, treat any data-integration vendor's breach as functionally equivalent to a breach of your most permissive data store.

If a CISA alert about your vendor says 'rotate everything you ever told them,' you have a relationship problem, not just a vendor incident.

The under-reported angle is that customer-facing connector credentials are still routinely stored in plaintext-equivalent ways across BI and iPaaS vendors. The Sisense incident gave us a strong negotiating lever in 2024 vendor reviews: ask to see how the customer credential is stored, who can read it in the vendor environment, and how rotation works on the vendor side. The answer often determines whether the vendor stays.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.