That's what the article implies, but I think it's overblown. They provide enough information (unfortunately) to identify the employee whose credentials were stolen, and she's a Sales Engineer. The data seems to have come from her own Snowflake account, which was used to build demos for customers or prospective customers. It's quite possible that those customers granted her access to some of their actual data, which was used in those demos, but it's a far cry from unfettered access to the customer's Snowflake database itself. It's also quite possible that the hacker exfiltrated fake-but-realistic data used for demo purposes and doesn't know the difference.
> They provide enough information (unfortunately) to identify the employee whose credentials were stolen, and she's a Sales Engineer.
I'm not previously familiar with Hudson Rock, nor how "standard" disclosures around this work, but identifying the breached employee felt like an extremely shitty move to me. If a single infected laptop of a sales engineer (i.e. not even an admin with extensive access rights) resulted in a breach this large, the root cause problem is not the sales engineer - and I'd note that Hudson Rock says as much in their article.
But don't you see, we fired the problem so no more worries!
Oh, what's that. How did we change our hiring process to avoid hiring a problem again?
Sorry, my phones buzzing and I need to go.
--
Although obviously yes the problem isn't with hiring, it's with the system where a what should be fairly untrusted device shouldn't be able to exfiltrate a ton of data without setting a flag off somewhere.
The problem isn't the employee or the hiring process. It's the security infrastructure! One compromised account, supposedly from sales, shouldn't bring down the whole company.
