The ISO 27001 standard may be the closest there is to a gold standard in the security world. Vendors of various industries pursue their ISO 27001 certificate to secure business deals that they would not otherwise get. Large corporations with ambitious CISOs make it their career goal to achieve full compliance and certification. Big 4 auditors swear only by it and use it to evaluate a company security maturity. Even other renowned security certifications require knowledge of the ISO 27001.
But…
A company can tick all 140-ish controls, yet succumb to regular privilege escalation, lateral propagation and infrastructure compromise using run-of-the-mill hacking techniques.
I am not making this up. Ask any pentester, or simply follow up on the plethora of cybersecurity intrusions.
So what gives? Why did I dunk on it in my previous post, and more importantly, why does it never succeed in stopping a pentester/hacker/attacker from pwning the infrastructure in a few hours ?
This post is my attempt at rationalizing this glaring discrepancy between what the standard claims to achieve and what happens in the field.
What’s wrong with the ISO 27001?
Let’s start with the most annoying aspect of the ISO 27001. The list of controls is behind a paywall that costs around $118. Yes, it’s peanuts for a corporation. But that’s not an excuse to rip everybody off.
Just as that feeling of frustration slowly morphs into acceptance—after all, few things are free in this world—it quickly spikes up again when one learns that at least two other standards are needed to properly follow the ISO 27001. The ISO 27002 which contains detailed recommendations of the one-line controls listed in 27001 and the 27005 that defines risk analysis. $198 and $178 respectively.
Fortunately, one can find many free versions online with a few Google search keywords.
Policies…policies everywhere
Perusing the 149 controls of the ISO 27001, one can’t help but draw a very dangerous and misleading conclusion: Policies, procedures and documentation are the bedrock of security.
Indeed, one needs a mobile device policy (A.6.2.1), a data classification policy (A.8.2.1), a policy for removable media (A.8.3.1), another one for handling secret authentication information (A.9.3.1), a secure log-on procedure (A.9.4.2), a procedure for data transfers (A.13.12.1) and so goes the list.
Reading these standards, the picture we get is that of a security team busy in its corner writing processes, procedures, and policies. Dumping this litany of documents on the lap of infrastructure admins, developers and other employees and waiting for them to act to respect these guidelines. It paints the image of a security team whose main job is to wave disproving fingers at other departments, often with the sole argument that “it’s not compliant with the ISO 27K1”.
They assess, they verify, they control…but they never really fix anything. Zero value added to the business.
What a flawed and depressing governance structure.
Furthermore, and I hate to break it to people, but a data classification policy never stopped an attacker from emptying an S3 bucket. We’re fighting technical prowess and expertise with the written word. It’s not war, it’s carnage.
Yes, it is essential to write down how a company addresses security, handles access controls and so on. It creates alignment between teams. But that’s merely 1% of the job! The bulk of it is implementing technical measures to enforce those policies.
Writing an access control policy is easy. It takes 8 hours at most. There are even free templates available online. The challenge is implementing these policies in a consistent and pragmatic way. It’s in hunting public non-authenticated access. Finding ways of securing them without hurting business or growth prospects. Putting in place technical controls to prevent and detect any new occurrences and so on.
Sadly, the standard conveys quite the opposite view… Policies and procedures at put on a pedestal. You can absolutely nail your 27K1 certification if you provide the right set of documents. Companies therefore spend fortunes debating policies, hiring expensive consultants to rewrite and calculate maturity scores. Meanwhile, their Active Directory is bleeding NTLM credentials in the field, where the actual war is waging.
Disconnection with reality
To paraphrase their introduction, the ISO 27001 is meant to help companies establish, implement and maintain an information security system. I remember when I first read their list of controls after a couple of years in the pentesting world. Something seemed awfully strange. I could not quite put my finger on it. The controls cover all accepted theoretical security concepts: encryption, access control, audit trail and so on, but something bothered me… Only hours later could I begin to really articulate it: I could not map these controls to what I had observed in the field.
Take a classic hacking scenario: clear-text passwords of an admin service account in a VBS script on a shared network drive. How can anyone ever extrapolate this type of vulnerability from the generic control “Management of secret authentication information of users” (A.9.2.4)? Intuitively, we know it’s related. But a security team looking to tick the A.9.2.4 control, will never, ever land on this vulnerability. They will dutifully follow the implementation guide in the ISO 27002 and make “users […] sign a statement to keep personal secret authentication information” before moving on to the next point. Meanwhile, their network drives, code base and other repositories are swarming with clear-text passwords.
The goal of security is and always was to fight attackers. What good is a security standard if it does not orient defenders toward the most glaring deficiencies exploited by attackers?
These controls are so broad that they approach astrological literature. A CISO that runs down the ISO 27001 list of controls will seldom converge to the flaws and vulnerabilities actually exploited by attackers. They will get the illusion of improving security by interpreting overly generic controls, but they’re not finding nor fixing the actual flaws exploited by attackers.
Subversion of the mission
Finally, the third and probably the biggest issue of the ISO 27001, and other similar standards for that matter, is that it supplants the goal it’s supposed to help achieve.
Take a CISO that wishes to address security in their company. They follow the 27005, perform a risk analysis, enumerate threats and important assets and come up with a plan to address them using 27001 controls. Say they decide to work on protecting databases from insider threat and choose to start with Access Control (9.2.2).
Reducing this risk in any meaningful way could imply putting in place a Single Sign On solution, extending it to different types of databases, handling edge cases, upgrading authentication libraries, reviewing and tightening access rights, migrating hundreds of apps and so on. Probably a 9 to 18 months series of projects.
Arguably, this is a reasonable risk-based approach. But our CISO would end up getting sacked in a year or two for failing to get their ISO 27001 certification. 18 months to implement a single control? Hell no, the company wanted that certification yesterday. The average lead time to getting certified is usually 6 to 12 months. That means 6 to 12 months to go over all the 149 controls, not linger on a single one of them… But again, no one scores the ISO certification because they lowered their risk profile. They get it first and foremost, because they implemented the maximum number of controls.
The company is therefore incentivized to privilege breadth over depth: generic and wide risk analysis over precise threat definition. Vague and hazy controls over focused and concrete actions. The goal quickly shifts from reducing risk exposure and thwarting attackers to finding clever ways of gaming the standard and ticking every little box.
The CISO would often just go alphabetically through the list of controls scribbling documents about the internal organization, project management, human resources and employee screening while their Elasticsearch is naked on the Internet and developers enjoy admin access to production databases and push hard coded secrets in the code base.
Then they hire a bunch of consultants to calculate the level of compliance of each control, assign meaningless ex post facto rationalized scores to each of them. The CISO, feeling more comfortable with numbers, starts shuffling medians and averages to determine their next course of action:“We only score 1.8 in incident management. What controls should we upgrade to reach an average of 2.4? I know, let’s write a procedure for reviewing our procedures”
Risk analysis? Yes, of course they have that, but it’s just another Excel sheet gathering digital dust on some analyst’s computer.
To sum up
I don’t have a particular beef against the ISO 27001, except for the fact that they make people pay hundreds of dollars to download their documents. I am even okay with it being marketed as a list of points and ideas to help reach exhaustivity.
But I maintain that it cannot be used a starting point to secure an environment, nor as a robust framework to structure and lead security efforts. It pushes the wrong approach to solving security issues, that of policy scribbling junkies that operate in a vacuum far away from the threats of the real world. It incentivizes people to completely ignore the attacker, their capabilities, and their modus operandi. Furthermore, it prones compliance with a bunch of abstract, overly generic concepts while the attackers are happily swimming in a sea of real vulnerabilities. Vulnerabilities that can never be deduced from the aformentioned controls.