Types of security frameworks

If you are here, reading this than I can assume you have questions.  Maybe you have just started your search and stumbled across this article, but it’s also just as likely you have been searching for a while and are not finding answers to your questions.  Either way, welcome!  This is my reasonable attempt to first detail the types of security frameworks and later explain why you might select one over another.

Let’s start off with a thought experiment, I want you to go and think about the first time you heard of a “security framework”.  It might have been in a textbook, it might have been from a boss at work or a coworker during lunch.  You hear, “security framework” and you think “Aha!  A framework, this is something I can easily digest because it’s a f-r-a-m-e-w-o-r-k".

Then you start searching. You find references on the NIST site to rev4 vs rev5, you find the SP 800-53 document and its…WHOA(!)…500 pages long. Maybe this isn’t the best way to learn about these frameworks.

So, what is the best way? Best, is of course very subjective, but I want to share with you a method of learning about these frameworks that helped me grasp the nuances of these frameworks.

Cybersecurity framework types

It helps to first sort security frameworks into similar categories, which will help you compare them to select the best fit for your organization.  First, you need to realize there are three main categories of security frameworks.

· Control Frameworks

· Program Frameworks

· Risk Frameworks

Alright, pause, hit the brakes…lets talk about this.  Why are there different categories?  The simple answer is because, every organization is different.  Some are just starting down their security maturation journey and others have been working on it for decades.  The control frameworks are usually the least difficult to adopt, followed by program frameworks.  Risk frameworks require a significant investment in enumerating and classifying risks unique to your organization, and for this reason are usually reserved for mature organizations (or those under intense scrutiny).

Control Frameworks

What is a control?  A control is nothing more than a specific piece of a security program.  If we look at the CIS Controls, we can get specific examples of a control. In this screen shot, we see a "sub-control" (now called a Safeguard) that tells you to create a process that ensures secure configurations are used.

Why is there a framework built around a set of controls?  Because controls are easily understood, making them easier to adopt.  Assemble several controls together, and bingo! You have a framework.  I don’t want you leaving this section thinking the ease of adoption makes control frameworks any less effective than program or risk frameworks.  That would be a mistake. Control frameworks, like the CIS Controls, and NIST 800-53 are very effective.

Program frameworks

Program frameworks, while more difficult to adopt and implement than a control-based framework, does have a clear benefit.  Not only do you get a tangible “program” that you can point to if someone asks, but you are able to clearly and simply articulate your current security state to your leadership.  This is an area where we, in cybersecurity, often fall short.

Visibility from the top down into the cybersecurity efforts is critical to ensure not only the success of the program, but to also ensure proper relationship building and maintenance is occurring.  “Hey Chris, what the heck man, this is a blog post about security frameworks!”  Yeah, yeah, I know…but never lose sight of the fact that we exist to enable the strategic objectives of your executive team (leadership). You want accolades and easy budget approval?  Make it easy for your leadership to see how effective your security team & program is.

Common program frameworks include the NIST CSF & ISO 27001.  ISO 27001 is an internationally recognized standard, so if you’re reading this and have concerns that lie outside of the US, this is probably going to be your program framework of choice.  ISO 27001 is also the program that gives you an ISMS, or information system management system. Emphasis on system, because that’s what it is.

NIST CSF is best thought of as a life cycle of security management.  Picture a loop, you start at “A”, progress to “B”, “C”, “D” and finally step “E”.  It prescribes to you a plan to follow to ensure you are successful in your adoption of the NIST CSF.  For this reason, it is very popular because it makes your life easier if you are new to security frameworks.

Risk frameworks

Building on the foundation that is often created by Control and Program frameworks, an organization will determine they require a Risk based security framework.  But why?  Why would an organization take on the significant burden of adopting a risk-based framework? Not just the burden of adoption, but the increased management costs associated with risk-based frameworks?

Because they have a problem:  Their controls and programs have identified dozens, hundreds or thousands of vulnerabilities, misconfigurations, gaps and so forth.  They require a solution to this problem.  The solution is a risk-based framework, that will help them prioritize the vulnerabilities identified in other programs.

Frameworks like the ISO 27005 and the NIST 800-39 provide the methods needed to create a process to manage your risk.  Under NIST 800-39 there are other special publication (SP) that include 800-37, which is the risk management framework, and 800-30 which is the risk assessment process.  Both 800-30 & 800-37 are a sub-component of 800-39.

There is an incredible amount of nuance that goes into understanding these frameworks, more than I can fit here in this article.  I will have to save that for another day, but before we leave this topic, I must mention use of the FAIR model.

FAIR stands for Factor Analysis of Information Risk, it is an open and internationally recognized standard for measuring risk. The FAIR model is a method to QUANTIFY cybersecurity risk, which is critical because neither the ISO 27005 nor the NIST SPs mentioned above define how to measure risk (quantitative or qualitative).