Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why CISA Is Warning CISOs About a Breach at Sisense

krebsonsecurity.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Why CISA Is Warning CISOs About a Breach at Sisense

#41

Post by mschuster91 »

bsder wrote: post #28
koolba wrote: post #12

> Those sources said the breach appears to have started when the attackers somehow gained access to the company’s Gitlab code repository, and in that repository was a token or credential that gave the bad guys access to Sisense’s Amazon S3 buckets in the cloud. So plaintext AWS credentials checked into source control. > Both sources said the attackers used the S3 access to copy and exfiltrate several terabytes worth…

> didn’t they at least having billing alerts for the terabytes of AWS bandwidth? 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.

At least according to general "HN hivemind experience", AWS is reasonable in handing out refunds if you got hacked.

Re: Why CISA Is Warning CISOs About a Breach at Sisense

#42

Post by numbsafari »

lmeyerov wrote: post #37
captn3m0 wrote: post #31

Earlier quoted context omitted.

State Encryption was one of those long requested features[0] (I had it on my ideas list for years[1]) that Hashicorp didn't have much incentive to build. I don't think it has to with distancing opentofu as such, but the opentofu team prioritizing the right things that customers actually need. [0]: https://github.com/hashicorp/terraform/issues/9556 [1]: https://github.com/captn3m0/ideas#-mars-terraform-remote-htt...

Interesting! The 'much incentive' part is the interesting thing to me. Hashicorp did build encryption-at-rest for state into their paid remote cloud service. They explicitly recommend using the paid service instead when security is required, and instead of having both versions secure, the paid form simply disables the local one [1], drawing a strong line here between paid/secure and unpaid/insecure. So I'm wondering…

With a tool like Terraform, when is security not required?

Re: Why CISA Is Warning CISOs About a Breach at Sisense

#43

Post by TheNewsIsHere »

captn3m0 wrote: post #31
lmeyerov wrote: post #29

Earlier quoted context omitted.

Do you think a feature like this is tied to distancing OpenTofu from Hashicorp, e.g., AWS & friends have less incentive to do enterprise feature gating around security?

State Encryption was one of those long requested features[0] (I had it on my ideas list for years[1]) that Hashicorp didn't have much incentive to build. I don't think it has to with distancing opentofu as such, but the opentofu team prioritizing the right things that customers actually need. [0]: https://github.com/hashicorp/terraform/issues/9556 [1]: https://github.com/captn3m0/ideas#-mars-terraform-remote-htt...

Hard agree. When I started my company we were playing with Terraform but left it pretty early and before taking anything into production because of the issues with state management and security.

We moved on, but there are areas where I wouldn’t mind poking at it. I’ve been thinking OpenTofu is where I’d start afresh with TF.

Re: Why CISA Is Warning CISOs About a Breach at Sisense

#44

Post by TheNewsIsHere »

mschuster91 wrote: post #41
bsder wrote: post #28

Earlier quoted context omitted.

> didn’t they at least having billing alerts for the terabytes of AWS bandwidth? 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.

At least according to general "HN hivemind experience", AWS is reasonable in handing out refunds if you got hacked.

My business has not (yet?) been compromised, but I did accidentally send my S3 bill into the stratosphere in the past 12-18 months by miscalculating API charges for some intra-AWS changes I was making with lifecycle management and bucket-to-bucket moves.

I wrote to support asking for a refund and explained my calculations. I pointed out where I had made the mistake, and asked for some relief on the bill. Honesty went a long way in that case, and they gave me a credit on the bill equal to about 70% of the total S3 spend. So they ate 70% of my mistake. That was more than fair enough; it was my error.

The amounts weren’t huge. They could have eaten the entire amount and it wouldn’t have even been a rounding error on their books, but I didn’t ask and I didn’t want to expect that.

I can’t speak for others.

Re: Why CISA Is Warning CISOs About a Breach at Sisense

#45

Post by specialist »

ali_piccioni wrote: post #36
koolba wrote: post #12

> Those sources said the breach appears to have started when the attackers somehow gained access to the company’s Gitlab code repository, and in that repository was a token or credential that gave the bad guys access to Sisense’s Amazon S3 buckets in the cloud. So plaintext AWS credentials checked into source control. > Both sources said the attackers used the S3 access to copy and exfiltrate several terabytes worth…

Long lived credentials are a security red flag. We setup our AWS organization’s policies (SCPs) to prohibit long-lived tokens. Instead access goes through SSO or OIDC. It’s difficult to track usage behind access tokens, prevent leaks, and effectively revoke them.

Yup. TTL (leases) must become the norm for All The Things.

Re: Why CISA Is Warning CISOs About a Breach at Sisense

