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.
> 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
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.
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).
I was hoping for a more nuanced take from you, @tptacek. However, this deserves more thought than “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.
Seems like this thread misses regulatory expansion as a business goal. Compliance is the standardized language you use to communicate the great security you do to your customers, and their customers. It removes barriers to adoption. It also opens the door to billions in market access.
It is not a punitive act, it is a business imperative.
Being compliant within any of those frameworks does not make an organization secure. It's a good place to start, and will make the auditors happy, but assuming that (compliance equals secure) is a huge mistake.
I'd push back on this, and say it's a pretty distinctively bad place to start, unless you're starting at Allstate in a parallel universe where Allstate hasn't spent the last 20 years doing this stuff and indirectly influencing these frameworks.
These frameworks don’t guarantee security, but there is a stark difference between companies that do this and those who don’t. Companies that follow these frameworks are at least attempting to be secure.
In my experience, the companies not following these frameworks aren't even _performing_ security.
Everyone here is correct that you need more than just these frameworks/audits to be secure. However, most companies that are secure following these frameworks. If you're secure, these frameworks are a no-brainer to certify against.
> Being compliant within any of those frameworks does not make an organization secure.
I've gotten into breathless arguments with "cyber experts" who really don't understand this simple point. I've met people in industry who literally think that "filling out the paperwork and having a risk committee accept risks or prioritize a schedule to get into compliance" equals "our systems are now secure".
It's a massive self-serving industry incentivized to enrich itself and not secure systems. If they were successful at designing, deploying, and maintaining secure systems, there wouldn't be an industry.
I’ve really been of the opinion as of late that if we took just a small fraction of the time and manpower we waste on pedantic security framework adherence and put it towards training actual staff to and experts to be better cybersecurity professionals, we’d be better off.
I agree with this notion. The issue is you need the security attestation and certifications to give folks in the sales cycle the warm fuzzies. These pedantic measures are directly a pathway to sales enablement and revenue. The actual securing and maturity work is a side benefit.
On the other side of the coin, if a vendor does not have paperwork and evidence to support their programs - how does one as a purchaser or security reviewer verify? Organizations only act truthful to an extent that benefits them. Quality of audits and supporting paperwork is a real mixed bag. Unless you’re an Amazon you’re not going to get the chance to audit your vendors and sub processors outside of reviewing this type of documentation.
My personal take on the land of cyber security frameworks - and especially security standards - is that a good security team should be able to read through a list of controls (e.g. those in NIST 800-171) and express a reasoned opinion on each one with respect to the company's security posture. They are fantastic tools for reminding you what things you might have overlooked and driving a discussion about how your organization is approaching security - basically regardless of what type of company you run.
That's where the value stops - once you give lawyers, policymakers, and insurance companies access to these documents it becomes an unending game of regulatory capture, responsibility derogation, and box-ticking.
You end up with people who have zero context for technology running around demanding to see evidence that your smart toaster implements 12.2.14.1.5b "The centralized time server must enforce separation of duties" before it can be added to the network or some other such incoherent nonsense.
These standards always start in the right place, but they get used in the most frustrating ways because people who don't understand how technology works are, invariably, the auditors and assessors who apply these standards since true technologists can easily find more gratifying jobs doing literally anything else.
The other bad thing they do is encourage technologists who aren't security subject matter experts to invest in programs and tools that aren't valuable, either at their current state or, in some cases, ever. They create the impression that there is an important checklist of things that most companies need to have, and if such a checklist exists, not one of these frameworks captures it.
Yeah, I'm self taught on this stuff, but I've started to think that's not all bad. I literally downloaded every one of the NIST 800 series, the FIPS series, the CNSSIs, all of it, and went through everything to figure out what connected with what. Most of it is pretty damn obvious. You should secure your internet-facing servers, sanitize inputs, never hold actual passwords in a database, use some form of 2FA, etc.
But there are a lot of dudes with degrees in "cyber-something" or "IT something" who lord over me with their government-bestowed positional authority (I'm just the clinical informatics physician with an undergrad in physics from a top school and teach machines to diagnose disease, trying to deploy things to actually save lives, so what the fuck could I possibly know about the dark arts of cybersecurity? "Oh, god, here he is talking to us about numbers again, borrrringgggg. I bet he's going to ask us when the GPUs are going to be on contract. Again. Like, bro, we'll get to it. Later.")
Come to find out a lot of these fuckwads speed-click through their ATO checklists. Shockingly, the timestamps on the checkboxes are all on the Thursday afternoon before the Tuesday "surprise" inspection that happens the same week of the year every time, run by the guy who they used to work for at the last gig.
And then the guys actually trying to get shit done get drowned by the 50 fucking drones who all show up to the weekly meetings and pipe up with their 30 seconds worth of input. And the guy trying to actually deploy product spends the rest of the week establishing that the drone didn't actually know what the fuck was going on in the meeting and just blurted something out at the appropriate moment, relying on the last 30 seconds of banter to guide his statements.
Positive change starts with someone acting on the thought "it doesn't have to be this way."
Fatalism and cynicism are comfortable because they don't ask you to do anything.
Cynicism is ultimately resigned consent.
How many security professionals here have actually sent a thought out letter to their congressperson or the NIST directly? How many people who express the negativity in this thread have tried to e-mail someone in a position of institutional authority or a tech related think tank? How many people have given government service a try? How many people have waited for a security catastrophe and then e-mailed someone who might be able to change policy? How many people have looked up a law and tried to reverse engineer who wrote it and who can influence it?
How many people have tried and failed?
When everyone thinks like yourself, it becomes a self fulfilling prophecy.
NIST CSF = The encyclopedia which breaks security down into as many areas/steps/sections as possible. If you are planning a 500-person security department, this is how you give them all something to do. The idea is to accomplish the task with manpower rather than elegance. CSF itself is mostly just a pointer to NIST 800-53. For truly large-scale operations it can be an ok fit, but for most organizations it is overkill that your cyber-insurance vendor will still expect you to do. Otherwise, best used as a reference not a guide.
ISO 27001 = Not super familiar with this one.
COBIT = The management/process focused version of NIST CSF. Great if you have an executive suite CTO, CISO, CRiskO, CPrivacyO, and want to coordinate their efforts in a program that divides responsibilities among them and associated committees. Includes maturity modeling, which gives it a +1, but it is distant from anything technology related. Instead, it is all about which committees should be formed to decide on risk management strategies etc...
PCI-DSS = You'll do this one because VISA makes you do it. Much more actionable than NIST or COBIT, but it depends on the third-party auditor who is issuing your attestation of compliance. "Your label maker has it's default password?" = audit finding.
CIS18 Controls = The most actionable/lightweight framework now that they have incorporated maturity levels (aka implementation groups). Not as thorough as NIST or COBIT. Well implemented, CIS18 is enough for most organizations provided they do not have a specific security standard or requirement in their industry.
27001 is Euro-SOC2. Technically, 27001 is a certification, and SOC2 is just an attestation --- there is an external ground truth that 27001 is matching security programs to, where SOC2 is just validating internal consistency. But the subject matter is the same and they're generally thought of as equivalents for each other, with 27001 being the more rigorous.
Ironically, COBIT is the IT-focused equivalent of COSO --- in other words, it's the ostensibly more technical set of controls. But SOC2 keys off of COSO, and is audited by accountants, so practitioners are more likely to have experience with the fuzzier COSO controls.
PCI-DSS is an industrywide joke; it's a checklist audit performed by race-to-the-bottom consultancies, which have invariably PCI-certified all of the most egregious payment card breach shops since PCI was standardized. Ironically, as bad as PCI is, it's the controls standard that has probably had the most practical impact, because of how prescriptive it is, and how rote the audits have become. Its impact is still malign!
Agree 100% with this and your other comments. These frameworks often create risks by obscuring reality behind procedure. Sucking up all the air that would go towards more direct security objectives. Businesses think they are done with cybersecurity because they are done with the checklist. Believing we are safe because a non-technical auditor said so, can be a risky spot. Specially if that is used to overrule subject matter experts.
> PCI-DSS is an industrywide joke; it's a checklist audit performed by race-to-the-bottom consultancies
We ended up with a consultants from a former Eastern Europe country that charge less per hour then local cashiers make (which is NOT a statement to the quality of said consultants).
I (irregular) deal with PCI-DSS and never ever felt so close to quit my job and become a full time lawn mower.
Worked at a bank for years. So many things we wanted to do to really get our firewall policies modern and more actionable for the SOC. Layer 7 enforcement, user-based policies, deduplication of rules, more aggressive cleanup.
Things needing to be done a certain way for the auditors was a major hamper in our processes.
I'm now consulting and I have seen people do changes to their policies in such strange ways because they have to jump through ridiculous hoops for their industry regulator.
Yes. I've come to believe that much of the skill involved in doing security compliance work is in managing (strangling) down the scope of the framework, and almost none of it is in using the framework to inform and improve real security practices. This is what I mean when I keep saying here that these frameworks are not a "good first step". If you don't actually have to engage with them, because your customers aren't demanding it, you should actively avoid them and use that precious time to build a real security practice.
Yeah, this entire website is a pretty clear ai content farm. From the stable diffusion profile images to the twitter with 27k followers and no engagement.
We can tell how good these cybersecurity frameworks are by seeing how hard it is to breach the organizations certified at the highest levels such as SolarWinds [1], Equifax [2], Trend Micro [3][4], Cisco [5], and so many more.
It is so utterly ridiculous that anybody cares about these standards when literal clown shows get full marks.
The sign of a good standard is one that effectively and accurately predicts outcomes. A standard can be validated experimentally by evaluating if the certified targets conform to the stated predictions of the standard. A standard that fails to discriminate between good and bad is useless and the results of such certifications can be safely ignored.
The vast majority of cybersecurity frameworks have failed in these respects. Basically, if a standard gives Microsoft top marks, it is a lousy standard. That is not a necessary condition, but it is certainly sufficient along with anything certifying plenty of other security messes.
Having worked performing assessments against these frameworks and standards. The important thing people need to know particularly for NIST, is that you could have a clean bill of health today. But if one or two of your controls fails tomorrow, then you may run into trouble.
NIST isn't a maturity framework, it doesn't tell you that you need x control in place to be x level of maturity. It gives you control objectives that you need to design and operate effectively over time.
You might have a great set of controls across penetration testing and vulnerability management today, but if you fail to perform one of these controls tomorrow you will be vulnerable.
For example, I have performed controls assessments against organisations that have implement CIS controls. I have seen more often than not, CIS controls not being fully implemented as per the wording of the control AND the control not having been performed appropriately.
This is where using a cyber security standard and obtaining controls assurance is very important.
The fundamentals of these frameworks are not inherently bad. The main problem is that they are treated as the checkbox solution that should be implemented regardless of context.
If you take your IT security work seriously you will in most cases already fulfill the requirements stipulated in the frameworks, and if you are setting out to get started with more structured approach they are a good place to start.
What cannot be understated however is the need for context, IT security is a set of choices that determine where you will have exposure and those business risk. For any business these will be different, as regulation and value creation differs. Exactly as any other risk management, but for some reason this does seem difficult for most to understand.
51 comments
[ 3.0 ms ] story [ 111 ms ] thread(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.
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.
Everyone here is correct that you need more than just these frameworks/audits to be secure. However, most companies that are secure following these frameworks. If you're secure, these frameworks are a no-brainer to certify against.
I've gotten into breathless arguments with "cyber experts" who really don't understand this simple point. I've met people in industry who literally think that "filling out the paperwork and having a risk committee accept risks or prioritize a schedule to get into compliance" equals "our systems are now secure".
It's a massive self-serving industry incentivized to enrich itself and not secure systems. If they were successful at designing, deploying, and maintaining secure systems, there wouldn't be an industry.
On the other side of the coin, if a vendor does not have paperwork and evidence to support their programs - how does one as a purchaser or security reviewer verify? Organizations only act truthful to an extent that benefits them. Quality of audits and supporting paperwork is a real mixed bag. Unless you’re an Amazon you’re not going to get the chance to audit your vendors and sub processors outside of reviewing this type of documentation.
The entire process is broken.
That's where the value stops - once you give lawyers, policymakers, and insurance companies access to these documents it becomes an unending game of regulatory capture, responsibility derogation, and box-ticking.
You end up with people who have zero context for technology running around demanding to see evidence that your smart toaster implements 12.2.14.1.5b "The centralized time server must enforce separation of duties" before it can be added to the network or some other such incoherent nonsense.
These standards always start in the right place, but they get used in the most frustrating ways because people who don't understand how technology works are, invariably, the auditors and assessors who apply these standards since true technologists can easily find more gratifying jobs doing literally anything else.
Yeah, I'm self taught on this stuff, but I've started to think that's not all bad. I literally downloaded every one of the NIST 800 series, the FIPS series, the CNSSIs, all of it, and went through everything to figure out what connected with what. Most of it is pretty damn obvious. You should secure your internet-facing servers, sanitize inputs, never hold actual passwords in a database, use some form of 2FA, etc.
But there are a lot of dudes with degrees in "cyber-something" or "IT something" who lord over me with their government-bestowed positional authority (I'm just the clinical informatics physician with an undergrad in physics from a top school and teach machines to diagnose disease, trying to deploy things to actually save lives, so what the fuck could I possibly know about the dark arts of cybersecurity? "Oh, god, here he is talking to us about numbers again, borrrringgggg. I bet he's going to ask us when the GPUs are going to be on contract. Again. Like, bro, we'll get to it. Later.")
Come to find out a lot of these fuckwads speed-click through their ATO checklists. Shockingly, the timestamps on the checkboxes are all on the Thursday afternoon before the Tuesday "surprise" inspection that happens the same week of the year every time, run by the guy who they used to work for at the last gig.
And then the guys actually trying to get shit done get drowned by the 50 fucking drones who all show up to the weekly meetings and pipe up with their 30 seconds worth of input. And the guy trying to actually deploy product spends the rest of the week establishing that the drone didn't actually know what the fuck was going on in the meeting and just blurted something out at the appropriate moment, relying on the last 30 seconds of banter to guide his statements.
Not that I'm bitter or anything...
Fatalism and cynicism are comfortable because they don't ask you to do anything.
Cynicism is ultimately resigned consent.
How many security professionals here have actually sent a thought out letter to their congressperson or the NIST directly? How many people who express the negativity in this thread have tried to e-mail someone in a position of institutional authority or a tech related think tank? How many people have given government service a try? How many people have waited for a security catastrophe and then e-mailed someone who might be able to change policy? How many people have looked up a law and tried to reverse engineer who wrote it and who can influence it?
How many people have tried and failed?
When everyone thinks like yourself, it becomes a self fulfilling prophecy.
ISO 27001 = Not super familiar with this one.
COBIT = The management/process focused version of NIST CSF. Great if you have an executive suite CTO, CISO, CRiskO, CPrivacyO, and want to coordinate their efforts in a program that divides responsibilities among them and associated committees. Includes maturity modeling, which gives it a +1, but it is distant from anything technology related. Instead, it is all about which committees should be formed to decide on risk management strategies etc...
PCI-DSS = You'll do this one because VISA makes you do it. Much more actionable than NIST or COBIT, but it depends on the third-party auditor who is issuing your attestation of compliance. "Your label maker has it's default password?" = audit finding.
CIS18 Controls = The most actionable/lightweight framework now that they have incorporated maturity levels (aka implementation groups). Not as thorough as NIST or COBIT. Well implemented, CIS18 is enough for most organizations provided they do not have a specific security standard or requirement in their industry.
27001 is Euro-SOC2. Technically, 27001 is a certification, and SOC2 is just an attestation --- there is an external ground truth that 27001 is matching security programs to, where SOC2 is just validating internal consistency. But the subject matter is the same and they're generally thought of as equivalents for each other, with 27001 being the more rigorous.
Ironically, COBIT is the IT-focused equivalent of COSO --- in other words, it's the ostensibly more technical set of controls. But SOC2 keys off of COSO, and is audited by accountants, so practitioners are more likely to have experience with the fuzzier COSO controls.
PCI-DSS is an industrywide joke; it's a checklist audit performed by race-to-the-bottom consultancies, which have invariably PCI-certified all of the most egregious payment card breach shops since PCI was standardized. Ironically, as bad as PCI is, it's the controls standard that has probably had the most practical impact, because of how prescriptive it is, and how rote the audits have become. Its impact is still malign!
We ended up with a consultants from a former Eastern Europe country that charge less per hour then local cashiers make (which is NOT a statement to the quality of said consultants).
I (irregular) deal with PCI-DSS and never ever felt so close to quit my job and become a full time lawn mower.
Things needing to be done a certain way for the auditors was a major hamper in our processes.
I'm now consulting and I have seen people do changes to their policies in such strange ways because they have to jump through ridiculous hoops for their industry regulator.
https://owaspsamm.org/blog/2020/10/29/comparing-bsimm-and-sa...
It is so utterly ridiculous that anybody cares about these standards when literal clown shows get full marks.
The sign of a good standard is one that effectively and accurately predicts outcomes. A standard can be validated experimentally by evaluating if the certified targets conform to the stated predictions of the standard. A standard that fails to discriminate between good and bad is useless and the results of such certifications can be safely ignored.
The vast majority of cybersecurity frameworks have failed in these respects. Basically, if a standard gives Microsoft top marks, it is a lousy standard. That is not a necessary condition, but it is certainly sufficient along with anything certifying plenty of other security messes.
[1] https://www.schellman.com/certificate-directory?certificateN...
[2] https://www.oxebridge.com/emma/equifax-held-iso-27001-certif...
[3] https://www.bleepingcomputer.com/news/security/trend-micro-f...
[4] https://www.trendmicro.com/en_us/about/trust-center/complian...
[5] https://blogs.cisco.com/tag/iso-27001-certification
What is true is that if you do very little on them, you are much more likely to be hacked.
NIST isn't a maturity framework, it doesn't tell you that you need x control in place to be x level of maturity. It gives you control objectives that you need to design and operate effectively over time.
You might have a great set of controls across penetration testing and vulnerability management today, but if you fail to perform one of these controls tomorrow you will be vulnerable.
For example, I have performed controls assessments against organisations that have implement CIS controls. I have seen more often than not, CIS controls not being fully implemented as per the wording of the control AND the control not having been performed appropriately.
This is where using a cyber security standard and obtaining controls assurance is very important.
If you take your IT security work seriously you will in most cases already fulfill the requirements stipulated in the frameworks, and if you are setting out to get started with more structured approach they are a good place to start.
What cannot be understated however is the need for context, IT security is a set of choices that determine where you will have exposure and those business risk. For any business these will be different, as regulation and value creation differs. Exactly as any other risk management, but for some reason this does seem difficult for most to understand.