5 ms·

> so if I design a car with a faulty steering mechanism that fails under unusual circumstances but, when it does, can cause a possibly fatal accident What was

> so if I design a car with a faulty steering mechanism that fails under unusual circumstances but, when it does, can cause a possibly fatal accident What was the faulty product in this case? Struts? Why is Equifax liable? > The Equifax breach here was caused by, at the very least, reckless negligence in that they failed to patch a published vulnerability for MONTHS after it was disclosed. You have no knowledge of their internal security practices, or what the status of knowledge of the vulnerability was. Did they make a mistake? Absolutely. But no security is perfect. You have zero basis to make such a claim. > What I'm talking about is having the same expectations, requirements and civil and criminal punishments that product liability would have with a physical product, at least when it comes to willful negligence of this sort. There are already laws on the books that cover this, as well as the CFPB. I expect significant fines and additional oversight for Equifax in the coming months. > The VW emissions scandal (rightly) is resulting in criminal prosecutions for fraud. Because that was a real, provable, honest to goodness fraud, where there was provable criminal intent. Just like Enron. Where's the criminal intent with Equifax?

raesene6 9y ago
As to the first point, Equifax could be liable as they are the one operating the system (for profit), and they're the one processing personal information using it. If they had been using commercial software they might have been able to shift the liability (if it existed) to the vendor based on it being not fit for purpose, but as they were using open source, no such option would be open to them.
- g051051 9y ago
  How is that a "product liability" issue, as put forth by OP? What faulty product did they sell to consumers?
  - raesene6 9y ago
    Well they sold services which made use of a vulnerable version of struts.... You can argue services != products, but It could be argued a similar approach could apply. The fact that they didn't sell those services to consumers but that consumers are the ones impacted is actually a big part of the problem. There's an externality here in that the people who suffer the loss have no part in the transaction (they are neither buyer no seller) so have no way to, in an economic sense, impact Equifax's behaviour, which does lead to the idea that regulation could be an appropriate approach.
    - g051051 9y ago
      > The fact that they didn't sell those services to consumers but that consumers are the ones impacted is actually a big part of the problem. Perhaps, but it's a different problem that product liability. > which does lead to the idea that regulation could be an appropriate approach. CRAs are already regulated.
  - rhizome 9y ago
    If I can jump ahead a little, are you saying that bad (e.g. fraudulently-inserted) CRA data cannot rise to the level of actual damages?
    - g051051 9y ago
      Who's doing the fraud? Is it Equifax, which is in good faith recording the information provided by its customers (credit companies, banks, etc)? The credit company that is reporting in good faith to Equifax (or another CRA), but is tying it to the wrong person because an account was fraudulently opened? Is it the person who used stolen ID data to open the account? Is it the thief who originally stole the data?
      - rhizome 9y ago
        The US doesn't have a data-protection law, but how can you say their recording of the information is in good faith if they allow unauthorized people to make spurious changes via their systems and security practices?
        g051051 9y ago
        > allow unauthorized people to make spurious changes via their systems and security practices? I don't follow. Who's the unauthorized party that's "allowed" to make spurious changes via their systems and security practices?
        rhizome 9y ago
        Those who use the holes in their infrastructure, did you see the story about a database being accessible with default credentials? There is some question of scope for that particular issue, but it bodes duplication in the company's practices elsewhere.
        g051051 9y ago
        You mean the web site that didn't have any non-public data, and was actually not in active use for 3 years? I agree that was sloppy, but the site didn't have the level of security requirements that one of the main sites or their internal network had. Do you put a $100 lock on a $5 bike? And how was this "allow[ing] unauthorized people to make spurious changes"? No data was changed in the breach.
FireBeyond 9y ago
> What was the faulty product in this case? Struts? Why is Equifax liable? Struts had provided a remedy for the fault, months prior. Equifax had _failed_ to implement that remedy, because it was 'difficult', 'complex' (due to its own application / deployment / infrastructure), for several months, on a highly sensitive service.
- g051051 9y ago
  > Equifax had _failed_ to implement that remedy, because it was 'difficult', 'complex' (due to its own application / deployment / infrastructure), for several months, on a highly sensitive service. Can you cite your source for these claims?
  - kogepathic 9y ago
    I don't work for Equifax, so I can't give you any inside information which confirms why they didn't patch Struts. However it is common knowledge among security professionals that it was the unpatched Struts vulnerability that lead to the data compromise. [0] [0] https://krebsonsecurity.com/2017/09/equifax-hackers-stole-200k-credit-card-accounts-in-one-fell-swoop/ https://krebsonsecurity.com/2017/09/equifax-hackers-stole-20...
    - g051051 9y ago
      It was also announced by Equifax themselves so of course it's common knowledge. I'm not sure of your point here. https://investor.equifax.com/news-and-events/news/2017/09-15-2017-224018832 https://investor.equifax.com/news-and-events/news/2017/09-15... "Upon discovering a vulnerability in the Apache Struts web application framework as the initial attack vector, Equifax patched the affected web application before bringing it back online."
      - spathi_fwiffo 9y ago
        He already made his point: "Struts had provided a remedy for the fault, months prior." According to your quote, they patched only after they were the victims of a breach; they should have been pro-active and dealt with the issue as soon as the vulnerability was made public.

