Making the Most of the NIST Cybersecurity Framework

June 17, 2019 • Zane Pokorny

The NIST Cybersecurity Framework has become a valuable tool for evaluating security across a variety of business sectors. Originally published in 2014 and targeting critical infrastructure, the framework continues to evolve to meet the changing needs of organizations in the U.S. and around the world. Its popularity stems from its thoroughness, applicability, and approachability.

Our guests today are Ken Durbin, senior strategist for global government affairs and cybersecurity at Symantec, and Allan Liska, senior solutions architect at Recorded Future. They’re going to walk us through the NIST Cybersecurity Framework and help us understand how to make the most of it within our own organizations.

This podcast was produced in partnership with the CyberWire.

For those of you who’d prefer to read, here’s the transcript:

This is Recorded Future, inside threat intelligence for cybersecurity.

Dave Bittner:

Hello everyone, and welcome to episode 112 of the Recorded Future podcast. I’m Dave Bittner from the CyberWire.

The NIST Cybersecurity Framework has become a valuable tool for evaluating security across a variety of business sectors. Originally published in 2014 and targeting critical infrastructure, the Framework continues to evolve to meet the changing needs of organizations in the U.S. and around the world. Its popularity stems from its combination of thoroughness, applicability, and approachability.

Our guests today are Ken Durbin, senior strategist with Symantec global government affairs, and Allan Liska, senior solutions architect at Recorded Future. They’re going to walk us through the NIST Cybersecurity Framework and help us understand how to make the most of it within our own organizations. Stay with us.

It’s great to have both of you with me, Ken and Allan. I want to start, Ken, since our audience has heard Allan a few times, I’d like to spend a couple of minutes getting to know you first. Could you just give us a little overview of what your career journey has been like?

Ken Durbin:

Absolutely. So, I’ve been focused on the federal space for the majority of my career. It’s been in different disciplines along the way, but ultimately over the last 10 years, I’ve landed on compliance and risk management issues and more recently have branched over into the privacy arena.

Dave Bittner:

And of course, Allan, we’re familiar with you and the work you do at Recorded Future. What’s your official position there these days?

Allan Liska:

I’m senior solutions architect at Recorded Future.

Dave Bittner:

All right, terrific. Well, Ken, today we wanted to talk about the Cybersecurity Framework. Why don’t we just start off with some high level stuff here. For those who might not be familiar with it, can you describe, what are we talking about here?

Ken Durbin:

So, the NIST Cybersecurity Framework was born out of an executive order about six years ago, and it was designed to give critical infrastructure sectors a tool to analyze and improve their cybersecurity posture. The concern was that they may not be as robust as needed to meet today’s threats.

So, the executive order specifically spelled out that NIST has one year to do this, and they were to do it in collaboration with industry. They had to do it in one year and they got it done. So, what they produced is commonly called the Cybersecurity Framework, its official title is the Framework for Improving Critical Infrastructure Cybersecurity.

Dave Bittner:

How sentimental.

Ken Durbin:

Exactly. Another interesting point while we’re at it, everybody refers to it as the NIST Cybersecurity Framework except for NIST, they consider it to be industry’s framework and they were just facilitators of it.

Dave Bittner:

Interesting. That’s kind of a comfort. Nicely humble of them I guess.

Ken Durbin:

Well, it did acknowledge the work that industry put into helping with the development of it.

And additionally, it was meant for critical infrastructure, but because of its ease of use and effectiveness, it quickly made it popular with organizations of all shapes and sizes. So, pretty successful effort from NIST and industry.

Dave Bittner:

Well, let’s walk through what it’s all about. Can you take us through the various elements?

Ken Durbin:

Sure. In a nutshell, it helps an organization determine what their current cybersecurity capabilities are and then you need to, using a risk assessment procedure, determine if those capabilities are adequate for what your business or mission goals are.

If they’re not adequate, then the Framework also helps you to decide what changes should be made to improve the cyber capabilities and then to monitor your progress along the way. It’s a very simple framework. There’s only three key parts to it. There’s the Framework core, profile, and tiers, and if you don’t mind, I’d like to go through each one.

Dave Bittner:

Yeah, let’s dig into them.

Ken Durbin:

