Risk Management Framework (RMF) Can Help You Develop A Secure System

An overview of the Risk Management Framework (RMF) and its components.

Risk Management Framework (RMF) Can Help You Develop A Secure System

Throughout the past 25 years, the military and other government agencies struggled to adapt a standard of it's terminologies, development and certifications of their information systems. I won't get into the history of all the attempts of standardizations however, it's important to note before the implementation of RMF, DIACAP was a good attempt but it lacked "teeth." The teeth being, there was no way to enforce the standards needing implemented.

Commanding officers or agency department heads had  "oh yeah? Make me!" and "we've been doing things this way here for years" mentalities and never fully implemented the standards. Around the 2010's RMF, came along and stated to commanders "thou shall and thou will" follow the standards with god-like reverberation (and the backing to boot) to put the fear of God into them as well.

So, what is RMF and how can it help develop a secure information system?

RMF essentially coincides with the System Development Life Cycle (SDLC). It encompasses six National Institute of Standards and Technologies (NIST), three Department of Defense Instructions (DoDI), and (for even more sensitive IS's) two National Security Service/ Intelligence Community (NSS/IC) standards and frameworks. Seems like a lot, and it is, but they all come along together nicely as they all are interdependent. I would like to note these standards and frameworks all available to the public and anyone can use them in their IS development if they choose to. I will list all the standards and frameworks in the end.

To simplify, like the SDLC, RMF works in phases. RMF consists of six phases (see Figure 1).

Figure 1. RMF phases.
Phase 1, categorize the IS according to the DoDI 8510.01 and NIST 800-37 . The IS is categorized by how it is effected by the confidentiality, integrity, and availability (the CIA triad) with values of either low, moderate, or high. A system could be categorized as Moderate, Low, Low; C=moderate, I=low, A=low.

Phase 2, select controls according to NIST 800-53. The NIST 800-53 is the main reference I use as a daily to do my job. There are hundreds of controls broken into different categories ranging from access controls to physical controls.

The categorization from Phase 2 helps determine how many controls will be implemented and also, if the IS is processing or connecting to highly sensitive IS's, the CNSS 1253 could add some more controls (called overlays) onto the system. Conversely, some tailoring could apply as necessary, meaning, some controls just may not apply and could be stricken from the list of controls needed to be implemented.

Phase 3, implement the controls. At this time in the SDLC, you may have a running system to implement the controls from the 800-53 and self-test.

Phase 4, assess the controls. Here a third-party accessor will check how well you implemented your controls. They should use the NIST 800-53A as their procedures to access your controls. You should have answers to all of their questions at this point and if not a plan of action and milestones will be developed to answer them in the future.

Phase 5, authorization to operate. This is the end zone of the engineers and owners of the system. In the assessment phase, the accessors determined you either met requirements and gave their findings to an Authorizing Official (AO). The AO using the guidelines in the NIST 800-39, DoDI 8500.1, and 8500.2 thus determines whether they accept the risks (because we all know no system is ever 100% secure from vulnerabilities) or denies authorization to operate (ATO). Length of ATO could also vary, but is usually every 2 to 3 years.

Phase 6 is monitoring the controls. Hopefully, you gained an ATO and now is a active IS under the watchful eyes of the IS security manager. Use the NIST 800-137 as guideline to help determine what to do if a system component needs upgrade or software becomes obsolete, etc.

Again, this is a over-simplification of RMF. Hopefully, you could reference this article to give you an idea of what RMF is and how it can help you develop a more secure IS.

List of cited standards, guidelines, and frameworks:

NIST: 800-30 Risk Assessment, 800-37 Risk Management Framework, 800-39 Managing Information Security Risk, 800-53 IA Controls and Enhancements, 800-53A Assessment Procedures Development Guidance, and 800-137 Continuous Monitoring

DoD: 8500.1 Information Assurance, 8500.2 IT Definitions, 8510.01 Risk Management Framework for DoD IT

NSS: 1253  Baselines, Overlays, and Assignment Values