[i_k_k]

There’s something missing here.

From what the Hudson Rock article shows, they were able to use an SE’s creds to access their demo account. This is not a customer account and shouldn’t (but of course could) contain sensitive info. It’s not clear to me how this snowballed into a larger breach.

Perhaps customers had granted this SE access to their accounts and the data within. Or perhaps there’s a deeper hack. But this isn’t clear to me from what I’ve read.

[gregates]

I was just going to post the same thing. The files that they show in the screenshots are things like PROGRESSIVE_BID_CHANGE_202405271129.csv. Looks suspiciously like the Snowflake Sales Engineer's data for their job role closing a deal with Progressive, not Progressive's own data. And there's no reason to think that a SE would have broad access to customer data. There may be some overlap, but I doubt it contains sensitive customer data owned by Progressive.

[capecodes]

You’re thinking “bid” is in reference to Snowflake bidding for progressive as a client?

I’d say thats not likely, I work in fintech and the first thing this filename indicates to me is a CSV feed of market data for bid prices (https://en.m.wikipedia.org/wiki/Bid_price)

This is a common type of dataset a firm would dump into a datalake to use as reference data lookups against other more sensitive data (for pricing trades, etc.)

[coredog64]

Something similar happened at a previous employer. Contractor was hired to do a big data PoC, and they managed to cajole access to a prod data dump for a more impactful demo.

They then managed to load all this PII data into an ElasticSearch instance that was open to the internet and was discovered by threat actors.

I wouldn’t be surprised to find that something similar happened here, where an unscrubbed prod dataset was shared for a better demo.

[p0seidon]

There may have been administrative access that was not properly secured.