Great. So the core, as its name suggests, is at the heart of the Framework, it’s divided into five main functions. They’re called identify, protect, detect, respond, and recover. Each one of those is then further subdivided into categories and subcategories, and by the time you get to the subcategories, those five functions have now ballooned into 108 subcategories, and it’s the functions that help guide you through what your capabilities are.

I mean, if you just think of the names of the functions alone, if you just talk about those names, it tells you a lot about your cybersecurity capabilities. First, identify, “What is it I’m trying to protect?” Protect is, “What protections do I have in place to actually do that?” Nothing is 100 percent successful, so you have to have the ability to detect when something makes it through?

Once it’s detected, do you have the ability to respond to it, and then ultimately, do you have the ability to recover and get back to normal business operations? So, you can see just at that level, you can have a pretty meaningful conversation with somebody about their cybersecurity capabilities.

Dave Bittner:

Let’s move on, can you describe to us the profile?

Ken Durbin:

The profile, I like to refer to the profile as the way you interface with the core. So, you start with subcategory number one and you ask yourself, “Is this outcome important to my business, or mission needs?” If it is, “Do I have something to address it?” If I do, “Is it adequate?”

Then you ask yourself that question for all 108 subcategories and at the end of it we have what’s known as a current profile, or what my current cybersecurity capabilities are. Then you do a risk assessment against that, determine what changes need to be made, document those changes, and now you have your target profile, “What it is I’m trying to achieve.”

The delta between those two becomes your roadmap from getting from point A to point B. So, that’s how you interface with the core itself.

Allan Liska:

And one of the things that I really like about the Framework is that it allows you as an organization to sort of set goals for yourself and map them out in a clear way. We’re here now, we’ve had an honest assessment, this is where we are, these are the steps we need to take to get to this point. So, it allows you to be aspirational in improving your security based on your goals and what you hope to achieve.

Dave Bittner:

Well, Ken, let’s move on and talk about the tiers then.

Ken Durbin:

Okay. The tiers sometimes are misunderstood. There are four tiers in the Framework, tier one through four, and they’re defined as: Partial, risk informed, repeatable, and tier number four is adaptive. It helps an organization measure their overall capabilities in three areas: Their ability to follow a risk management process, how integrated the risk management program is, and then what level of external participation are they engaged in? And as you go up the tiers, those abilities get more robust and people like to look at the tiers as a maturity curve.

That if I’m a tier two, I have to get to a tier four, and that’s not necessarily the case. They set them up as a way to give you a guide, figure out where you are. If that’s acceptable for your business, or mission needs, that’s fine, you don’t need to go any further, but if you do, then it helps you plan how to get there. They do say if you’re a one, you should probably focus on getting to a two, but not everybody has to get to a four.

Dave Bittner:

Now, I’m curious, Allan, as you’ve seen this adopted throughout the industry, am I correct in my assessment that it’s been a very positive reception?

Allan Liska:

Yeah. Overall, and I think Ken hit on this perfectly, while this was originally intended for critical infrastructure, it’s actually seen much wider adoption beyond that intended audience, simply because it’s something that’s easy, it’s measurable, and it’s repeatable across all industries.

So, there’s nothing industry-specific about it, and the goals and the guidelines are broad enough that you don’t have to worry about having specific equipment, or specific types of security, or a specific level of staff in order to be able to meet the goals that are outlined here.

Dave Bittner:

Yeah, it’s interesting to me that I suppose even if you’re not under any sort of regulatory requirements, that just going through this as an exercise with the approachability that it seems to have, well it’s going to be time well spent.

Allan Liska:

Sure. I mean, if you go to the board, your board of directors, and the board says, “What’s our security posture?” Which is something that’s being asked more and more often, this gives you a quantitative way of analyzing where you stand as far as your security readiness, compared to where you could be, and then be able to justify.

As Ken said, you don’t necessarily need to be able to jump to a tier three, or tier four, but you can at least then explain, “Okay, here we meet all these requirements for a tier two and this is good enough based on our risk profile for these reasons.”

Dave Bittner:

Now Ken, from a practical point of view, does this allow people to set a level to compare themselves with other organizations?

Ken Durbin:

