Sisense breach: the urgency of protecting developer secrets

As a result of the breach, it is critical that Sisense customers take action immediately to minimize the impact of any breached credentials. Here is a quick overview of what happened, and a look at what needs to be done to secure your developer secrets to protect against follow-on data breaches.

What caused the Sisense breach?

According to reporting by Brian Krebs, attackers gained access to Sisense’s self-hosted GitLab environment. From there, they found an unprotected token that gave them full access to the company’s Amazon S3 Buckets. Once they had full access to the company’s cloud environment, they were able to copy and exfiltrate several terabytes of customer data, including millions of access tokens, passwords, and even SSL certificates.

Who’s impacted?

Exact details have not been published, however, it appears that over 1,000 companies (and possibly over 2,000) may have been impacted, ranging from startups to global brands. The company serves businesses in the finance, healthcare, retail, media & entertainment, software and technology, and transportation industries.

While the initial breach is severe on its own, it’s the potential for downstream attacks on companies and consumers that likely has CISA concerned. The stolen credentials could give the attackers access to additional cloud environments containing consumer information as they move downstream from their initial target to Sisense’s customers. Many of these credentials – SSL certificates, SSH keys, and API tokens – exist for an extended period of time by default. As a result, it is imperative that Sisense customers take action to secure their developer credentials.

Sisense breach: actions to take

Sisense has shared guidance with their customers about the types of credentials to rotate, including but not limited to account passwords, single sign-on (SSO) client secrets, database credentials, Git credentials, API tokens, and SSL certificates. Impacted customers should:

1. Review guidance and communications from Sisense for the full list of impacted credentials.
2. Audit and identify the most privileged credentials that protect customer data, especially personally identifiable information (PII) and personal health information (PHI).
3. Begin rotating credentials, working backwards from the most privileged to the least privileged.

Lessons learned – and what to do going forward

Even if you were not directly impacted by the Sisense breach, it’s important to review your security posture, especially when it comes to developer secrets and devops environments. As we’ve written about in the past, businesses of all sizes struggle to protect developer secrets. Even sophisticated security and engineering organizations can fall victim to secrets leaks.

Here are some steps you can take to secure developer credentials:

Secure developer credentials like API tokens and SSH keys

Despite the privileged access developer secrets provide, they often do not have the same degree of protection as passwords, especially since IT and security teams can lack visibility into the health of these credentials. These types of developer secrets should be secured with end-to-end encrypted storage, like an enterprise password manager (EPM).

Use secrets references, even in dotenv files

It’s too easy to accidentally commit a secret, even if it’s added to an environment configuration file. The best defense is to use secrets references that can be replaced programmatically at run time.

Inspect Git commits for secrets

Although it is more effective to address the root causes of developer secrets leakage, businesses and organizations should inspect Git commits as a last safety check to make sure credentials are not accidentally committed to shared repositories. GitHub recently announced that they have turned on push protection for all public repositories, but this feature needs to be applied to all repositories, public or private, cloud or self-hosted.

Strengthen cloud infrastructure by blocking public access by default

Amazon S3 Block Public Access can help you make sure that your Amazon S3 buckets don’t allow public access. As of April 2023, block public access is turned on by default for all new Amazon S3 buckets. For any created prior to April 2023, the setting should be configured for your AWS accounts or within individual Amazon S3 buckets. Another preventative security measure for Amazon S3 buckets is to use IAM Access Analyzer to regularly monitor which buckets (and other resources) are accessible outside your account or AWS environment.

How 1Password can help

While organizations must react to this breach, the most effective solution to this type of breach is to implement the practices outlined in this post to secure developer secrets. To that end, 1Password provides an enterprise password manager (EPM) that secures developer secrets while simplifying the complexity of developer workflows.

1Password’s offerings provide critical secrets management functionality to prevent breaches caused by developer credentials, and are available in all 1Password plans:

Protect and manage developer secrets

Store SSH keys, API tokens, database credentials, and more in 1Password’s end-to-end encrypted vaults. Use 1Password to generate, store, and biometrically authenticate SSH connections so SSH private keys are never saved as plaintext on your local disk.

Keep secrets out of code

Use the 1Password VSCode Extension to find secrets in your code as your work, one-click save them to 1Password, and then replace them with a secrets reference.

Securely deploy to production

Integrate 1Password with your CI/CD pipelines (GitHub Actions, CircleCI, and Jenkins) and infrastructure as code (IaC) tools (Kubernetes, Terraform, Pulumi, Ansible) to programmatically replace secrets at runtime.

While it’s not possible to prevent 100% of breaches, it is possible to empower software engineering teams and other employees with the tools they need to keep secrets safe.

You can get started with a 14-day free business trial, or by visiting our developer docs to learn more about how you can secure developer secrets.

1Password