No, no to all of this.
Speaking from experience
1.) At their worst - many industry-prescribed standards act to move liability from the poor Visa of the world onto smaller businesses. For example, being visa in this scenario - Why should I develop a better solution to credit card/identity theft? We have PCI!! I can even help sell training out of the goodness of my heart! This, of course, stagnates the industry, both through lost leaders thinking this piece of paper will protect them or to the parasitic cottage industries that capitalize on the fact nobody knows better and takes what could have been an investment in solving fundamental security problems. Ultimately accountability goes back to Visa / SWIFT and whatever body that cba’d on fixing the problem they created.
HOWEVER
2.) At their best many of these standards invite operational rigor required when you want to move past the “3 people in a basement” stages of your startup and have to make grown-up decisions if someone is hit by a train. Furthermore, security is often considered a cost center; attaining specific certifications can be one of the few indirect ways to attribute as a measurable product differentiator in whatever space you’re in.
The author's argument that these frameworks are a decent place to start to work on the comprehensive “cyber security” strategy is excellent for the neophyte looking to understand better one of the many elements that go into running a security program, but it’s far from comprehensive. It’s sad to think, but sometimes these compliance-driven certifications often become one of the few forcing functions you have as a security engineer/leader to get someone to do something that closely resembles the right thing. I’m sure many roll their eyes reading this comment, but - I’ve had countless interactions with engineers who could give less of a shit if their product is insecure just as long as they can ship it on time and be offline by 4, and my only option is to get the legal department to chase them because we will fail an audit if they don’t change course.
Either way. I’d recommend anyone reading the article to have an open mind to understanding many of these frameworks, what they are used for, and how you might use them effectively until we figure out something better. Don’t just cargo cult “standards r bad”, “Jira is dumb”. Try to ask the broader question of why they are needed in the first place.
It is not a punitive act, it is a business imperative.
(I am also deeply skeptical of these frameworks, but don’t have a strong argument against them, and they seem pervasive in the security industry)
Those frameworks should be treated as guidelines to build a mature security programme, and not just tickbox exercise.
By a wide margin, their most impactful designed purpose is to sell security products and services.
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.
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.
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
If a big company can’t explain why they aren’t doing the bare minimum defined in a framework, that’s a red flag.
There are open source solutions for the majority of controls in these frameworks. It isn’t 1995.
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.