That is actually one of the goals that gets missed quite a bit from the Cybersecurity Framework itself. It’s a way to compare apples to apples. So, you mentioned a regulatory situation before. So, if you have somebody that is with the government and they use the Risk Management Framework and they use FISMA, and you want to talk to somebody, let’s say, the power utilities, and they’re using the NERC, FERC controls, it’s difficult to have a conversation.

But since both of those regulatory frameworks map into the Cybersecurity Framework, if they both do that, now they have a common language where they can sit and have conversations about, “Well, what are you seeing in this area? How are you improving this area?” So, it helps create that level of conversation.

Dave Bittner:

Yeah, I’m curious too, I mean, can people come at it from the other direction? I’m thinking for example, could an insurance company who is looking to evaluate how well a company is doing in an effort to provide them with cyber insurance, could they look at this and say, “Well, how are you doing relative to the NIST Framework?”

Ken Durbin:

Yes, the insurance companies were looking at this since its adoption. Every now and then you hear more activity about the insurance companies using this as a way to baseline for cyber insurance. It kind of ebbs and flows, but absolutely, that has been a focus.

Let’s use this as a baseline to see what your capabilities are and then that helps set the rates based upon how prepared they are to handle a cyber event.

Dave Bittner:

Well, let’s talk about how it is related to threat intelligence. Are there areas where threat intelligence comes up within the Framework?

Ken Durbin:

That’s why I was excited about this podcast, because it does give us an opportunity to address where threat intel plays, because if you look at the way the Framework is written and you do just a word search on the PDF document, you find that threat intelligence only comes up twice.

It comes up in the description of one of those subcategories that we talked about. It’s a subcategory under identify risk assessment and then it’s also mentioned when you get to tiers. So, each of those tiers I told you was broken up into three parts, one of them is external participation.

Well, threat intelligence is a measure of your external participation. Now, that’s not to say that the Framework is saying that threat intelligence isn’t needed, it’s just not spelled out as well. It’s implied, but it’s not expressly stated, “This is where threat intelligence is going to help you within these certain functions and categories and subcategories.”

Dave Bittner:

And so reading between the lines then, where are the places that it fits in?

Ken Durbin:

So, it fits in in multiple areas. First off, we mentioned the tiers, and so as you go up the tiers, your interaction with threat intelligence gets more ingrained into your organization and their cybersecurity capabilities. So, there’s that, but then if you look at the functions again and the names of the functions, if you look at protect, detect, and respond, you can almost ask yourself the following question: “I protect against what?” To answer the “against what” part, threat intelligence helps you with that. When you hear “detect” and you say, “Okay, detect what?” That also implies threat intelligence, and then with “respond” “Respond how?” That can lend itself towards threat intelligence, and then there are specific examples within each one of those functions.

Dave Bittner:

Yeah. Well, I want to dig into some of those, but before we do, Allan, I’m curious for your take. How do you approach the Framework from your position, the work you do every day with threat intelligence?

Allan Liska:

Well, and I think Ken kind of hit the nail on the head that while threat intelligence isn’t called out except in a couple of places, really it permeates the entire flow of the Cybersecurity Framework, and when we think of a modern concept of what threat intelligence is, where it’s integrated into the workflow, then that becomes part of the way the Cybersecurity Framework works.

So, as you move up the tiers, you’re better integrating threat intelligence into your workflow, threat intelligence is informing what you do in a way that makes sense. So, it’s not just, “Here’s some external information that’s coming in,” It’s, “Okay, we’re integrating this threat intelligence directly into, whether it’s our endpoint protection, whether it’s our firewall, whether it’s our SIM.” By bringing all that in, it’s helping you again, not as much in tier one, but tier two, through tier four.

And then going to that next level of “Okay, I’m participating with my local ISAC, and I’m talking to other people in my industry, and sharing information. I’m publishing blog posts.” Whatever, all that information going back out to help keep the community informed. So now, you become not just a user of threat intelligence, but a producer of threat intelligence that helps protect other organizations.

Dave Bittner:

Well Ken, let’s dig into some of those examples. What can you share with us?

Ken Durbin:

