Risk Management Framework. 

These three words are likely to bristle hairs upon the necks of information technology professionals across the U.S. Department of Defense (DOD), and for good reason. For years, the Defense Information Assurance Certification and Accreditation Process (DIACAP) has been the U.S. government’s go-to procedural mandate for securing DOD information systems, and it involves a painstaking process that we’ve evolved to accept and incorporate into our IT security management practices, ushering in a few choice words on the three-year anniversary of system authorization when it comes time to don our cybersecurity hats for re-assessment through a barrage of security controls, Defense Information Systems Agency (DISA) security technical implementation guides (STIG)/security requirement guides (SRG), vulnerability scans, plan of action and milestone (POA&M) generation and updates, etc. in an effort to ensure security compliance has been met. As of March 2014, just as we thought we had the process down, the DOD published DOD Instruction 8510.01, Risk Management Framework (RMF) for DOD Information Technology (IT) to identify the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) as the new mandate on the block to be adhered to. Mandatory implementation of RMF across the DOD begins October 1, 2016, with 100-percent implementation and compliance to be reached by mid-2018. The process is derived from the NIST 800 series of publications which lay out implementation guidance in great and cumbersome detail. 

Consisting of a six-step implementation plan (see Fig. 1), the process is designed to facilitate continuous risk management and compliance, rather than the “set it and forget it” approach that was characteristic of DIACAP, requiring only re-assessment every three years and foregoing many of the proactive measures now required under RMF throughout the lifecycle of the information system. 

To date, migration to RMF from DIACAP is a measure which has been avoided like the plague by the majority of DOD organizations, as the procedural guidance is overly verbose, yet at the same time so vague as to not only how the framework may be effectively implemented within a DOD environment but, even more confusingly, how to transition from DIACAP to RMF in an efficient and sensible manner. There isn’t yet a great deal of supporting information out there on the street as to how to pull this off, or what pitfalls to look out for, but what I’m aiming to do here is provide a little bit of high-level insight into the dynamics of the conversion process from the perspective of someone who has already undergone conversion from DIACAP and implementation of RMF within a DOD enterprise environment, as well as been actively engaged in drafting guidance pertaining to implementation of RMF for the DOD. While I’ll not delve into the intricacies of the RMF implementation/conversion process, these are some simple lessons-learned that will hopefully guide you into a positive course of action in relation to your DIACAP-to-RMF transition efforts.

1. This isn’t DIACAP. Accept it and move on:Avoid at all costs the tendency to compare everything under RMF to DIACAP. On the surface, it may be easy to assume similarities between the two are greater than they truly are. They’re not. Avoid the trap of locking into a cycle of meetings and discussions centered around how things were done under DIACAP, versus what is required under RMF. Here’s the trick… let go of the past. This isn’t DIACAP and, although existing documentation, procedures, etc. are tremendously useful in jump-starting the RMF development and implementation process, the majority of documentation will have to be re-worked anyway to meet RMF-specific mandates that didn’t exist under DIACAP. Save yourselves some time by collecting all existing artifacts you’re able to gather and get going with the re-writes to meet RMF requirements. There’s a long road ahead and no time for debate over how to beat the process. The only way to beat it is to not provide the explicit information called for under RMF in the RMF-required format, and to do so would be to submit to non-compliance.
2. Be mindful of your resources:Prior to initiation of the RMF conversion process, assess your current resources and cast assumptions aside that RMF may undergo efficient implementation on a DIACAP budget. It cannot. Rather than start off down this trail, only to find out mid-way through that, due to lack of resources, you're unable meet the requirements of the assessment and authorization (A&A) process without completely abandoning your primary organizational mission, ensure you are adequately staffed and funded to accommodate such a rigorous transition. Although this may not be the case for all, there is a high likelihood that additional contractors or other supporting personnel will need to be called in for reinforcement.
3. Don’t get carried away. Start with the basics:While on a surface level, it’s easy to assume that RMF is simply yet another framework that carries on in the tradition of DIACAP and the preceding DITSCAP, this couldn’t be farther from the truth. While this may be viewed as an opportunity to revamp information security management practices via application of additional processes, alterations to methodology, etc., you’re advised to stand down and weather the storm ahead before cruising into the heart of it, armed with only a wet map and a dinghy. The complexity of the RMF implementation process is staggering, consisting of (depending upon system categorization and overlays applied) not merely hundreds of security controls, but thousands of correlation control identifiers (CCI’s) which act as singular controls within themselves. Each one of these CCI’s represent an actionable component of the overarching security control. Where DIACAP used to group all actionable items under one control without delineation between them, RMF lists each requirement out under unique identifiers, forcing responsible parties to independently acknowledge every single one and document accordingly within the security authorization package management tool of choice. At the helm of each of the 18 security control families is a separate policy which will need to be drafted, each requiring extensive review and concurrence amongst stakeholders, ensuring feedback of all departments is considered before signing into action. Throughout the aforementioned CCI’s will be various plans, guidance, etc., which are all mandates under RMF and must be in place prior to authorization is rendered. These are only the beginning, and it’s imperative that your professional staff aren’t subjected to the burden of unnecessary visions of change that less-involved or non-technical managerial staff may be tempted to instate. There is always time for change later. Focus on executing the basics and get to know the core process first.
4. Hosting enclaves first, subordinate systems next:If there ever arises the debate regarding whether to transition hosting enclaves or subordinate systems first, the answer is this; hosting enclaves. Due to the nature of inherited controls, the many-to-one, umbrella nature of control complexity under RMF is more favorable to issuing inheritance to a DIACAP-accredited system, rather than receiving. You will encounter many scenarios in which several DIACAP controls may fit comfortably inside a single RMF control. Remember those CCI’s? It’s this reason that RMF controls are better-equipped to cover a broader range of requirements, per-control, than DIACAP. Additionally, if using an authorization package management suite such as Enterprise Mission Assurance Support Service (eMASS) or Xacta IA Manager, one is unable to issue or receive inheritance to or from dissimilar accreditation frameworks. In other words, if you want to use the system to inherit a DIACAP control to satisfy an RMF control on a lower level, this cannot be done. That being said, neither can the opposite, but it makes more managerial sense to transition a hosting enclave first, followed by subordinate systems to begin picking up inheritance as they cross over to the dark side alongside their hosting big brother. In the interim, inheritance relationships may be tracked and documented via external memorandums of acceptance/understanding (MOA/MOU) and electronically instated later as RMF transitions unfold on the subordinate level.
5. Clean up your artifacts:As roles and requirements have changed under RMF, existing artifacts that were once issued under DIACAP will require re-creation, even if their expiration is open-ended. As RMF mandates call for provision of artifacts in support of specific roles, procedures, etc., verbiage and processes will require alteration to render them usable under the new framework. As a part of this process, take a moment to re-evaluate the necessity of each artifact and resist the urge to transition the full load from the old package to the new package when converting to RMF. Odds are, the majority of these artifacts are redundant, unnecessary or inapplicable, expired or otherwise simply no longer desirable or welcome additions to the new accreditation package. Use this opportunity to do some spring cleaning where your supporting documentation is concerned and move into RMF with clear vision pertaining to not only to where you stand, but also where you’re headed.

As the RMF transition process is riddled with head-scratching moments and endless meetings that can potentially lock up weeks of valuable work time, these are some basic tips that, although very high-level and seemingly-simplistic, may shave days, weeks, or even months off of your implementation schedule if entering into the process with a general awareness of these pitfalls and how to avoid them early-on.

Enjoyed this piece? Follow Adam on LinkedIn, Twitter and Facebook. If you liked what you read, please share, like and comment.