I recently received a message in my inbox from a vendor (note the use of the word “mandatory”):
"Are you all caught up in the third ISO 27001 edition which introduces new mandatory controls regarding threat intelligence."Is it really mandatory?
Too often people confuse the guidance that standards provide with what is mandatory. Too often vendors use a new line in standards guidance as a catalyst for new sales. Regardless of the source of this mis-information, you should always be on your guard. Even I was caught for a moment by the request above. “Was there a change…have I not kept up with the latest version…am I getting too slow to track all these things?” Happily, none of these questions are true, but it took a moment to figure that out.
Let’s give you some tools to help you answer these questions quickly.
Is it a standard or is it a guideline?
I find this question to be the most telling, and ISO is a great example. In a fantastically informative conversation I had over a decade ago with the lead of the working group for ISO 27001, I was told how many times she had to correct people that ISO 27001 was the standard, and that ISO 27002 was a guideline framework (my italics) to help understand the potential scope of their security program (ISMS). ISO 27002 was not meant as a mandatory set of controls, but rather to help people see how far and wide security controls could go, what was possible, and what they should consider.
When I received the email I quoted from at the top of the post, I did a quick check of ISO 27001. No mention of threat intelligence. I checked the link they included in their email, and it pointed to ISO 27002. Problem solved. It was not mandatory. Not by any stretch of the imagination. Was it a good practice? Yes. Was it mandatory? No.
Save the argument that everyone should have threat intelligence. I’m not saying people should not. I am saying it will look vastly different to different people. Big banks may want deep intelligence across their company and across the globe. A small company may just want enough to keep their systems patched. ISO 27001 mandates a risk-based approach that prioritizes efforts where they create the greatest risk-returns. It does not mandate that you do that through threat intelligence.
What is the intent?
I regularly find people dropping reference to Sarbanes-Oxley in reasoning for controls, or justification for blocking a modernization effort. I ask them to read the intent of the regulation or standard they are referring to. In the case of Sarbanes-Oxley it is to provide assurance of the controls over financial reporting. It has little to nothing to do with choices about how to modernize your applications or infrastructure, unless that intent is to eliminate all controls. In fact it has been repeatedly proven that companies can maintain Sarbanes-Oxley compliance without IT controls. Its hard, its not pretty, and I wouldn’t recommend it, but it can be done. Using a regulation as a bludgeon to stop an otherwise useful activity is the wrong approach.
Make sure you know the intent. If you focus on controls that give you assurance that the financials are accurate, then the rest is immaterial. If you focus on accounting controls, controls for data integrity, and prevention of inappropriate change to data, then you probably have Sarbanes-Oxley locked up. If someone uses Sarbanes-Oxley to stop an infrastructure modernization program, or as a criteria for stopping going to public cloud, they probably have no clue what they are talking about. Ask them how the change affects control over the financials. The blank stare you get in response will tell you everything.
Can you achieve better?
This is the most contentious, but my favorite. Some standards (I’m looking at you PCI-DSS!) are highly prescriptive. They mandate specific settings and technology to the detriment to innovation and best practice. PCI-DSS for a long time has mandated password controls of:
- Require a minimum length of at least seven characters
- Contain both numeric and alphabetic characters
- Change user passwords/passphrases at least once every 90 days.
- Contain both numeric and alphabetic characters
Now, NIST has long since advised that changing passwords every 90 days is dangerous in that in promotes bad behavior such as writing down passwords in unsafe places, forgetting passwords, and making passwords too simple so they can be remembered. PCI hasn’t caught up yet. But what should you do if you can do better? What is you use SSH keys? What if you choose not to rotate them every 90 days? What if you use MFA on top of the SSH keys? What if you use biometrics? Can you change those every 90 days?
The obvious point being made here is that some controls can be improved upon and made better than a “good practice”. In defense of PCI-DSS (which I often like to kick) they do have a category of “compensating controls” that allows you to define things better than their standard. And from what I’ve seen so far, PCI-DSS 4.0 focuses on objectives over prescriptive control activities. How that settles out is still to be seen, but again, it takes us away from the silly view that something is “mandatory”.
Think Carefully Before Acting
For all these calls for mandatory, be cautious. It is an easy way to install Fear, Uncertainty, and Doubt. It should not be that way, but it is human nature to illicit an illogical reaction. (Ah biases). Take your time, think it through. Is it a guideline or is it mandated in the letter of the law? Is it fulfilling the intent, or is the intent really in some other area? Is the requirements the best you can do, or can you do better? Only you as the owner of security can answer these. Do consider them carefully before making a rash decision that otherwise might ruin your budget for the year.