raesene6 9y ago

As to the first point, Equifax could be liable as they are the one operating the system (for profit), and they're the one processing personal information using it. If they had been using commercial software they might have been able to shift the liability (if it existed) to the vendor based on it being not fit for purpose, but as they were using open source, no such option would be open to them.

g051051 9y ago
How is that a "product liability" issue, as put forth by OP? What faulty product did they sell to consumers?
- raesene6 9y ago
  Well they sold services which made use of a vulnerable version of struts.... You can argue services != products, but It could be argued a similar approach could apply. The fact that they didn't sell those services to consumers but that consumers are the ones impacted is actually a big part of the problem. There's an externality here in that the people who suffer the loss have no part in the transaction (they are neither buyer no seller) so have no way to, in an economic sense, impact Equifax's behaviour, which does lead to the idea that regulation could be an appropriate approach.
  - g051051 9y ago
    > The fact that they didn't sell those services to consumers but that consumers are the ones impacted is actually a big part of the problem. Perhaps, but it's a different problem that product liability. > which does lead to the idea that regulation could be an appropriate approach. CRAs are already regulated.
- rhizome 9y ago
  If I can jump ahead a little, are you saying that bad (e.g. fraudulently-inserted) CRA data cannot rise to the level of actual damages?
  - g051051 9y ago
    Who's doing the fraud? Is it Equifax, which is in good faith recording the information provided by its customers (credit companies, banks, etc)? The credit company that is reporting in good faith to Equifax (or another CRA), but is tying it to the wrong person because an account was fraudulently opened? Is it the person who used stolen ID data to open the account? Is it the thief who originally stole the data?
    - rhizome 9y ago
      The US doesn't have a data-protection law, but how can you say their recording of the information is in good faith if they allow unauthorized people to make spurious changes via their systems and security practices?
      - g051051 9y ago
        > allow unauthorized people to make spurious changes via their systems and security practices? I don't follow. Who's the unauthorized party that's "allowed" to make spurious changes via their systems and security practices?
        rhizome 9y ago
        Those who use the holes in their infrastructure, did you see the story about a database being accessible with default credentials? There is some question of scope for that particular issue, but it bodes duplication in the company's practices elsewhere.
        g051051 9y ago
        You mean the web site that didn't have any non-public data, and was actually not in active use for 3 years? I agree that was sloppy, but the site didn't have the level of security requirements that one of the main sites or their internal network had. Do you put a $100 lock on a $5 bike? And how was this "allow[ing] unauthorized people to make spurious changes"? No data was changed in the breach.

FireBeyond 9y ago

> What was the faulty product in this case? Struts? Why is Equifax liable? Struts had provided a remedy for the fault, months prior. Equifax had _failed_ to implement that remedy, because it was 'difficult', 'complex' (due to its own application / deployment / infrastructure), for several months, on a highly sensitive service.

g051051 9y ago
> Equifax had _failed_ to implement that remedy, because it was 'difficult', 'complex' (due to its own application / deployment / infrastructure), for several months, on a highly sensitive service. Can you cite your source for these claims?
- kogepathic 9y ago
  I don't work for Equifax, so I can't give you any inside information which confirms why they didn't patch Struts. However it is common knowledge among security professionals that it was the unpatched Struts vulnerability that lead to the data compromise. [0] [0] https://krebsonsecurity.com/2017/09/equifax-hackers-stole-200k-credit-card-accounts-in-one-fell-swoop/ https://krebsonsecurity.com/2017/09/equifax-hackers-stole-20...
  - g051051 9y ago
    It was also announced by Equifax themselves so of course it's common knowledge. I'm not sure of your point here. https://investor.equifax.com/news-and-events/news/2017/09-15-2017-224018832 https://investor.equifax.com/news-and-events/news/2017/09-15... "Upon discovering a vulnerability in the Apache Struts web application framework as the initial attack vector, Equifax patched the affected web application before bringing it back online."
    - spathi_fwiffo 9y ago
      He already made his point: "Struts had provided a remedy for the fault, months prior." According to your quote, they patched only after they were the victims of a breach; they should have been pro-active and dealt with the issue as soon as the vulnerability was made public.