Well, if we focus on the protect function, everybody is familiar with antivirus programs, endpoint protection, so that antivirus obviously is looking for a virus and for it to be able to find it and identify it, it’s looking for a signature and that signature is threat intel, or if you are trying to prevent your end users from communicating with bad IP addresses, so something that’s known to be a Botnet Command and Control Server. In order to do that, you need to know what that bad IP is and that, of course, is threat intelligence.

Allan Liska:

Right, and it’s whether you’re talking about bad IPs, bad domains, or at a basic level, if you’re talking about antivirus. So, a simple antivirus does a sort of a hash match, right? It’s, “This bad thing matches this bad thing, so I’m going to block it.” But even the more advanced endpoint capabilities like what Symantec does, you’re not just matching on hash, you’re matching on action.

So, all that becomes a profile of what an attack looks like, and being able to use that as a protective mechanism makes a lot of sense, and it is a form of threat intelligence that’s delivered directly to your users.

Dave Bittner:

And how about with a detect component?

Ken Durbin:

It would be a similar situation. You’re asking yourself, “What am I trying to detect?” And a lot of that is based on threat intel. So, you are going to have a need to inspect network traffic to detect indicators of compromise, or IOCs, or malware, and you want to do that before it gets on premise.

In order to fulfill that outcome, you need to have the threat intel in order to enable that to happen. Same thing with if you have encrypted traffic. You decrypt it, you need to be able to inspect that decrypted traffic, and you’re looking for indicators of compromise. That is all based on threat intel.

Allan Liska:

Right, and we see a lot of that, especially for more advanced clients that are starting to do things like inspect NetFlow or SSL detect, and for example, there’s a big demand right now for YARA rules. YARA rules are basically a form of threat intelligence that you can use to look at network traffic that’s passing through, find matches against behaviors.

So again, stepping up away from indicators, and more the entire action itself, and putting rules in place to find things that may look legitimate on first glance, but then a deeper inspection shows this is something bad, right? I mean, this is the role of the hunter in your security operations center, or maybe your incident response team.

Dave Bittner:

Well, help me understand how it plays into the respond component, because at that point, something has already happened and you have detected it.

Ken Durbin:

So you’ve detected it, now you have to respond to it and a lot of the goal of respond is to mitigate and prevent that event from getting out of hand, or getting more severe. So, an example there is, you’ve detected what is going on in the network that’s bad and you’re able to define that as an IOC, and we’ll say that the network control point detected the IOC and now it can send it down to the endpoints and say, “Hey, keep an eye out for this to prevent the event from spreading and getting out of hand.”

Or it could be as simple as you’ve had an event, you know that it is a vulnerability that has a patch that’s available, but you haven’t deployed the patch yet. So based on its CDE, you can then tell your asset management system to go and deploy this patch to take care of that known vulnerability.

Allan Liska:

Or if you can’t deploy a patch for whatever reason, you can put in place compensating controls, but you can take some sort of action, because of the behavior that you know is coming.

Dave Bittner:

And is it a factor of also getting intelligence on who might be responsible for this? I mean, I can imagine it being a different response if this is a nation state coming at me, versus some kids trying to steal credit card numbers.

Allan Liska:

Yeah, there’s definitely a difference in that, but even then, even ignoring the difference between a nation state actor, versus a cybercriminal, knowing in general the way the actor acts allows you to respond appropriately. So for instance, if you see something that indicates that it’s an actor that likes to use PsExec to move around the network, now you know, because of that intel, you now know, “Okay, I need to look for instances of PsExec being used at either odd times, or just in general use depending on how often it’s used in your network.”

So, knowing that information, knowing what the actor is and knowing the information about the actor, knowing their TTPs allows you to better respond in a way that is going to reduce the amount of time, what we say is reduce the dwell time working on the incident, because I now have these five things I can go look for and I can take that information and go across the network to look for it, and this also comes into play with automation.

If I have a set of indicators that I’ve gotten in my SIM and I can push those indicators out directly to my endpoints, or to a firewall for blocking, or to something else, I can respond to these activities much faster, in a much cleaner manner.

Dave Bittner:

I’m curious, Ken, from your point of view, do you have any tips for folks on how to best use the Framework? Maybe they’re already engaged with it, or are there areas where you find you have advice for folks to make better use of it?

Ken Durbin:

