The Muddled State of Security Standards

Posted on by John Linkous

One of my favorite quotes—attributed to either Admiral Grace Hopper or computer science professor Andy Tanenbaum—goes something like this: "The nice thing about standards is that there are so many to choose from." It’s true in the information security world, too.

Standards, Standards Everywhere!

Let’s first settle what we mean by security standards. There's no shortage of recommendations on how to secure networks and systems, and on how to properly manage an entire information security program.

Laws such as HIPAA and SOXcontain information security components. Generally speaking, these laws don't have details, and they're highly specific: designed to protect one type of data (HIPAA) or a business process (SOX). Industry mandates, such as the Payment Card Industry Data Security Standard (PCI-DSS) and the NERC Critical Infrastructure Protection (CIP) standards, provide detailed guidance for information security. They may not carry the weight of a law, but are still considered mandatory for certain industries., These mandates are also focused on protecting a certain type of data (cardholder data in the case of PCI DSS), or are designed to fit an industry’s unique requirements (industrial control systems, in the case of NERC CIP).

None of these are really standards. 

A security standard is a standard if its intent is broad: It can be used by any organization in any industry vertical and is not specific to a particular technology or business function. Security controls frameworks such as ISACA’s Control Objectives for Information Technology (COBIT) provide big picture standards. . While COBIT is not originally specific to security, ISACA released a security controls-focused add-on document to COBIT in 2012. Another major framework standard is ISO-27001 (currently in its 2013 release), developed by the International Organization of Standards (ISO), and the most widely-adopted information security-specific controls standard. The US federal government, through the National Institute of Standards and Technology (NIST), developed NIST Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and Organizations. Although originally developed out of the federal government agency-focused FISMA law in 2002, NIST 800-53 provides perhaps the most detailed guidance available on general information security controls, and ties it all together nicely with a great risk model.

There are other, more comprehensive standards such as the Center for Internet Security (CIS) benchmarks, which provide detailed, system-specific, and cooperatively-developed secure configuration guidance. There are also DISA STIGs, which are the US Department of Defense's version of detailed system-level security configuration guidance.

"Choose . . . But Choose Wisely"

Two issues plague security standards today: scope, referring to what the standard applies to, and prescriptiveness, referring to the depth of information provided in the standard. Fortunately, the scope problem is easy to solve. While high-level standards such as ISO, NIST, and COBIT can help guide the overall security program, there's nothing that prevents them from being used in conjunction with low-level, detailed standards such as CIS benchmarks and DISA STIGs.

The prescriptiveness problem is a bit more tricky. For example, we can all agree that antivirus software is a good thing, and should be part of any sane defense-in-depth security strategy. But each security standard has a different take: One standard may simply say, "You need to install anti-malware software on each server and workstation." Okay, fair enough. Another standard may state, "You need to install antimalware, and ensure that signature files are up to date, and review the results periodically." Other standards—such as the CIS benchmarks or the federal government's DISA STIGs—are even more prescriptive, and either provide detailed guidance on how anti-malware agents should be configured (in the case of CIS benchmarks), or require specific brands of software to be installed for anti-malware (in the case of the DISA STIGs). From an assessment perspective, this ambiguity makes it difficult to develop standard auditing criteria to determine the true state of risk exposure.

Where We Go from Here

We all know how successful cyberattacks have been in recent years, so the need for security standardization is self-evident. However, finding a legislative solution to the problem has proven problematic. Of the 14 bills introduced this year directly relating to cybersecurity standardization, none have made it out of committee. There is also a greater focus on information sharing rather than mandating processes and controls.

So what's the future of information security standards? It's difficult to say. The adoption of new standards—especially less prescriptive, generalized security control standards—is only going to muddy the waters of reducing risk, which is the real reason we have these standards in the first place. It will be a problematic balance to achieve.

John Linkous

, Technology Advisor

risk management legislation

Blogs posted to the website are intended for educational purposes only and do not replace independent professional judgment.  Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA® Conference, RSA Security LLC or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community