3 ms·

Equifax has an $18B market cap. Can you name one instance of a government imposed fine for improperly stored PII exceeding even $100M? Furthermore, do you have

Equifax has an $18B market cap. Can you name one instance of a government imposed fine for improperly stored PII exceeding even $100M? Furthermore, do you have evidence that the PII was improperly stored, or that Equifax's security practices were lacking in any way? The vulnerability provided full RCE, and I know of no info-sec magic that inoculates you against that.

konceptz 9y ago
"The vulnerability provided full RCE, and I know of no info-sec magic that inoculates you against that." Not really accurate because the exploit name, especially as generic as RCE, does not tell you how it was done. RCE can be a number of things that can be fixed in numerous ways. For example, file upload functionality with path manipulation and no file type validation may lead to RCE. This can certainly be removed with properly crafted file upload handling. Some RCE, particularly on lower layers of the application stack, may be more difficult to defend against, especially in the case of unknown exploits.
- cloakandswagger 9y ago
  Fair enough. I more meant that after an attacker has achieved RCE, no amount of encryption or other practices can protect sensitive info in your database.
  - sdenton4 9y ago
    Why does the webserver need access to All of the Datas? Store the data separately, and create use-tokens for webservers to access data once users have authenticated. The webservers should be treated as if they're potentially compromised, not given arbitrary access to a database...
  - duskwuff 9y ago
    Encryption can't save you, but other practices can. Specifically: if you're working with a lot of very sensitive information, you structure your application such that there are multiple layers separating that data from the outside world. In the case of Equifax, that might mean implementing the "credit score check" as an internal service exposed through the public web servers (or whatever).
    - kevan 9y ago
      Exactly. While nothing can completely stop attackers, there are multiple techniques you can layer to slow them down. E.g: * Credential vaults that allow only-once retrieval on application startup and only keep credentials in memory * anomaly detectors for request patterns (suspicious payload formats, processing time, CPU/memory usage, etc), * Honeypot records in sensitive data stores (records you know should never be accessed, if they are you've been breached) If you're storing information this sensitive you need to be paranoid, because an attacker has a $4B incentive ($30/identity on the black market * 143 million records) to crack your systems.
  - TheCondor 9y ago
    No you have to use other architectures for defending against that. Equifax sells queries to this data, they also use queries to that data as a trigger to change your credit rating. It seems like you'd want a very tightly audited mechanism for issuing these queries to make sure they are properly billed. Referring to it as a struts issue makes it sound like someone popped a web server, fired up a dub client and started dumping unencrypted tables. It seems amazing that nothing tripped up some monitoring or something.
empath75 9y ago
Having root on a web server shouldn't give you access to 147 million customer records.
- cloakandswagger 9y ago
  I'm eagerly awaiting the technical details of the attack. If it turns out that their web server has 100% unfettered access to the database then I'll gladly pick up a pitchfork as well. I'm wondering if Equifax is using Struts-provided REST for its entire architecture. If that's the case, gaining access to the web server was only the first step. From there the attacker could perform RCE on sensitive services.
  - sillysaurus3 9y ago
    If it turns out that their web server has 100% unfettered access to the database then I'll gladly pick up a pitchfork as well. You may want to think twice. Try to design an architecture that doesn't have that. If you think it through, you'll realize the best you can do is not to deny access, but to monitor access so that any statistical deviation in requests-per-hour will trigger an alarm. Yet nobody does that, so why should Equifax have been a pioneer in this method? This is the uncomfortable truth that everyone is obscuring here. There wasn't a solution. Equifax got owned, and they happened to have a trove of data. Everyone now wants to see their heads roll, but you too would find yourself in the same situation if you have an RCE on your servers.
    - Iknowsecurity 9y ago
      Agreed
    - kelnos 9y ago
      > You may want to think twice. Try to design an architecture that doesn't have that. We have an architecture like that where I work. It's not that hard. Our web applications have very little direct access to databases; most of it is mediated by services downstream of the web app. That's certainly not a silver bullet, but it makes it impossible to exploit a RCE vuln in the web server in such a way that it lets you have arbitrary access to the database.
kelnos 9y ago
> The vulnerability provided full RCE, and I know of no info-sec magic that inoculates you against that. If the vulnerability used turns out to be the Struts one that was announced at the beginning of the year, then the "magic" here would have been quite muggle-like: update the damn dependency. Not doing so is negligence, plain and simple. (I agree with you, though, that EFX will almost certainly come out of this relatively unscathed.)
- cloakandswagger 9y ago
  The statement released by Apache said that, if the attack did use the REST plugin vulnerability in Struts, then it would have been a zero-day at the time of use.
  - gaius 9y ago
    You will note that Equifax is not a contributor to Struts - cash or code. They are trying to shift the blame onto something they got for free and work other people did for free.
    - elkos 9y ago
      It's my understanding that Equifax is a multibillion dollar org. (Something in the order of 17 billion USD). Since Struts is a major part of their business infrastructure one would expect a contribution to the Struts project and other software they rely on. They could spin it as "Social Responsibility" too. In retrospect it seems more cost effective to do so too, even if Equifax manages somehow to pay only a few hundred million dollars.
  - bga 9y ago
    Yet Equifax continues to evade giving details on the attack. That itself is damning evidence they weren't doing everything they should have been to protect their servers and data.
ridgeguy 9y ago
I wonder if the legal concept res ipsa loquitur (the thing speaks for itself) could apply here? It's one foundation of tort law. The argument would be that the very fact that PII security was breached demonstrates defendant's negligent data storage/security practices. If those practices had been adequate, the breach would not have occurred.
- cloakandswagger 9y ago
  If that's the case then I'd suggest every software developer on this forum immediately switch careers, this one is doomed.
  - ridgeguy 9y ago
    Well, there is that. Maybe reality is that no set of security practices can ever secure PII. If so, that's an even bigger problem than lackadaisical firms like Equifax. But I think higher expectations, helped along with civil legal machinery that's likely to mete out meaningful punishment, would move us faster to finding out whether the problems are mostly just sloppy practice (which responds to economic penalties) or whether they're more fundamental and need a different fix.
fred_is_fred 9y ago
You need to think beyond the fine. There will be costs of new regulations (if passed), increased costs for lobbying against any said efforts, loss of revenue (would you want to have your company name as a partner for Equifax), and finally lawsuits. Going long may make sense but we've not hit bottom yet.

konceptz 9y ago

"The vulnerability provided full RCE, and I know of no info-sec magic that inoculates you against that." Not really accurate because the exploit name, especially as generic as RCE, does not tell you how it was done. RCE can be a number of things that can be fixed in numerous ways. For example, file upload functionality with path manipulation and no file type validation may lead to RCE. This can certainly be removed with properly crafted file upload handling. Some RCE, particularly on lower layers of the application stack, may be more difficult to defend against, especially in the case of unknown exploits.

cloakandswagger 9y ago
Fair enough. I more meant that after an attacker has achieved RCE, no amount of encryption or other practices can protect sensitive info in your database.
- sdenton4 9y ago
  Why does the webserver need access to All of the Datas? Store the data separately, and create use-tokens for webservers to access data once users have authenticated. The webservers should be treated as if they're potentially compromised, not given arbitrary access to a database...
- duskwuff 9y ago
  Encryption can't save you, but other practices can. Specifically: if you're working with a lot of very sensitive information, you structure your application such that there are multiple layers separating that data from the outside world. In the case of Equifax, that might mean implementing the "credit score check" as an internal service exposed through the public web servers (or whatever).
  - kevan 9y ago
    Exactly. While nothing can completely stop attackers, there are multiple techniques you can layer to slow them down. E.g: * Credential vaults that allow only-once retrieval on application startup and only keep credentials in memory * anomaly detectors for request patterns (suspicious payload formats, processing time, CPU/memory usage, etc), * Honeypot records in sensitive data stores (records you know should never be accessed, if they are you've been breached) If you're storing information this sensitive you need to be paranoid, because an attacker has a $4B incentive ($30/identity on the black market * 143 million records) to crack your systems.
- TheCondor 9y ago
  No you have to use other architectures for defending against that. Equifax sells queries to this data, they also use queries to that data as a trigger to change your credit rating. It seems like you'd want a very tightly audited mechanism for issuing these queries to make sure they are properly billed. Referring to it as a struts issue makes it sound like someone popped a web server, fired up a dub client and started dumping unencrypted tables. It seems amazing that nothing tripped up some monitoring or something.

empath75 9y ago

Having root on a web server shouldn't give you access to 147 million customer records.

cloakandswagger 9y ago
I'm eagerly awaiting the technical details of the attack. If it turns out that their web server has 100% unfettered access to the database then I'll gladly pick up a pitchfork as well. I'm wondering if Equifax is using Struts-provided REST for its entire architecture. If that's the case, gaining access to the web server was only the first step. From there the attacker could perform RCE on sensitive services.
- sillysaurus3 9y ago
  If it turns out that their web server has 100% unfettered access to the database then I'll gladly pick up a pitchfork as well. You may want to think twice. Try to design an architecture that doesn't have that. If you think it through, you'll realize the best you can do is not to deny access, but to monitor access so that any statistical deviation in requests-per-hour will trigger an alarm. Yet nobody does that, so why should Equifax have been a pioneer in this method? This is the uncomfortable truth that everyone is obscuring here. There wasn't a solution. Equifax got owned, and they happened to have a trove of data. Everyone now wants to see their heads roll, but you too would find yourself in the same situation if you have an RCE on your servers.
  - Iknowsecurity 9y ago
    Agreed
  - kelnos 9y ago
    > You may want to think twice. Try to design an architecture that doesn't have that. We have an architecture like that where I work. It's not that hard. Our web applications have very little direct access to databases; most of it is mediated by services downstream of the web app. That's certainly not a silver bullet, but it makes it impossible to exploit a RCE vuln in the web server in such a way that it lets you have arbitrary access to the database.

kelnos 9y ago

> The vulnerability provided full RCE, and I know of no info-sec magic that inoculates you against that. If the vulnerability used turns out to be the Struts one that was announced at the beginning of the year, then the "magic" here would have been quite muggle-like: update the damn dependency. Not doing so is negligence, plain and simple. (I agree with you, though, that EFX will almost certainly come out of this relatively unscathed.)

cloakandswagger 9y ago
The statement released by Apache said that, if the attack did use the REST plugin vulnerability in Struts, then it would have been a zero-day at the time of use.
- gaius 9y ago
  You will note that Equifax is not a contributor to Struts - cash or code. They are trying to shift the blame onto something they got for free and work other people did for free.
  - elkos 9y ago
    It's my understanding that Equifax is a multibillion dollar org. (Something in the order of 17 billion USD). Since Struts is a major part of their business infrastructure one would expect a contribution to the Struts project and other software they rely on. They could spin it as "Social Responsibility" too. In retrospect it seems more cost effective to do so too, even if Equifax manages somehow to pay only a few hundred million dollars.
- bga 9y ago
  Yet Equifax continues to evade giving details on the attack. That itself is damning evidence they weren't doing everything they should have been to protect their servers and data.

ridgeguy 9y ago

I wonder if the legal concept res ipsa loquitur (the thing speaks for itself) could apply here? It's one foundation of tort law. The argument would be that the very fact that PII security was breached demonstrates defendant's negligent data storage/security practices. If those practices had been adequate, the breach would not have occurred.

cloakandswagger 9y ago
If that's the case then I'd suggest every software developer on this forum immediately switch careers, this one is doomed.
- ridgeguy 9y ago
  Well, there is that. Maybe reality is that no set of security practices can ever secure PII. If so, that's an even bigger problem than lackadaisical firms like Equifax. But I think higher expectations, helped along with civil legal machinery that's likely to mete out meaningful punishment, would move us faster to finding out whether the problems are mostly just sloppy practice (which responds to economic penalties) or whether they're more fundamental and need a different fix.

fred_is_fred 9y ago

You need to think beyond the fine. There will be costs of new regulations (if passed), increased costs for lobbying against any said efforts, loss of revenue (would you want to have your company name as a partner for Equifax), and finally lawsuits. Going long may make sense but we've not hit bottom yet.