5 ms·

Or it's a pile of nonsense from a company desperate to deflect blame. How could poor poor Equifax defend itself against foreign governments? The reality is Eq

by x0x0 7y ago

Or it's a pile of nonsense from a company desperate to deflect blame. How could poor poor Equifax defend itself against foreign governments? The reality is Equifax are lazy stupid idiots who * couldn't patch well known holes in infra for months (note that a 2 engineer startup could do better by eg running rails and checking bundler-audit on every deploy); * disabled their IDP because they didn't keep a cert up-to-date; * didn't notice their disabled IDP FOR 10 MONTHS because lazy stupid incompetent; * strongly appear to have no internal access controls, so regular app users in the db could exfiltrate the entire DB without creating any internal alerts In contrast to the self-serving nonsense in the Bloomberg article, there was nothing sophisticated here. These people couldn't get the most basic things right, all part of the most very basic security posture: patch known holes. Regularly verify such patching. Run an IDP. Verify the IDP is running. Have controls around odd behavior or bulk queries for the DB users running on your front-end boxes.

g051051 7y ago
> Or it's a pile of nonsense from a company desperate to deflect blame. How could poor poor Equifax defend itself against foreign governments? Bloomberg has plenty of criticism, they just don't wrap it in the shrill click-bait headlines of other "news" outlets. > note that a 2 engineer startup could do better by eg running rails and checking bundler-audit on every deploy) On systems a fraction of the size, with a fraction of the traffic, and not under a constant withering assault from hackers.
- x0x0 7y ago
  the point -- which I believe you deliberately missed -- is the tools are available from the very beginning to know if you are shipping code with known CVEs. It's easily available. I'm not sure why you're invested in pretending this is super hard, or that it isn't extremely easy to do correctly if it is a company priority to do so. As their scale, it's also straightforward to build and maintain the list of sites you're running, what's running them, and the versions of libs in place. Particularly because you can have dedicated engineering for the above. It really comes down to whether it's a corporate priority or not.
  - g051051 7y ago
    > I'm not sure why you're invested in pretending this is super hard, or that it isn't extremely easy to do correctly if it is a company priority to do so. The enormous amounts of money and time that companies spend on this problem, and still not get it right, disproves your assertion of simplicity.
    - x0x0 7y ago
      And yet there's lots of examples of companies that aren't trivially breached, and can promptly roll patches for CVEs.
      - g051051 7y ago
        And just as many that are breached in spite of their best efforts. Perfect security is impossible.
        x0x0 7y ago
        Let's not shift the goalposts from competent to perfect.
        g051051 7y ago
        Even competent security is difficult, especially at the scale that large companies operate at. Attackers are very sophisticated, and patient.
        x0x0 7y ago
        Your implicit claim that it's difficult to 1 - know what assets are on what domains 2 - know the code backing them is belied by the many competent orgs that do that. And the fact that it's table stakes for a reasonable security posture. Further, it's not that technically challenging, not least because it can be human automated. Detection tools are available right here: https://www.metasploit.com https://www.metasploit.com for $0. You can have a human run that once a week against your web properties and do way way better than Equifax. Because Metasploit would have alerted on the Struts vuln. It's also not rocket science to have a member of a security team run that against a list of web properties (that can be trivially sourced from your DNS server even if they bypassed internal deployment processes). Nothing about this is sophisticated beyond basic computer skills -- grabbing known sites from your security docs, backing that up with DNS entries, alerting on anything missing, and running metasploit from a script. Unless, of course, you're hellbent on claiming the above is super duper hard.
- mannykannot 7y ago
  >...and not under a constant withering assault from hackers. There are really only two alternatives here: either the problem is not solvable, in which case Equifax should not be conducting its business in the way it is, or it is solvable, in which case Equifax should not be conducting its business in the way it is until it gets its security act together.
viraptor 7y ago
> note that a 2 engineer startup could do better 2 engineers produce 2 engineers worth of code/infrastructure. Equifax has much more than that to manage. And at corporate scale just knowing what you're running is a significant challenge, which is a step before version management. I'm not trying to justify bad assets management, but if anyone's comparing their situation to a 2 engineer startup, they don't understand corporate it environments or issues or that scale/budget.

by x0x0 7y ago

g051051 7y ago

> Or it's a pile of nonsense from a company desperate to deflect blame. How could poor poor Equifax defend itself against foreign governments? Bloomberg has plenty of criticism, they just don't wrap it in the shrill click-bait headlines of other "news" outlets. > note that a 2 engineer startup could do better by eg running rails and checking bundler-audit on every deploy) On systems a fraction of the size, with a fraction of the traffic, and not under a constant withering assault from hackers.

x0x0 7y ago
the point -- which I believe you deliberately missed -- is the tools are available from the very beginning to know if you are shipping code with known CVEs. It's easily available. I'm not sure why you're invested in pretending this is super hard, or that it isn't extremely easy to do correctly if it is a company priority to do so. As their scale, it's also straightforward to build and maintain the list of sites you're running, what's running them, and the versions of libs in place. Particularly because you can have dedicated engineering for the above. It really comes down to whether it's a corporate priority or not.
- g051051 7y ago
  > I'm not sure why you're invested in pretending this is super hard, or that it isn't extremely easy to do correctly if it is a company priority to do so. The enormous amounts of money and time that companies spend on this problem, and still not get it right, disproves your assertion of simplicity.
  - x0x0 7y ago
    And yet there's lots of examples of companies that aren't trivially breached, and can promptly roll patches for CVEs.
    - g051051 7y ago
      And just as many that are breached in spite of their best efforts. Perfect security is impossible.
      - x0x0 7y ago
        Let's not shift the goalposts from competent to perfect.
        g051051 7y ago
        Even competent security is difficult, especially at the scale that large companies operate at. Attackers are very sophisticated, and patient.
        x0x0 7y ago
        Your implicit claim that it's difficult to 1 - know what assets are on what domains 2 - know the code backing them is belied by the many competent orgs that do that. And the fact that it's table stakes for a reasonable security posture. Further, it's not that technically challenging, not least because it can be human automated. Detection tools are available right here: https://www.metasploit.com https://www.metasploit.com for $0. You can have a human run that once a week against your web properties and do way way better than Equifax. Because Metasploit would have alerted on the Struts vuln. It's also not rocket science to have a member of a security team run that against a list of web properties (that can be trivially sourced from your DNS server even if they bypassed internal deployment processes). Nothing about this is sophisticated beyond basic computer skills -- grabbing known sites from your security docs, backing that up with DNS entries, alerting on anything missing, and running metasploit from a script. Unless, of course, you're hellbent on claiming the above is super duper hard.
mannykannot 7y ago
>...and not under a constant withering assault from hackers. There are really only two alternatives here: either the problem is not solvable, in which case Equifax should not be conducting its business in the way it is, or it is solvable, in which case Equifax should not be conducting its business in the way it is until it gets its security act together.

viraptor 7y ago

> note that a 2 engineer startup could do better 2 engineers produce 2 engineers worth of code/infrastructure. Equifax has much more than that to manage. And at corporate scale just knowing what you're running is a significant challenge, which is a step before version management. I'm not trying to justify bad assets management, but if anyone's comparing their situation to a 2 engineer startup, they don't understand corporate it environments or issues or that scale/budget.