(This is one of the reasons I'm generally pro-OSS for digital infrastructure: security quickly becomes a compliance game at the scale of government, meaning that it's more about diligently completing checklists and demonstrating that diligence than about critically evaluating a component's security. OSS doesn't make software secure, but it does make it easier for the interested public to catch things before they become crises.)
Also, any certificate bears a certificator company name. We can always say "company A was hacked despite having its security certified by company B". So that company B at least share some blame.
But yes, there are many standards for this (e.g. SOC Type 2 reports).
In defense of their utility, the good ones tend to focus on (a) whether a control/policy for a sensitive operation exists at all in the product/company & (b) whether those controls implemented are effectively adhered to during an audited period.
An auditor would certainly have some consequences if they were exposed for auditing negligently.
This is how the PCI SSC manages to claim that no compliant merchant/service provider has ever been breached, because they assume being breached means that the breached party was non-compliant at the time of the breach. Which is probably a technically true statement, but is a bit misleading about what they’re actually claiming that means.
You're totally right. Why are people afraid to say that they're worthless? Why caveat or equivocate?
Adversaries in computer security do not mince words.
Actually, I doubt they would have upgraded the apps and pocketed the profits instead but SOC2 is providing cover instead of real change.
Maybe the org prioritized poorly and sucks overall, but that doesn’t mean SOC2 or compliance generally is worthless.
THAT WAS THE PROBLEM. My bad, I thought most hacks were due poor software management but I'm glad SOC2 truly addressed the real problem.
But also you gotta have the balls to stand up to the guy pushing soc2 and say. No. There are known vulnerabilities. We are patching those first then we are doing soc2. The way I frame it is “we know we have critical vulnerabilities, we don’t need to go hunting for more till we fix them. Once we fix them we go looking for other ways to improve security posture” And if the ceo still insists (big client requires it so we’re doing soc2 simultaneously) you say fine, then hire a security consultant so we can go twice as fast. And if he refuses you quit because fuck that place.
That shoudl have caught these types of exposures?
I almost feel I could write novels (if only I had time and could adequately structure my thoughts!) on this and adjacent topics but the simple fact is that the SDLC in a lot of enterprises/organizations is fundamentally broken, unfortunately a huge portion of what breaks it tends to occur long before a developer even starts bashing out some code.
Yes you can, you can access the source code to audit it.
So, I guess you could have some sort of escrow third party that isn't Crowdstrike or MS to do this "audit"?
Or see this for a much better write up: https://stratechery.com/2024/crashes-and-competition/
That's not the default option for kernel drivers on Windows, so this was an explicit choice on Crowdstrike's part.
Your company must meet said requirements to become a vendor for certain agencies or even be able to submit an RFP for governmental agencies.
Now, why wasn't the requirement enforced? Or why didn't the audit turn this up? Good questions.
But all of those are going to have some kind of requirement, e.g. FedRAMP.