Why CISA Is Warning CISOs About a Breach at Sisense

I eventually got my way after 18 months and found out it was really bad - hard coded s3 access keys were floating around that could read any bucket and they had used terraform with vault and that had pulled all sorts of root level creds into the plain text state files.

Lots of other ways to control this risk but I removed vault from TF.

For a tortured analogy, let's say you keep your guns in a gun-safe in your garage, and then hang the key for the safe in the garage. With a sign saying "gun safe key".

Not leaving the safe key out in the open doesn't guarantee your guns are impervious, of course, a sufficiently motivated and skilled burglar willing to put time and effort into breaking open the safe would be able to access your guns.

But, that takes time. And it makes noise. Both of which increase the chance of being caught.

But if the key is right there? Easy as.

Yep, they had obtained access to the repo, like the burglar had obtained access to the garage.

But if the AWS secrets weren't just hanging on the wall, then progressing from Gitlab compromise to S3 compromise would a) be harder and b) take longer, both of which increase the chance of discovery.

Just saying, if you care about the security of your guns and/or customer data, don't leave the key hanging about in plain sight as a good first step.

Make them compromise multiple things, not just one thing.

I'm desperately trying to work encryption at rest into this analogy. Um... trigger locks?

AWS is notoriously bad about this. You can't set hard limits. Even if you set a limit, your notification won't come in until long after that limit has been hit and blown through.

I'm not going to talk in analogies. There's no more depth at the stage that the source code is compromised, regardless of how many credentials are put where. It's sort of a matter of opinion. I mean this is what I am saying by make-believe: everything you say is, quite literally, a bunch of analogies, because there isn't any actual hard evidence to any of it, it is wood carving traditions. Of course I agree that they're good practices, but man, there are unlimited good security practices, and only limited money and time.

Another point of view is, it's easy to provide generalized, vendor-colored advice about credential security. You know, just buy AWS KMS whatever the fuck, right? It is hard to write software that accommodates arbitrary changes to authorization requirements & stories. There are a lot of commenters here giving these Sisense people a hard time, and I doubt they're stupid, more so that they are really unlucky.

I feel like the comments miss the forest for the trees. Most startups have admin roles, and if you're using something like Next.js, Elixir, Ruby on Rails or Go, your application's API methods have ad-hoc, in-source policy enforcement and definitions.

This is what happened here: the developer's GitHub credentials are an Admin role. It could happen in any scheme. Can you develop an application without an admin role? Not a SaaS. Now you should see why it's okay for Postgres to have all its source code open, but not your SaaS company's, for the purposes of security.