You would expect a serious firm to have auditing and logging that would provide the necessary forensics without having to rerun an exploit.
This doesn't shout amateur hour to me directly, it seems more kicking a dead horse while its down, but that doesn't mean it isn't amateur hour or a complete company wide failure to prioritize security and secrecy of customer data at Equifax.
I'm not trying to defend them, just stating this sounds somewhat misleading and sensationalized.
I haven't seen any proof that Equifax operates in any other way. I am not attempting to be rude, only stating fact.
Do you work for Equifax?
Can you share that proof?
https://www.consumer.ftc.gov/blog/2017/09/equifax-data-breac...
> If you have a credit report, there’s a good chance that you’re one of the 143 million American consumers whose sensitive personal information was exposed in a data breach at Equifax, one of the nation’s three major credit reporting agencies.
> Here are the facts, according to Equifax. The breach lasted from mid-May through July. The hackers accessed people’s names, Social Security numbers, birth dates, addresses and, in some instances, driver’s license numbers. They also stole credit card numbers for about 209,000 people and dispute documents with personal identifying information for about 182,000 people. And they grabbed personal information of people in the UK and Canada too.
Sensitive personal and financial data of half of American adults, as well as UK and Canadian citizens. For 90 days. If that isn't proof, I don't know what is.
I am familiar with systems that do, and do not believe it to be an unreasonable ask depending on GRC [1] requirements. Storage is cheap, compression effective.
[1] https://en.wikipedia.org/wiki/Governance,_risk_management,_a...
Record systems must be able to represent the exact EHR presented to a query e.g. to check if there was a human error like some one missreading the record.
This is achieved by keeping record versions and a record history this isn’t achieved by having system logs and audit trails of queries returned.
Essentially your EHR system would work like git you’ll be able to query the same commit as the original query but it doesn’t mean that your database audit trail would record any parts of the electronic health record that is simply not allowed.
The other approach, of being able to replay a historical query described in a log while disallowing the private content in the logs allows the audit logs to be stored in a way that can be biased for better storage durability, without quite the same recursive audit nightmare. The logs are much smaller and can be easily replicated and archived, without quite the same level of risk from exposure of log content. Not to say those other logs are not also worth protecting, but there are different ways to balance the risks and costs...
The last thing you want is PII or other regulated date sitting in splunk in fact each large organization that handles such data will have systems to ensure that this does not happen as the regulatory requirement is simple - do not log sensitive data there are tons of both client side and server side plugins and tools for common logging frameworks and log aggregators that search and delete sensitive data or sanitize it before it being logged completely and usually you run a combination of both.
On the storage/performance side since you need to keep access logs sometimes for years if you store query results you’ll need storage 1000’s and 1000’s of times the size of your DB to store those logs this isn’t feasible.
What you log is often the query how many result did it return the user and or app that run the query.
I have encountered very few (not saying it's good, just that's how it is) companies with detailed database query+results logging that was stored for long enough, in any usable way...