By Philip D. Schall, Ph.D., CISSP, RDRP
As spring arrives, I thought it would be beneficial to share the rumblings and conversations I heard/had at AFCEA West 2022 and Rocky Mountain Cyberspace Symposium 2022 regarding my favorite topic, Risk Management Framework (RMF).
Before I dive into my RMF conference debrief, I am pleased to report that in-person conferences are back in full force!!! After the past few years of hiding in our offices in virtual meetings, the overall atmosphere of these events was very positive and full of energy! I think it is safe to say the DoD government and contractor community are ready to get back to it!
“Do we really need thousands of RMF controls?” The previous quote was a statement that I overheard at Rocky Mountain Cyberspace Symposium 2022 in a keynote address by a high-ranking government official. For edification, the answer to this question is YES, we really do need all of the RMF controls (if they are applicable to the system in question). The idea that RMF is failing and is inefficient is not a new one. I have previously written on this topic, and it is my belief that RMF is not a failed framework, but the perception of failure is due to a fundamental misunderstanding of the RMF process which likely starts with Authorizing Officials (AO’s) and government leadership. I have been trying for years to put together a half-day training class for AO’s without success or interest due to the busy schedule of those at the AO designation.
Below are the three themes and questions that were constant as well as my general responses.
Theme 1: RMF has too many controls and we need to figure out a way to make RMF quicker.
Response: RMF is a holistic framework. It does not focus on only technical controls. In fact, if you review most cybersecurity breaches, they often have direct relationships to poor implementation of administrative and operational controls. As an RMF practitioner, I recognize that RMF has A LOT of controls associated with systems, but we simply cannot start ignoring controls because they take too much time to respond to. Instead of trying to skip and cheat on control responses, I suggest we focus on reciprocity and trying to inherit controls from common control providers within our systems. Also, the automation of technical controls via STIG automation is a great idea, but we cannot simply ignore controls that are not technical in nature.
Theme 2: DoD has issued a statement on continuous authorization. Do you have any information on it?
Response: Yes, we saw that statement too. Unfortunately, until DoD publishes more specific continuous monitoring guidance and continuing authorization guidance in RMF Knowledge Service, we are in a holding pattern. We are very excited about this development too though and plan to create Continuous Authorization training as soon as guidance is available!
Theme 3: RMF needs to be automated. Can we just pay attention to technical controls and ignore the others?
Response: This comes back to Theme 1, but this question keeps coming up. I am 100% behind the automation of the appropriate controls in the RMF process. The controls that are most likely to be automated are technical in nature and many programs are currently being developed to do this. With that said, NO, we cannot only focus on the technical RMF controls. As previously stated, if you look at major cybersecurity breaches historically, most of the impacted systems utilized non-technical controls to compromise.
Overall, when talking to RMF subject matter experts and cybersecurity personnel, the common theme was that of jaws dropping when the question was proposed if we “really need all of these controls”. I sincerely hope it does not take a major breach and loss of life for DoD and the cybersecurity community to realize that we do indeed need all applicable controls. The solution to RMF efficiency is better RMF education and cybersecurity SME’s working together for evidence-based solutions vs. attempts to water down and take shortcuts when implementing RMF by making controls inaccurately not applicable.