We’ve all heard the adage: “Nothing ventured, nothing gained.” In essence, you have to risk something if you want to get things done. So much of our lives involves assessing risk and intelligently managing those risks to meet our needs and achieve our goals. It’s why a motorcyclist wears a helmet to protect their brain in a crash and fills up their gas tank before a long trip to make sure they don’t run out in the middle of nowhere. That same rider isn’t likely to put on a life vest in the off chance they were to crash into a lake. At the same time, someone else might not even set foot on a motorcycle to begin with. We all build a set of rules and procedures to protect ourselves while encumbering what we individually consider to be just enough risk to do what we need to do (but not too much!).  Agencies have to deal with risk as well, but on a different scale.

The National Institute of Science and Technology (NIST) developed what, in 2010, would become the Risk Management Framework (RMF) to assist executive agencies in meeting their information security mandates in the Federal Information Security Modernization Act (FISMA) of 2014 (itself, an amendment to the Federal Information Security Act of 2002). Agencies follow the controlled, intelligent, flexible, and routinely updated methodology outlined in the RMF to develop systems that manage security, privacy, and supply chain risks (SPSCRs) while working within that agency’s mission, standards, and legal obligations.

Keep reading for an overview of how the RMF development process works and how to apply it to your organization.       

The Risk Management Framework (RMF) Process and Recent Changes

NIST’s RMF is currently on its second revision. It lays out seven sequential steps to follow to plan, develop, deploy, and evaluate an agency’s own unique risk posture system and to measure its success after it is enacted. These steps are:

• Prepare
• Categorize
• Select
• Implement
• Assess
• Authorize
• Monitor

NIST recently (NIST SP 800-37 Rev. 2) added the “Prepare” step to its RMF (the RMF had six steps in its earlier version). NIST added the new first step because they consider preparation to be the most critical to the RMF’s ultimate success. The first step forms the solid foundation upon which the final security “structure” will stand. Furthermore, with careful early planning and preparation, countermeasures and controls can be “baked into” the control system, typically a more effective solution than controls that are “bolted on” after the fact.

Throughout the process, look for ways to lean heavily on automation. NIST encourages organizations to maximize the use of automation, wherever possible, to increase the speed, effectiveness, and efficiency of executing the steps in the Risk Management Framework (RMF). Further, NIST’s guidance on automation gives organizations significant flexibility in deploying those systems that work best for them.

7 NIST RMF Steps & How to Apply Them

The seven NIST RMF steps lay out the process your organization can follow: Prepare; Categorize; Select; Implement; Assess; Authorize; and Monitor. Each step builds from its predecessor, ideally culminating in a fully realized system that encumbers enough SPSCR – but no more! – to function well over time.

Step 1: Prepare

The first step of NIST’s RMF guidance is to prepare all levels of your organization to manage its security and privacy risks through the RMF. Take a hard, careful look at your organization from a risk management perspective and document your interpretations because they will be the foundation upon which the rest of your RMF will be built.

Map out your business processes and the resources that they involve. What does your operations technology infrastructure (OTI) include? What is your management structure and who are your organization’s decision-makers? Who are your stakeholders? How might they be affected? What are your organization’s security exposures and risks? Are you confident that you can accurately assess and categorize these risks, or will you likely need outside help?  

Once you’ve produced a thorough assessment of what you’re about to undertake, you’re ready to move into the second step.

Step 2: Categorize

The second step in RMF development is to systematically categorize all of the SPSCRs your organization carries. Organizations in the Categorize step ask “what’s the worst that could happen – for our organization’s mission; our assets (or those of our stakeholders); or our ability to fulfill our legal responsibilities – if our information were compromised, stolen, or lost?”

Every organization places a different security weight on the confidentiality, integrity, and availability (the “Security Objectives”) of the information it processes, stores, and/or transmits (its “Information Types”). In this step, categorize each of your organization’s Information Types’ Security Objectives – Confidentiality, Integrity, and Availability – on a “Low”, “Moderate”, “High” scale. Then similarly categorize (“Low”, “Moderate”, “High”) the impact that your organization would feel to its ability to function effectively if any of those Security Objectives were compromised?

For example, compare how Anyville USA’s Department of Public Works (DPW) might categorize the data stored on their public information web server versus that in their geodatabase (a collection of data linked to geographic information) of installed waterlines:

Information Type	Security Objective  (i.e., “What’s important to us?”)			Security Impact Level (i.e., “What’s the worst that could happen to us?”)
	Confidentiality	Integrity	Availability	Confidentiality	Integrity	Availability
Public Information Web Server	Low	Moderate	High	Low	Moderate	Low
Installed Waterline Geodatabase	Moderate	High	Moderate	Moderate	High	Moderate

The information on DPW’s website is intended for public use, so public works staff are not concerned that it is kept confidential. If it were to be stolen and distributed over the web, it would have little impact because, again, it’s intended for broad access. DPW wants their website to be accurate. If someone were to alter it, giving the public incorrect information, that might create problems; probably not anything critical, but problems nonetheless. Finally, the information on that server should be readily available but if it were to go down, it would not result in a significant negative impact on their ability to carry out their responsibilities.

On the other hand, the DPW oversees public infrastructure, so, they would categorize their waterline geodatabase differently. It isn’t critical that waterline locations, materials, dimensions, etc. are kept in confidence, but it is important that the information in their records is correct. Otherwise, they might send the wrong supplies for a repair or damage a line they weren’t aware of during another construction project. DPW could refer to schematics and other data sources if the database were to be corrupted. Likewise, though it’s helpful to have that geodatabase readily available any time, the DPW has redundant information to refer to in a pinch.

Once you’ve categorized your SPSCRs, use a high-water-mark approach to assign an overall security impact value for that information type based upon its highest Impact Level score. Using Anyville DPW’s two examples, their website server would receive a “Moderate” Security Impact Value while their waterline geodatabase would be scored “High”.

Step 3: Select

In the third RMF development step, the organization selects, tailors, and documents the safeguards (called “Controls”) needed to protect the system, based upon its categorized risks. NIST developed Special Publication 800-53 (Rev. 5) to help with this process. This document lists over 1,000 individual controls that, when implemented with other controls, serve as starting points, or “Control Baselines,” that address different categorized SPSCRs. These control baselines are grouped into 18 “Control Families” ranging from Access Control (AC) to Incident Response (IR; click here to learn more about the different Control Families). 

 

If controls provide risk mitigation capabilities for multiple systems at once, like physical barriers to IT equipment, they are “Common Controls”. Controls that apply to only one system are “System-Specific.” If a control is common for some systems but specific to another, it is “Hybrid.” An example of a hybrid control might be security protocol training for a new server that includes a review of overall information security within the organization.

A few important notes for selecting controls from NIST SP 800-53:

1. One size does not fit all – The listed controls are baselines that are intentionally basic and broad to apply to the widest range of risk environments. Each organization must tailor the control baselines to meet their specific needs.
2. Focus on functionality; “more” ≠ “better” – If an organization were to deploy every one of the roughly 1,000 controls, they likely would be very secure, but they probably wouldn’t be able to function. Focus control selection and tailoring to manage real risk for your organization rather than removing it altogether.
3. Assign someone to oversee each control – In first aid courses, we are taught that we should not say, “Someone call 9-1-1!” Instead, we should clearly point to someone and tell them: “You! Call 9-1-1-!” Otherwise, everyone is likely to assume someone else will make that critical call and ultimately no one will. Similarly, controls are less likely to be effectively used (if they’re used at all) if everyone assumes someone else is responsible for them.

Refer to NIST Special Publication 800-53B for guidance on selecting, tailoring, and implementing your organization’s controls.

Step 4: Implement

In the fourth RMF development step, an organization takes all of their planning and development and implements their tailored controls on their system. Begin Step 4 by documenting your planned actions and documenting the roles and responsibilities. Then, over time, carry those plans out and revise your documentation as you go. Note that it may take a long time to fully complete an RMF’s implementation stage; this isn’t something your team can knock out over a long weekend. These controls may require new equipment that must be approved and procured. It may call for staffing changes or potentially jarring changes to your day-to-day operations that are best taken in smaller increments.

Things rarely go 100% according to plan. Because the implementation stage takes so long, take the opportunity to adjust as you go if a control isn’t meeting its intended requirements. Designed controls can be modified at any time or de-selected (i.e., not applicable) altogether if they aren’t working as planned.

And don’t forget to document these changes for future reference!

Step 5: Assess

In the fifth RMF step, the organization looks back at their implemented security control system and assesses how well it is working. Is it meeting the prescribed risk posture? Are there unforeseen problem areas? What will be done to address those problem areas so that the risk posture doesn’t go lower than prescribed?

NIST guidance mandates that you assign an assessor or an assessment team to objectively review the system and report their findings to the leadership. The assessor(s) typically reviews your system’s documentation for thoroughness and accuracy and watches the controls in action to make sure they are being carried out in accordance with the documentation without errors, omissions, or inconsistencies. They would watch for breakdowns in inter-related controls (precursor, concurrent, successor controls). They would also likely interview staff and service providers to get their perspective.

Because of their rapid, tireless, and unflinching attention, monitoring and reporting systems included with the implemented controls make the Assessment phase particularly well-suited for automation. The data they generate feed direc.tly into reports for authorization packages and implementation that follows (see below).

If the assessors finds unacceptable risks in the implemented system, you must develop a Plan of Action and Milestones (POA&M) to effectively and measurably (i.e. cost, schedule, and performance) remediate them. 

Step 6: Authorize

The sixth RMF step brings accountability, mandating that one senior official authorize the system, signing off on the prescribed, implemented, and assessed controls. That individual, in turn, accepts the risks of the system and assures that the controls have been appropriately developed and put in place to effectively control those risks. Before taking this significant responsibility, the signatory reviews the system’s Authorization Package, which contains the System Security Plan (SSP), the Security Assessment Plan (SAP), and the Security Assessment Report (SAR). If necessary, the Authorization Package would also include POA&Ms to mitigate unacceptable risks. With automated systems in place, these data can be generated on a real-time or near-real-time basis, leading to accurate and up-to-date decision-making for senior leaders.

Step 7: Monitor

In the final step, the organization watches their authorized system and adjusts it over time to make sure that it maintains the same security posture and the same level of acceptable risk that was laid out when the RMF was being developed. In this phase, groups may install patches to their software as they’re released or add new hardware that has exceeded its use life. They may adjust controls as new threats arise.

Automate RMF with IPKeys

NIST does not mandate that RMF documentation is done manually; automated systems are acceptable if they meet the RMF’s underlying requirements. NIST SP 800-37 Rev. 2 includes specific recommendations to use automation to the maximum extent possible to streamline RMF development and make it timelier, more thorough, and more accurate. IPKeys’ cutting-edge, automated Cyber-Lab-as-a-Service (CLaaS) platform can digitally document (write once – reuse many) a system’s cybersecurity artifacts using AI-fueled RMF controls, implementation, and assessment data. IPKeys CLaaS will help you make better, smarter cybersecurity decisions while staying NIST compliant.