[cookiengineer]

TLDR is:

Equifax had no working firewall / intrusion detection for almost a year, because they did not update their snakeoil MITM certificate and forgot about it.

Remind me again, how did Equifax get SOC 1&2, and ISO27001 certified?

Oh yeah, they probably have a checklist for that, so they must be secure. /s

[dilyevsky]

Why "snakeoil"? Sounds like the system actually caught the intrusion once operable! The fact it was silently down for god knows how long is another matter...

> Remind me again, how did Equifax get SOC 1&2, and ISO27001 certified?

You probably already know that these are compliance CYA focused around process not actual measure of how secure the system is (if there could be such a thing).

[jszymborski]

Snakeoil is a term for self-signed certs. I think they were lamenting the fact that it was not updated, not that it was self-signed.

https://eleni.blog/2019/04/10/the-snakeoil-ssl-certificate/

[tialaramex]

As another person pointed out, it's just usual to name this certificate "snakeoil" because it's just ticking a box mechanically and serves little to no functional purpose. The service won't run without a certificate, this is a certificate, good enough. You might prefer to think of it as a placebo, but "snakeoil" seems to be usual name.

Yes, you're correct ISO standards are very focused on paperwork.

One of the fears some C++ people have is that today ISO 26262 (safety for road vehicles) says they can write car software in C++ because hey, there's an ISO standard for C++ so that's paperwork we can point to - But, wait, why is that enough? C++ is laughably unsuited to this work. Maybe 26262 should be revised to not say that C++ is suitable.

[cookiengineer]

Funny you mention ISO 26262 and somewhat were pointing to the dumpster fire that is Misra-C :D

Eversince ISO 21434 got rolled out, all Tiers are panicking because they need to introduce modern CI/CD pipelines that work with source verification. Simple things like generating an SBOM become impossible because even the Tiers that sold you their software don't have the source code themselves and just redistribute binaries from another Tier down the line.

I am somewhat a strong opponent of using C for these kind of areas because in the automotive industry I learned the hard way that these firmwares are pretty much the definition of unmaintainable.

Sometimes Tiers even cannot compile their own software anymore because they lack licenses of old Vektor DaVinci versions, and they literally have deals with Vektor where they send zip files and an excel spreadsheet that reflects the dependencies of kernel modules, and a _person_ not a program sends back the compiled firmware.

[cookiengineer]

Well, the process itself cannot be working because otherwise this whole fiasco would have been found. Technically within 24 hours, if the certifications are to be believed.

Trying to defend a broken process isn't what this is about, my critic was about that there was an audit a decade ago, and that the auditors did not verify any of the claims or processes in place. Certifications and audits without any verification of claims are not valid certifications.

SOC2 and ISO27001 also include _mandatory_ pentests which obviously didn't happen that year. Either that or the pentesting agency wasn't actually doing more than a metasploit run ;)

[bennyelv]

Common misunderstanding about 27001 - it doesn’t have mandatory anything when it comes to security controls.

It defines how you structure and operate a risk based security management system, that’s all. It’s perfectly valid to say “I should be doing pen testing but my risk appetite is high enough for me not to care”, and still get a 27001 certification.

[cookiengineer]

> “I should be doing pen testing but my risk appetite is high enough for me not to care”, and still get a 27001 certification.

I would agree with you if Equifax wouldn't be part of critical infrastructure.

[bennyelv]

Agreed - but 27001 doesn't have an opinion on that. It only requires that top management have set the context that the rest of the information security management system hangs off of. It doesn't specify what that context should be for your company.

It's completely unlike SOC in that regard.

[Roark66]

Personally I think the root cause of this was bad documentation practices. If the old system was properly documented they would've scanned the right folder.

Likewise with the certificate, if there was documentation to indicate when that cert expires (or monitoring to alert few weeks in advance) they would have a functioning ids and these web shells would be found immediately.

Unfortunately, out of half a dozen fortune 500 companies I worked for perhaps 2 had doc practices good enough to prevent this.

[yuliyp]

That feels like the wrong conclusion. Assuming documentation will be followed properly is not a reasonable security strategy. Validation and monitoring is needed. That their NIDS gracefully degraded to a "don't monitor the payloads" when it was expected that it would be monitoring those and nobody noticed is a problem. A scan of a system which misses a web server running it without erroring is a problem.

[hn_throwaway_99]

Couldn't agree with this more. While I think it's important to have good documentation, it is nearly always a very bad idea to rely on that documentation being 100% correct. Businesses simply have way too many moving parts to assume the state of the world is always up-to-date in the documentation.

You also highlight a very good point. Things like security software should "break loudly", i.e. beyond just sending alerts (which can be ignored), there should be some explicitly "painful" steps that occur if the security system is in a broken state for long.

[bishopsmother]

Does the use of snakeoil in the TLDR not run contrary to the narrative in the blog? When the 'snakeoil MITM' certificate was updated - they became aware of, as a direct result of MITM, a problem that had not previously been known to them?