Problem for companies is clients will ask for this or that certification (a due diligence checkbox they have little control over). Also unless you’re a big co., there is no way a service provider will let small co. customer interview the security and development teams and let you audit their security practices, etc. So at that point a known low bar is better than an unknown unset bar.
That's true, but it's vitally important that companies satisfying "framework" requirements for sales enablement understand why they're doing it:
1. They should adopt frameworks only when there's certainty that the revenue coming in from the sales they enable justifies the expense of performing the framework.
2. They should minimize the scope of work they do to satisfy the framework, keeping a clear head about the fact that these are sales enablement tasks, not security program tasks.
3. They should design and execute a real security program independent of the frameworks, being careful not to let the real program get led around by the framework compliance tasks, which are unrelated to security.
The real danger with these frameworks is that people don't do (3), but rather use the framework as a runbook for building a security practice. That's a terrible idea with a terrible track record, because frameworks aren't designed to security your company, but rather to document what a consortium of IT security people, largely from huge companies with diffuse, unaccountable security teams, happen to be doing.
Absolutely nailed it with this take. This summarizes the sales enablement piece perfectly.
Unfortunately business benefit is easiest to quantify from a sales enablement perspective as opposed to a security program perspective. Agree wholeheartedly you need to do (3) to actually move the needle on security.
Having worked with a number of different companies, and these frameworks are the floor of best practices, these frameworks are far above the subterranean caverns many companies operate their security postures from.
You can do worse than The Frameworks! But it doesn't follow logically that The Frameworks are a good starting place --- they can be (really: are) worse than the outcome from simply ignoring The Frameworks altogether.
> By a wide margin, their most impactful designed purpose is to sell security products and services
The cyber causality dilemma - which came first, the vendor or the framework?
I think there's some use for the framework to make people think about which controls and concepts might work for a given situation, but certainly they need the real world to be examined in parallel to be useful
they are popular because insurance, law, and regulations. it's hard to measure a corps security posture in a way that can apply to everyone and every thing. read them, know them, and if you are required to, meet them. but don't think for a second having all the boxes ticked gets you secure.
in fact I would suggest cis controls over nist and iso for pretty much everyone, but nothing beats knowing your environment inside and out, and striving for 100% visibility.
One indicator of the intellectually bankruptcy of this article's summary is the equivalence it draws between NIST's framework (which is really just an index of other frameworks), ISO 27001 (a certification), and PCI (a domain-specific audit program). It's an incoherent way to think about frameworks, even if you think there's value in them (I think it's probably clear to everybody that I don't).
Those frameworks should be treated as guidelines to build a mature security programme, and not just tickbox exercise.