What we learned from the Sisense breach

cisa-cyber-grant CISA Sisense Breach

Another week, another security breach story. This one doesn’t have the happy ending of last week’s story about XZ Utils. At the time of this writing, it is yet unclear how the story is even going to end.

The details of the breach: Sisense is a business intelligence product company, serving many clients across industries including financial services, telecommunications, healthcare and higher education. Based on the little information provided the general public, the attacker somehow got into Sisense’s Gitlab repository. This repo was not hosted by Gitlab, but directly by Sisense. This means there are a few ways the attacker might have gained access, but it’s likely to be through a Sisense insider.

The developers at Sisense managed to leave a credential in their code repository for gaining access to Sisense’s S3 buckets on AWS. The attacker used this credential to gain access to Sisense’s S3 buckets and exfiltrate over a terabyte of data, which apparently included millions of access tokens, email account passwords, and even SSL certificates.

The breach became significant enough for the U.S Cybersecurity and Infrastructure Security Agency (CISA) to get involved, presumably because some of the affected clients are part of critical infrastructure. Regardless, the fact CISA got involved is testament to the significance of this breach.

Both CISA and Sisense advised customers to reset and rotate credentials. We would imagine in the last week Sisense has figured out which specific S3 buckets were affected, and which customers’ data is actually at risk. The company is likely working with their customers to contain downstream damage to the customers of these companies.

Supply chain attacks, such as this one, have become more prominent in recent years. The SolarWinds attack three years ago was probably the first famous such attack. Last week’s XZ Utils finding would also have been a supply chain attack.

The Sisense breach holds many lessons for us. Any software company with customers that might be cyberattack targets can become a lucrative target for cyber criminals. Supplier managers need to partner with their CISOs to ensure they provide security policies to their suppliers, and have the capability to audit these policies.

There’s a lesson here for developers as well. It’s not uncommon to store credentials to databases or servers in files in the dev repo. The problem is that even if one goes now to delete this information, code repositories have a long memory. Everything is versioned, and never “truly” deleted. There is an element of policy and education here as well for developers to maintain the proper level of hygiene in their digital workspaces.

The battle for security continues, and with every setback we all learn something that has the potential to make us better and more secure.