I do, and that’s a great question. So, the number one use case that we see for the Framework is its ability to communicate about your cybersecurity posture. Again, because of the way it’s structured with those five one word descriptions for the core: Identify, protect, detect, respond, and recover. Using that language really helps you to communicate to, we’ll say, the board of directors, or upper management, or even to your rank and file employees to get them to understand their role in cybersecurity, and protecting the organization as a whole.

The other thing we hear a lot is, “I’m in a regulated environment. I’m already required to use X, Y, Z. Why would I also use the Cybersecurity Framework?” Which is a valid question, and during the workshops that they had to develop the Framework, this came up. It was one of the last workshops, there was a CISO from a power utility company, he got up and he said, “I’ve been skeptical of the Framework this whole time, because I’m regulated, and I have to use, it’s either NERC or FERC. I am compliant, I’m always compliant, I’ve never been out of compliance, so why should I also use the Framework?”

But he took the time and he mapped the NERC and FERC controls into the Cybersecurity Framework and he realized that it wasn’t a one-to-one, there were more subcategories in the Framework than there were in his regulated controls library. So it forced him to look, “Okay, well what am I not doing?” And he saw that there was some very basic cybersecurity hygiene procedures, if you will, that he wasn’t doing, because he wasn’t required to.

So, he implemented those, so now he’s compliant and he’s also improved his overall cybersecurity posture. So, it’s a very powerful tool. People need to understand that nobody’s asking them to stop what they’re doing and move to the Cybersecurity Framework. Quoting somebody from NIST who once said, “The Framework works best when it works along with something else.”

Allan Liska:

And I think one of the points that we have glossed over here, and it’s only because Ken is too modest to brag about himself, is that Ken has been very, very closely involved in developing add ons to this Framework.

So, they released the first version, they’ve worked on additional versions, because this is a dynamic document, and Ken’s really been a force for helping design and guide the Framework in a way that’s useful for organizations.

Ken Durbin:

Well, thank you for that Allan, but yeah, I mean, I’m an advocate for it, and I do spend a lot of my time helping people understand its utility and how they can improve their situations using the Framework.

Dave Bittner:

Well Allan, what are your recommendations in terms of how often an organizations should revisit the Framework? It strikes me that this is not an exercise that you just do once and then you’re good to go forevermore.

Allan Liska:

Right, this isn’t designed to be a check box framework that is, “Okay, we’ve done this and now we’re done until the next audit.” To me, this is something that organizations should be continuously looking at. As you’re making budget decisions, as you’re hiring, and planning for the coming year, making sure that if you’ve achieved a level that you’re happy with, making sure that you’re going to remain in compliance with that.

Or if you’re looking to improve, if you’ve got areas where you want to focus, this can really help you decide, “Hey, these are areas where, okay, maybe we can improve in this area by adding multi-factor authentication, or something along those lines.” Within your organization it should be a dynamic document that’s always being changed and updated.

Dave Bittner:

Well, Kenneth, I’d like to give you the last word here. Any final words of wisdom for folks?

Ken Durbin:

Well, first off, I appreciate the opportunity to have this discussion, and it’s always an honor to be in Allan Liska’s company, but the Framework, the adoption rate is beyond what anybody expected at the beginning, and that’s a true testament to its ease of use and its effectiveness.

So, anything that we can do to help people understand where the Framework fits into what they’re doing, how to improve their mission or business goals is a good thing. So, I appreciate the opportunity to be on the podcast.

Dave Bittner:

Our thanks to Symantec’s Ken Durbin, and Recorded Future’s Allan Liska, for joining us.

Don’t forget to sign up for the Recorded Future Cyber Daily email, where every day you’ll receive the top results for trending technical indicators that are crossing the web, cyber news, targeted industries, threat actors, exploited vulnerabilities, malware, suspicious IP addresses, and much more. You can find that at recordedfuture.com/intel.

We hope you’ve enjoyed the show and that you’ll subscribe and help spread the word among your colleagues and online. The Recorded Future podcast team includes Coordinating Producer Zane Pokorny, Executive Producer Greg Barrette. The show is produced by the CyberWire, with Editor John Petrik, Executive Producer Peter Kilpe, and I’m Dave Bittner.

Thanks for listening.