Which security framework is right for you?

One of the problems that cyber security stakeholders face is the overabundance of tools and processes. Just Google “firewall providers” and you are deluged with information; replace firewall with any other tool (anti-virus, phishing simulation, intrusion detection system, and the like) and the results are similar. This is true for processes as well, albeit on a smaller scale, as represented by the proliferation of security frameworks. Below are some of the more popular frameworks, but this list is by no means exhaustive.

• NIST (National Institute of Standards and Technology) CSF (Cyber Security Framework),
• HITRUST CSF
• ISO (International Organization for Standardization) 27001
• COBIT (Control Objectives for Information and Related Technology) 2019
• PCI (Payment Card Industry) DSS (Data Security Standard)
• CIS (Center for Internet Security) Top 20
• CAIQ (Consensus Assessments Initiative Questionnaire)

Framework is defined as “a basic structure underlying a system, concept, or text.” Therefore, a security framework can be considered the building blocks of your organization’s security program. A framework should theoretically make planning and implementing security easier, but with so many to choose from, how can you truly know which one is right for you?

This is a question we often hear from our clients. The answer (often frustratingly to them) is, “it depends.” As I've argued before, the concept of “just right” security is highly dependent on the needs of your organization. In a nutshell, choices around security and security frameworks are driven by business needs; since business needs vary across organizations, so should the choice for the right security framework.

A closer look at popular security frameworks

Back in 2016, Tenable conducted a survey to determine the adoption of security frameworks across organizations in the US. It found that as many as 84% of the respondents were already using a security framework, with PCI DSS being the most popular, not surprising taking into account how common online shopping and electronic payments are in today’s world.

PCI DSS compliance is a necessary prerequisite for organizations that process, transmit, or store payment card data branded by Visa, MasterCard, Discover, American Express or JCB; it also pertains to organizations that indirectly impact the security of this data.

The popularity of the second most common security framework, NIST CSF, is quite evident from the Cyber Security Reviews we conduct for our clients. In spite of our assessment methodology being adaptable to different control frameworks (ISO 27001, CIS Top 20, CAIQ, NIST CSF), 80% of our clients request they be assessed using the NIST CSF. While difficult to ignore, a framework’s popularity should not drive your decision. With so many frameworks out there, categorizing them can help understand fitment with organizational needs.

Program frameworks. Help to determine the current state of security maturity in the organization, define a target future state, and build (and manage) a strategic program to get there. Risk and controls frameworks are often included an umbrella program framework. Examples include ISO 27001, NIST CSF, COBIT 2019.

Risk frameworks. Help to identify, measure, and respond to applicable risks or uncertainties to business as usual. They are usually leveraged after establishing the security function in an organization. Examples include ISO 27005, NIST SP 800-30, FAIR.

Controls frameworks. Help to develop a minimum security baseline and prioritize the implementation of security measures as part of a tactical roadmap. Ideally, controls implemented should address risks identified using a risk framework. Examples include ISO 27002, NIST SP 800-53, CIS Top 20, CAIQ.

Compliance frameworks. Help to confirm specific regulatory or business requirements and have significant overlaps with the previous three kinds of security frameworks. Examples include PCI DSS, FIPS 200, FedRAMP, HIPAA Security Rule.

Depending on business needs, an organization may end up choosing one framework from each of these categories, or more. For example, consider a cloud services company. If the company accepts credit card payments, it has to comply with PCI DSS. If a major client requires the company to be ISO 27001-certified before renewing the annual contract, then ISO 27005, ISO 27002 and ISO 27001 may be leveraged to meet this pressing business need. Now, if the company wants to provide cloud based services to US government entities, it has to comply with FedRAMP requirements.

Guidance for adopting security frameworks

1. A framework should be chosen based on business needs, not on what’s currently popular.
2. A framework does not have to apply for the entire organization. For example, while PCI DSS may be required for the cardholder data environment (CDE), it may not translate well for the entire organization that may very well be served better by ISO 27001.
3. A framework is meant to provide guidance and should not be followed blindly. While there maybe compliance requirements that must be met, often there are nuances around what’s applicable to a particular organization and what’s not. A risk assessment can help determine what’s what.
4. A framework doesn’t exist in isolation, there are often significant overlaps with other frameworks. Some organizations are so caught up in adhering to multiple frameworks that they burn time and effort in reporting against them individually. Ideally, a core foundational program and processes should be leveraged with crosswalks across multiple frameworks to allow for maximum coverage.