Risky Business

Management of risk for federal compliance is intrinsically linked to the National Institute of Standards and Technology (NIST) Special Publications. Even if you are not mandated to follow these guidelines, they do provide a starting point from which you can find structure for advancing the maturity of your cybersecurity program. These publications take time to go through, but let’s cover the use of four that pertain to risk management. This is an introduction to NIST publications, not an exhaustive description of all that are involved in the process.

These are going to be laid out in numerical order, not necessarily based on significance. NIST SP 800-30 Rev 1 (and SP 800-39) provide guidance on risk assessments for federal information systems.  There are a few key takeaways here including the framing of the risk assessment. Particularly the Generic Risk Model with Key Risk Factors (Figure 1) should be understood as it is a point of focus for the conversation moving forward as seen below.

Figure 1 Generic Risk Model with Key
Risk Factors (NIST SP 800-30 Rev 1, p12)

Moving on to the next special publication we have NIST SP 800-37 Rev 2 that provides the actual framework for managing risk of federal information systems as well as providing guidance for the Federal Information Security Modernization Act of 2014 (FISMA) and the Privacy Act of 1974 (PRIVACT.)  The Risk Management Framework embraces the idea for incremental improvement as it demonstrates the need for a continual process as depicted below (Figure 2.)  This publication references numerous other publications throughout the industry, but for the sake of brevity, we will cover two more for this article.

Figure 2 Risk Management Framework
(NIST SP 800-37 Rev 2 p9)

In numerical order this leads us to NIST SP 800-53 Rev 5. This particular publication is used to implement controls in correlation with the RMF from the previous paragraph and in concert with the classification from the next one. Security controls tend to be the meat of the conversation for mitigating risk and even can be used for parts of incident response such as planning, identification, containment, eradication, recovery, and lessons learned (The PICERL format is more SANS and less NIST, but they do line up pretty well.) These controls undoubtedly will incorporate more characteristics from the CIS 20 in the future as they already are leaning that way. (CIS CSC 20 used to be the SANS 20 until branding was done in 2015.) My favorite part about these controls is the listing of the honeypot and the honeyclient. The honeyclient translates into a control that is a computer used to search out malicious activity on the internet (Figure 3.) That’s right, when Bob down the hall is researching elite hacks he is really just implementing a security control for the company!

Figure 3 Honeyclient Description
from SC-35 (NIST SP 800-53 REV 5 p252)

NIST SP 800-60 is the Guide for Mapping Types of Information and Information
Systems to Security Categories
.  The Risk Management Framework is used to quantify the impact and severity for the risk which an organization may face, and to help manage that risk through the use of controls.  The need for classification of systems is met by allowing the mapping of data and systems to security categories.  This qualitative analysis is a precursor and requirement for the quantitative practice that is generally outlined in this article.

This is just a quick overview of some of the NIST publications that you should
be using for federal information systems and compliance.  It is not comprehensive, but allows insight for the correlation between documents and the references they provide.  There are those in the private sector that will point to other frameworks that are just as good if not better.  The idea here is that if you do not need to comply with federal standards, you can still use the best parts of all frameworks to create your own security program.  This should be done with great scrutiny however; as you may find that certain frameworks require a structure that is not compatible with what you are trying to implement.  While you may be able to swap a corvette engine into the shell of a sub-compact car you will probably need to change the transmission at a minimum.  Frankensteining together a security program can lead to dire consequences.






Leave a Reply

%d bloggers like this: