Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Failure to apply a patch for a two month old bug led to this entire nightmare scenario. What are some best practices to ensure that ones dependencies are always up to date?

-asking as a relatively inexperienced dev



Equifax makes their partners have a fully implemented and tested patch management program and audits annually (or via a third party) that you stick to it, making this situation even more hilarious.


Failure to patch wasn't the cause of this breach. The causes of this breach were:

1. Reliance on a consumer-grade component in a security-critical system holding high-value data.

The portal should have had a small, audited code base with secure coding techniques and minimal reliance on third-party components.

2. Excessive attack surface on a system holding high-value data.

The machine hosting the portal should never have had read access to SSNs. Sensitive data should have been "thrown over the wall" to a secure backend with a constrained interface. This would have greatly reduced the scope of the breach.


If you're lazy and dealing with a non-critical system, `yum update --security -y` as a nightly cron job goes a long way.

If you're working on something important, say critical national economic infrastructure, you do the equivalent with automated staging and testing happening before any potentially breaking changes are made to live servers.

Or... you do nothing, as the case may be...


Yum isn't going to patch Struts, though. That's an application package.

There are services that monitor your package configuration(s) and let you know when something has been updated.

There are also mailing lists. Unless you're a Node developer, you probably only have a couple dozen dependencies in your app. Subscribe to them.

Finally, you can just check in your lockfile and update packages as part of your dev builds, then commit it whenever something changes. Your CI/CD will make sure you are always running the latest version of every application dependency in production.


Keep an up to date asset register before anything else. If you don't know what's in your platform then your running blind.


Have a process to know what all your shit is and be paranoid about using any shit. Being paranoid helps.


Although I'm sure Equifax is not going to be very forthcoming about this aspect of it, not having plaintext passwords visible after logging in as admin/admin also helps.


Applying patches when they come out...


Don't hire someone who majored in Music Composition as your Chief Security Officer is key.


I knew a music major who is a Linux kernel dev hacker. I know someone who has a law degree who worked on the file system your probabily using now.

Don't be so quick to judge.


Nobody's saying music majors are incompetent. But this woman's sole qualification is that. She is not a "kernel dev hacker" AFAICT. Do you know if she is in any way qualified to be CSO of a huge corp handling so much sensitive customer data?


Based on her work experience she seemed qualified.


She held another position as director of security, but no hands on technical roles ever. It really looks like the resume of a middle manager who moved to CSuite. I didn't see anything that indicated she was technical


You mean her "Head of Security when Equifax was Hacked" work experience?


I heard she was in a similar role at First Data, prior to the Equifax gig.


Don't hire an unqualified person. These two things are not equivalent. Their major in college is only one small part of that picture.

I have known people without degrees (or without relevant ones) that learned on their own and were great. I have known people with a CS degree that were terrible.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: