If it was a zero-day then they legitimately may not be at fault.
In either case, it's a very small amount of evidence anyway, but in that respect at least, hoping it wasn't a zero-day makes sense.
Working in the security industry quickly cures you of this illusion. It is unavoidably vulnerable in most cases. If someone wants to pop your network, they can usually find a way. The most clever code won't prevent someone from strolling in and plugging a raspi onto your network. Nobody notices an inconspicuous black box amid a pile of cables.
If they stayed old-school and had their computers inaccessible except to their own people, you'd have to make phone calls, fax, and mail to do anything with them. That would be less efficient - more costly - but it would prevent the possibility of a remote attack compromising huge amounts of data.
If we move up in abstraction, if these companies didn't exist and collect all the data the danger would be completely eliminated. OTOH the banks and lenders who use their services would have to find other ways to estimate credit-worthiness and that would again... cost more.
Most devs have creds littered throughout their system. Some subset of the creds will get me access to your network. If you let me rifle through your box for a few hours I'd likely find a way to pivot somewhere else.
If you're dressed as one of them, you can go wherever you want and people rarely ask questions. Another approach is to pose as an interviewee. That's how you get into the building, but beyond that you never actually talk to anyone so nobody is suspicious. People generally don't care when someone is walking around the halls dressed up in a suit.
One of my coworkers was involved in dozens of red teams and he got caught a grand total of one time. Every other time he was able to acquire an IP address, take a picture of himself sitting in the exec's chair, swipe a file out of the server room, or whatever the customer wanted.
Particularly if they behave accordingly.
A classic (just to show that there is nothing new under the sun):
https://en.wikisource.org/wiki/The_Innocence_of_Father_Brown...
>If you meet a member of that select club, "The Twelve True Fishermen," entering the Vernon Hotel for the annual club dinner, you will observe, as he takes off his overcoat, that his evening coat is green and not black. If (supposing that you have the star-defying audacity to address such a being) you ask him why, he will probably answer that he does it to avoid being mistaken for a waiter. You will then retire crushed. But you will leave behind you a mystery as yet unsolved and a tale worth telling. ...
These gigs are highly paid and secretive. The coworker I mentioned went on dozens of assignments like this. Admittedly he was legendary, but only because he was so experienced. If you were motivated and malicious, you could do many of the same things to attack a target network. People rarely do that, but it's the ultimate proof that none of us are secure against motivated adversaries.
Side note, that sounds like something one of my old bosses would do on his red team excursions (he also told me to get my teeth pulled without anesthetics at all, so... yea).
Regardless of this specific situation, we already live in this world. We all just need to get used to it.
Like, some random website: "we just got hacked, all you pii was taken, but don't worry nothing thats not already available in that public database"
other than new credit card #'s it'd be basically pointless right?
Everybody on that list will change their CC and life carries on until the next breach.
Was this database typically accessed with broad-sweeping queries that could snarf large amounts of it at once, or was it the sort of thing where a few specific keys were used to identify a single client record? My thinking is that it was probably the latter, and if that's the case then another layer of security should have been in place there. Stored procedures can be used to require very specific queries to access very specific records--this falls under the "prevention" category. Next, monitors should be deployed so that someone gets notified right away if some session makes a large number of successive queries to get around the restriction--this goes under the heading of "detection". These two things would have been able to prevent attackers getting the goods with just one exploit.
...yet companies regularly fail to take these kinds of simple and rational steps seriously, and then act like it was all just too hard for anyone to possibly defend against.
They should be liable for poor storage practices around sensitive PII. Take for example SSN. With SHA2, there is no good reason for them to be stored in plaintext.
If you don't need it, don't store it. For SSN, you just need a function (SHA256+Salt) that would give you a one way mechanism of Creating an identifier that masks the original in an irreversible way.
The prevalence and misuse of SSN as an identifier for people is so out of date at this point and weak. We need something different.
> The prevalence and misuse of SSN as an identifier for people is so out of date at this point and weak. We need something different.
I completely agree.
BCrypt with lots of rounds would be best.
The problems all come from using it for authentication.
With this disclosure, much of what banks and others use to authenticate my identity is now out in the open.
[1] https://baird.bluematrix.com/docs/pdf/dbf801ef-f20e-4d6f-91c...