A look back on my recent conversation with Dr. Ron Ross.
A few weeks ago, I had the opportunity to host an interview with renowned computer scientist and NIST Fellow, Dr. Ron Ross. The majority of our discussion centered around the implications of the upcoming final release of NIST SP 800-53, Rev. 5. In discussing the path that NIST took in updating Special Publication 800-53 this time around, we discussed some interesting changes that impact both public and private sector use.
Organizations that are essentially required to use the NIST RMF along with Rev. 5 will notice more flexibility in applying the controls. For instance, the Low, Moderate and High baselines have been removed from Rev. 5, and will be updated and placed within a new document called SP 800-53 “Bravo.” Additionally, updated guidance suggests that certain organizations and circumstances may see greater value from driving security requirements from the top down, via an engineering-based lifecycle, instead of using baselines that utilize specific controls mapped from 800-53 Rev. 5.
Considerable voluntary adoption of the RMF amongst the private sector, especially internationally, has also caused NIST to evolve Rev. 5 to be more approachable. The final public draft contains more easily interpretable IA controls and fewer references to U.S. government-focused processes and terms. In the end, the removal of the formalized baselines along with the addition of the “Prepare” step to the RMF significantly lower the barrier to entry for private organizations seeking to use NIST’s guidance and controls catalog as the high bar for risk and compliance activities.
However, a problem the new updated guidance has uncovered is the “taken at face value” adoption of the previous versions. In the past, adoption was usually forced as the letter of the law, with individual departments managing compliance by security checklist. What’s becoming clear is that a fair amount of work at the organizational level needs to occur to be successful with the RMF. Paraphrasing Dr. Ross, building a risk management program requires analytical thought.
Other topics we touched on included the incorporation of privacy controls throughout the catalog with a focus on both ensuring authorized use of PII and protecting against its unauthorized use — a subtle but very important difference. Furthermore, Dr. Ross sees the great value that both inheritance and DevOps pipelines can offer to drive down cost and maximize efficiency with the security, risk, and compliance process.
I leave you with one important thought from our discussion that our community of interest has been espousing for decades: we must continue to press the concepts of risk and compliance as far left in the system development lifecycle as possible, focusing on the integration of security at the earliest possible state. Risk, compliance, and security activities can’t be skipped or overlooked. Understanding their value and embracing them early has the greatest impact in reducing costs, timelines, and resources leading to successful deployments of assured systems and capabilities.
The Empower and Protect Blog brings you cybersecurity and information technology insights from top industry experts at Telos.