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).
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.
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.
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 ;)
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.
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.
> 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).