Security & the Federal Risk Management Framework

We are experimenting with new ways to share our findings.

Check out the site for our RMF Report: https://rmf.servicedesigncollective.com/

The Risk Management Framework (RMF) is a set of security standards developed by the National Institute of Standards and Technology (NIST). It applies to all technical systems in the Federal government, except national security systems. The RMF is also used by cities, states, and private sector companies. The primary goal of our research was to understand both the theory and the practice of the Risk Management Framework in the Federal government.

The Framework is a complex, personality-driven process. In theory, it provides a valuable foundation for security. In practice, it is unacceptably slow and expensive. It discourages modern security practices for all but the most inexperienced security professionals and delays or prevents the deployment of modern technologies that would help agencies achieve their missions. While some practitioners succeed in delivering effective security in an acceptable time and at a reasonable cost, that is not the norm. Even when the process is run efficiently, it produces sub-standard results.

No stakeholders are acting maliciously. The problem with the Framework is the process itself. If everyone makes rational decisions in their own self-interest, the RMF incentivizes stakeholders to act in conflict with one another, rather than in concert. With changes, the process could be improved but in order to be successful long term, it must be radically simplified and rethought. Importantly, the biggest risk to relying on the Framework is not security failure, it is an inability to deliver critical public services and programs.

The Framework does not translate into effective risk management. Instead, it leads to risk avoidance, both personal and professional. Without any entity acting inappropriately, the complicated incentives of government led to a process that was slower, costlier, and less effective than intended. The Framework is well-intentioned but it has become increasingly cumbersome and ineffective at managing security as technology has evolved.

The Framework increased reliance on legacy systems and reduced the number of commercial solutions available to the government. In some cases it degraded security and contributed to an increased likelihood of potentially harmful events, such as the inability to deliver key public and economic services. This was an outcome that no one wanted or foresaw, but it has become widely accepted that the Framework is too slow and cumbersome to be an effective tool for managing technical security. The Framework is also too established to abolish. Therefore, technical security has become a step separate from security compliance.

In the absence of change, the inherent problems with the current system will continue to worsen. Modern technology is increasing in complexity while it is also becoming easier to use. Technologies such as large language models are difficult for even seasoned technical experts to fully understand but make it simple for non-technical users to complete complex tasks, such as writing code or querying large data sets. As more people use more complex technology more frequently and in more contexts, NIST must consider new risks and incorporate them into the Framework. Authorizing Officials will need to manage more technologies and authorize new systems while maintaining an increasingly large portfolio of ongoing monitoring and reauthorization.

In its current state, the Framework will continue to grow in scale and complexity. New controls and overlays will be necessary to manage new use cases. The introduction of the new AI Risk Management Framework is a good example of how the paperwork struggles to keep pace with technology. This will increase the time and costs associated with authorizing new technology, exacerbating the fundamental flaws of the Framework.

There are short term approaches that would improve the implementation of the current Framework. A professional class of Authorizing Officials, with relevant expertise, adequate training, and reduced liability would deliver better results. A simplified ATO process focused on outcomes would help encourage security over compliance. NIST could narrow its focus to the most critical systems or write for a targeted audience, such as inexperienced practitioners or owners of legacy software. Across all parties, clearer communication and plain language would encourage greater understanding, clarify intent, and improve the quality of security dialogue.

Ultimately, however, the system itself must change. Managing security via paperwork and personalities can neither capture the dynamics of technical security nor can it keep pace with technological innovation. If technical security is to remain a human process, it must be drastically simplified so that its users can keep pace with current technical needs; pruned down to its essentials and re-written in clear, direct language. Culturally, the government must learn to accept greater risk and elevate the risk of mission failure as a key factor in technical security decision making. Failing to deliver benefits and services, in most cases, will lead to greater harm than the loss of data, especially when appropriate safeguards and failsafes are put in place.

• Shorten the Framework & use plain language
• Update A-130: Make it actionable, readable & prominent
• Professionalize the Authorizing Official role
• Consider narrative security approaches
• Do away with all or part of the Risk Management Framework

Service Design Collective gathered a team of five experts in the field of government technology with more than 50 years of combined experience. Our team read through the Risk Management Framework and other supporting documentation related to software development and then conducted multiple rounds of interviews.

Between August 2022 and June 2023, we spoke with more than twenty people, including Authorizing Officials, Senior Executives in security roles, policymakers, employees of private sector technology companies, and security consultants. Half of participants worked for the federal government as senior executives or held the rank of GS-15, the highest level on the Federal Government’s “General Schedule” pay scale. The rest worked at private technology companies or in Congress. Eleven participants held related positions in more than one role (executive branch, legislative branch, or private sector) in the last five years. All participants had worked directly on either the management of security policy or the implementation of the Risk Management Framework in the last year.

Private sector participants held titles that included Chief Executive Officer, Head of Compliance, Policy, or Transformation, Principal Software Engineer, Security Engineer, or Staff Engineer.

Government participants held Chief and Senior titles in roles that included Information Officer, Information Security Officer, Cybersecurity Engineer, Staff Member, Deputy Director, Information System Security Officer, Digital Service Expert, or Contracting Officer.

In these documents we chose to let our participants speak for themselves wherever possible under a promise to remain anonymous when quoted.

We hope these reports contribute to a larger push toward concrete changes in the way the Federal government delivers technology and serves the people of the United States. We have included some ideas on where to start but know that further research is required. This topic is a work in progress for us and reports may be updated periodically to reflect new insights and additional research interviews.