July 4, 2018
How to Use NIST's Cybersecurity Framework
July 4, 2018
The United States has – with much effort – developed an effective cybersecurity framework. This has been carried out by the National Institute of Standards and Technologies (NIST). The latest version was released in 2017, three years after its 1.0 publication. Most people in the information security arena have heard about NIST, but often times, we hear about it in the form of ‘Risk Assessment’ or ‘Risk Management.’ There even exists a fascinating publication on vulnerability assessment and management. It essentially categorizes all areas of information security and recommends a series of tests using best practices. Quite interesting is their NIST approach to cybersecurity. In the same way, ‘C:Windows,’ ‘C:Users,’ and ‘C:Program Data’ all share the same root or ‘parent folder,’ so too do the aforementioned framework guides. The NIST Special Publication SP 800-53 is that ‘root’ or ‘parent directory’ to all other publications. NIST SP 800-53 allows the information security team to better facilitate policies and procedures, all the while improving the overall security state for a given organization. Current as of August 2017, NIST has published the 5th Revision for the 800-53 Special Publication. Although it recommends use of the newest revision – much like updating a computer – all special publications use the same structure. It is this structure that allows the information security assessor, auditor, provider, etc., to provide an accurate snap-shot into an organization’s overall security state. Before continuing below, I’d like to make one quick note. NIST, ISO (International Organizations of Standards), and the wide range of other cybersecurity framework options, all have one huge commonality: to protect the confidentiality, availability, and integrity of user data. Personally, I enjoy using the NIST Framework because it relates most of their ‘Informative References’ to its ISO counterpart. We will read below common cybersecurity framework procedures for NIST SP 800-53: Security and Privacy Controls for Information Systems and Organizations. This is achieved by segregating the Special Publication into four categories: definitions, risk assessment, tier implementation, and introduction to the core. Finally, I would like to take this opportunity to thank all who read this article, as it is my first! I hope to bring to you interesting and hopefully thought-provoking articles in the near future. If you have any questions, please do not hesitate to reach out to me.
Let’s first start by defining some important terms we’ll use throughout this article. The NIST Cybersecurity Framework is strictly related to legitimately whatever you want to protect. For example, if you have a Windows domain environment, but you only care about protecting the domain controllers, then your specific NIST assessment is only related to those servers. That specific set of hardware, software, communication paths, etc., is known as an ‘Information System.’ This is especially important as you read NIST publication documents. When they refer to an ‘Information System,’ they are referring to the set of ‘things’ you are protecting. Within your information system, there exist some pieces of infrastructure so critical to the organization that its incapacity or destruction will have a debilitating impact on cybersecurity and the organization. This is known as ‘Critical Infrastructure.’ The impact each information system has is integrated into the organization’s criticality matrix. An organization’s criticality matrix is a lesson within itself, but it can easily be defined. It’s a kind of matrix that plots the relationship between the probability of failure of an asset and the consequence of failure of an asset. This is based on our CIA (Confidentiality, Integrity, and Availability) triad. More information about criticality matrices and overall risk assessments can be better found in the Special Publications 800-30, 800-39, and possibly 800-115.
Now let’s move out away from these conceptual terms and move into something more concrete: the core. The cybersecurity framework consists of three partitions. The first partition or section is called the ‘Function.’ This is the highest structure level. From personal experience, it’s the easiest way to describe the overall process to C-level persons. In short, these categories describe all security controls. Five categories make up this level. Each category is then broken down into subcategories. Each subcategory defines special physical, administrative, and technical controls. Below is a list of all five function levels and their associated subcategories.
- Identify – Policies and procedures related to Asset Management, Business Environment, Governance, Risk Assessment, and Risk Management Strategy.
- Protect – Policies and procedures related to Access Control, Awareness and Training, Data Security, Information Protection, Maintenance, and Protecting Technology.
- Detect – Policies and procedures related to detecting Anomalies and Events, conducting Security Continuous Monitoring operation(s), and Detection Processes.
- Respond – Policies and procedures related to Response Planning, Communications, Analysis, Mitigation, and Improvements.
- Recover – Policies and procedures related to Recovery Planning, Improvements, and Communications.
The real substance comes from the third subcategory: informative resource. The informative resource outlines the control(s) in specific detail. The wording often requires a small learning curve, as the wording is unique. For example, informative resources do not say something like, “Your organization should probably not use ‘1234’ for administrative passwords.” Instead, you will see something along the lines of, “Organization-defined teams will define organization-based policies and procedures to determine the organization-defined best practices for all organizational-authorized users and groups, as the organization-defined prescribed team(s) consult organization-defined risk tolerance policies.” Although this is somewhat repetitive and arguably annoying, the terminology brings an important point to the surface. The cybersecurity framework does not recommend – nor endorse – specific technologies or vendors. This leaves your control choices wide opened. If, based on risk analysis, you find that eight characters provide the best level of protection, then use them. If you find that a certain password manager offers enough protection for data, then use that. After all, your control policies and procedures will change as your organization continues to find vulnerabilities, and they will continue to improve the overall security state. In other words, what works for your organization today will not always work (effectively) tomorrow. Moreover, improvement really depends on the kind of attitude your organization has towards cybersecurity. This is where the ‘Implementation Tier’ comes into play.
The Implementation Tier is broken into four levels. Each describes a kind of attitude or mentality towards cybersecurity. It demonstrates to the company their attitude towards risk management practices and repeatable and adaptive behaviors. Implementation tiers can also help measure the readiness your organization has to defeat computer hackers. To properly select an implementation level, NIST recommends that
“During the Tier selection process, an organization should consider its current risk management practices, threat environment, legal and regulatory requirements, business/mission objectives, and organization constraints.”
One important thing to note is that tier levels do not represent maturity levels. For example, an organization sitting at Level 4 is not more advanced or mature than an organization at Level 2. The underlying difference between each tier level is the amount of rigor in the overall cybersecurity risk management practice. Most importantly, tier movement should only be determined by the needs of the company. A major Fortune 500 company may need to sit at Tier 4, whereas an SMB company may only need to sit between Tiers 2 and 3. Finally, movement between tier levels should only occur when that change reduces the attack surface and is cost effective. The tier levels are defined below:
- Tier 1: Partial
- Tier 2: Risk Informed
- Tier 3: Repeatable
- Tier 4: Adaptive
We’ve seen risk management pop up a few times already, but let’s lightly discuss what that means. Risk management can be seen in full by visiting https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf. There are essentially four steps within the risk management process: framing risk, assessing risk, responding to risk, and monitoring risk. Let’s take a few moments to see what that includes:
- Framing Risk – This section describes the environment and process for making decisions related to risk. This step ultimately lays down the ground work for the next three parts of the risk management process.
- Assess Risk – This section helps to identify threats, internal and external vulnerabilities, adverse impact, and likelihood.
- Responding to Risk – This section describes how to develop courses of action, evaluating their effectiveness, and implementing risk responses.
- Monitoring Risk – This section seeks to help how an organization determines the effectiveness of risk responses, identifying risk-impacting changes, and verifying that any changes to the information system(s) are made appropriately and securely.
A helpful chart can be found on page 12 on https://www.nist.gov/sites/default/files/documents/cyberframework/cybersecurity-framework-021214.pdf.
NIST can be complicated. There are a lot of moving parts, and any one individual can spend countless hours studying a plethora of its nuances. Cybersecurity, just like life, does not have a ‘one-size-fits-all’ solution. As it relates to the NIST Cybersecurity Framework, there are some generalizations that can be made.
- There are three parts to the framework: the core, implementation tiers, and profiling.
- The core is the laundry list of suggestions, and their complexity is defined by the ‘Informative Resources.’
- The implementation tier is the current profile, and the target profile is based on conversations about risk management and local/federal/international laws.
In my experience, I typically conduct an assessment in the following way:
- I first have a conversation about why they want this assessment to take place. I inform the customer about the overall process and refrain from using any sort of technical language. My legal team then draws up documents. The purpose of this step is to ensure your organization/technicians have the authorization to touch the network/business in any sort of way. NDA’s are typically a great route to take in my opinion.
- At this point, I gather as much as information about their business and network as possible. During this process, I’m looking for sensitive information, how its stored, and what kind of existing protective measures are in place. For example, do they use NTFS or DFS file/folder permissions, or are they restricting access based on a Role Based Access Control or Mandatory Access Control model? I’m also searching for any kind of compliance agency that may govern over them.
- I then call a meeting between executives and my team. We discuss their risk management strategies. For example, we talk about how they address Risk i) Acceptance, ii) Transference, iii) Mitigation, and iv) Avoidance. This information helps me to determine their current tier level.
- This is hardest part of the entire process: informative resources. This is the part where I go through each and every informative resource and compare it to the business’ current practices. Just an FYI, this can be a little hard for the customer to hear. In the same way we don’t want to hear we’re wrong, any company won’t want to hear it's doing a ‘bad job.’
- I then create a Target Profile and Criticality Matrix for the client. This really helps to translate your findings from the informative resources and put them into actionable solutions.
I hope you’ve enjoyed the above article. I truly enjoy running through these assessments. If you find there’s a better way to conduct the overall NIST 800-53 SP, please let me know. I’m always open to learning and improving. If you have any questions, please do not hesitate to reach out to me on Cybrary.it. Thank you!