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

31–40 of 62 posts

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

#31

Post by captn3m0 »

lmeyerov wrote: post #29
captn3m0 wrote: post #27

Earlier quoted context omitted.

opentofu is solving this with proper state encryption support: https://github.com/opentofu/opentofu/issues/874

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...

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

#32

Post by binkHN »

> ...a company entrusted with so many sensitive logins should absolutely be encrypting that information.

> “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 reset 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.”

The penalties for gross negligence are not high enough. These guys should be sued into oblivion; I hope their insurance limits are high enough.

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

#33

Post by [deleted] »

binkHN wrote: post #32

> ...a company entrusted with so many sensitive logins should absolutely be encrypting that information. > “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 reset 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 withou…

[deleted]

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

#34

Post by hnzix »

leetrout wrote: post #24
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…

My previous team argued with me when i said to avoid using terraform with vault with our state in S3. 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 re…

Was that a fundamental problem with TerraForm or just an implementation issue?

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

#35

Post by iforgotpassword »

hnzix wrote: post #34
leetrout wrote: post #24

Earlier quoted context omitted.

My previous team argued with me when i said to avoid using terraform with vault with our state in S3. 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 re…

Was that a fundamental problem with TerraForm or just an implementation issue?

The thing is that most HN folks, competent IT people see tools like Terraform, ansible, docker et al as neat tools that simplify and speed up annoying chores, so you get to spend your time on solving actual problems. What it means to managers is that task X has become so easy that you can hire complete idiots who would've failed without the tool but now manage to cobble something together quickly that appears to work well. Except you now have passwords and keys in repos, open s3 buckets, ...

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

#36

Post by ali_piccioni »

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.

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

#37

Post by lmeyerov »

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...

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 if that created a disincentive, from a perspective of enterprises upselling for security & compliance. OpenTofu community members aren't relying on selling a remote management service, and when a cloud provider, more usage in general is better, and that includes security for everyone. I can be off, so not quite clear to me the more I look.

[1] https://developer.hashicorp.com/terraform/language/state/sen...

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

#38

Post by wiredfool »

SoftTalker wrote: post #17
darkerside wrote: post #16

> If they are telling people to reset credentials, that means it was not encrypted. I'm not sure that follows. If I leaked customer information, even encrypted, I believe it would still be responsible to tell people and give them the option to react. Encryption is not foolproof technology. Vulnerable to cracking, or perhaps the key could simply be leaked as well.

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.

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

#39

Post by wiredfool »

binkHN wrote: post #32

> ...a company entrusted with so many sensitive logins should absolutely be encrypting that information. > “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 reset 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 withou…

It probably was, but Amazon's bucket checkbox encryption doesn't protect against an authorized user reading the data.

It's trivially easy to encrypt things on AWS, but the attack you're protecting against is someone walking off with the HD, which is not really the important threat. Well, that and making sure that the auditor can check off 'encrypted at rest' on the sheet.

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

#40

Post by EdwardDiego »

doctorpangloss wrote: post #30
EdwardDiego wrote: post #26

Earlier quoted context omitted.

Yeah it does, because you left the key for the place where you stored everyone else's keys out in the relative open. It reduces your defensive depth to 1, as in, 1 compromise was all it took. 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 y…

> Yep, they had obtained access to the repo, like the burglar had obtained access to the garage. 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…

I'm really unsure why you're so convinced that "don't leave AWS creds in source code" is just security theatre.
Post reply on HN