#46

Post by lmeyerov »

numbsafari wrote: post #42
lmeyerov wrote: post #37

Earlier quoted context omitted.

Interesting! The 'much incentive' part is the interesting thing to me. Hashicorp did build encryption-at-rest for state into their paid remote cloud service. They explicitly recommend using the paid service instead when security is required, and instead of having both versions secure, the paid form simply disables the local one [1], drawing a strong line here between paid/secure and unpaid/insecure. So I'm wondering…

With a tool like Terraform, when is security not required?

Encryption at rest of local terraform state seems beyond the threat model & compliance needs of a pre-PMF consumer startup

It's a lot harder to be an enterprise company or b2b startup (SOC2) and brush that off in front of knowledgeable auditors. I'm guessing most would miss it and rely on self-reporting, which in turn raises how 'loud' this issue is for most OSS terraform users.

We aren't heavy terraform users, so I'm not sure of the threat modeling here. Understanding these kinds of product decisions and OSS security ramifications is a pet interest of mine, and this is a fascinating one!

Re: Why CISA Is Warning CISOs About a Breach at Sisense

#47

Post by ethbr1 »

mulmen wrote: post #20
dudus wrote: post #4

Ouch """ Earlier today, a public relations firm working with Sisense reached out to learn if KrebsOnSecurity planned to publish any further updates on their breach (KrebsOnSecurity posted a screenshot of the CISO’s customer email to both LinkedIn and Mastodon on Wednesday evening). The PR rep said Sisense wanted to make sure they had an opportunity to comment before the story ran. But when confronted with the details…

They wanted an opportunity to comment. That implies no obligation to comment.

It does say something that they were interested enough to want the opportunity, but specifically chose not to exercise it.

Thought it was a nice addition to the piece.

Re: Why CISA Is Warning CISOs About a Breach at Sisense

#48

Post by karmajunkie »

wiredfool wrote: post #38
SoftTalker wrote: post #17

Earlier quoted context omitted.

Possibly the credentials were encrypted, but the attackers got the encryption keys as well?

It was probably an encrypted bucket, and the AWS keys had access to read/decrypt. Encryption is easy. Meaningful key management is hard.

Yeah, this caught my eye:

> “If they are hosting customer data on a third-party system like Amazon, it better damn well be encrypted,” Weaver said. “If they are telling people to rest credentials, that means it was not encrypted. So mistake number one is leaving Amazon credentials in your Git archive. Mistake number two is using S3 without using encryption on top of it. The former is bad but forgivable, but the latter given their business is unforgivable.”

I've got all our buckets encrypted-at-rest with a CMK, but if someone compromised a key, the role that key is connected to would necessarily have to have permission to decrypt the data as well. at-rest encryption just means nobody's going to buy a used hard drive and suddenly have access to gigabytes of healthcare or financial data or passwords. Or am I missing some nuance or implication of the conversation?

Re: Why CISA Is Warning CISOs About a Breach at Sisense

#49

Post by about3fitty »

koolba wrote: post #12

> Those sources said the breach appears to have started when the attackers somehow gained access to the company’s Gitlab code repository, and in that repository was a token or credential that gave the bad guys access to Sisense’s Amazon S3 buckets in the cloud. So plaintext AWS credentials checked into source control. > Both sources said the attackers used the S3 access to copy and exfiltrate several terabytes worth…

I know this says credentials were in a repo but I wonder if this has to do with their self-hosted (EE?) GitLab instance. I've found mine (CE) sort of difficult to upgrade sometimes.

Not sure how they store keys/tokens but it is sort of easy to leak to logs, and perhaps there was some exploit.

Should maybe be using cloud hosted GitLab at their level of scale, even though that option has had problems with uptime among other issues.

A past company used Sisense because the new manager came in penny wise and pound foolish. However, the other ETL/visualization products (e.g. Tableau) truly were expensive. I found Sisense's ETL / viz product to be meh.

Re: Why CISA Is Warning CISOs About a Breach at Sisense

#50

Post by mulmen »

ethbr1 wrote: post #47
mulmen wrote: post #20

Earlier quoted context omitted.

They wanted an opportunity to comment. That implies no obligation to comment.

It does say something that they were interested enough to want the opportunity, but specifically chose not to exercise it. Thought it was a nice addition to the piece.

What does it say?

I think adding the comment that they “changed their mind” was unreasonable because they didn’t change their mind. They wanted an opportunity which they got but didn’t exercise. They didn’t say “don’t contact us for comment in the future.” Which would be “changing their mind”. Their comment was simply “no comment”. This seems completely reasonable to me.

Post reply on HN