The Framework acts as an upper limit on security

“Unfortunately compliance has become so burdensome that sometimes it prevents updates to security because it takes so much time to audit it, so much time to prove it, that you don’t have enough time to actually do the work itself.”

Interview participants noted that the Risk Management Framework failed to take into account how technologies are actually created.

“I literally looked at a requirement the other day that was about data spillage and it says all of this information about how to manage it on-prem and then it’s like for cloud, maybe consider crypto erase, but that isn’t really a viable solution for most customers.”

“I don’t think NIST has really sat down and said, ‘okay, this is what we care about. What are the ways we can meet that, that are compatible with the way development works now.’”

Many felt that the Framework was a distraction to focusing on application development and more practical security concerns.

“There’s going to still be a need for documentation and proof, but it can’t be a 600 plus control, thousand page documentation because then you’re spending all of your resources on creating words, not software.”

“You have literal droves of Federal employees that are hired specifically to create documentation, and you have zero Federal employees that are actual engineers. This is because of the perverse incentives that are created here.”

“One of the central things that’s broken about the ATO process is that it doesn’t consider the cost of not launching.”

While it is commonly understood that the Framework establishes a strong foundation for security, many experienced security professionals felt it also acted as a ceiling, limiting or discouraging the use of advanced security practices. Inexperienced practitioners benefit far more from the Framework, which provides a list of potential vulnerabilities and mitigations of which they may be unaware, than experienced professionals. Skilled security professionals felt that the control-based nature of the Framework limited critical thinking and that related FIPS standards, specifically FIPS 140-3 and FIPS 200, prevented them from implementing industry best practices.

“This control based approach does not promote critical thinking which is bad. Not just because the controls themselves become outdated and lag best practices and have bad outcomes on a micro scale, but on a macro scale it also leads to huge misses…. There’s no control that is gonna have you thinking critically about what are the biggest risks facing my organization writ large.”

“Low, moderate, and high; to a certain extent it’s entrapment, right? It’s essentially a race to the bottom. FISMA and NIST could adopt a threat-informed and more risk-based approach to security control selection that prioritizes the security of the individual information system and furthers broader agency and administration goals focusing on resiliency, shared services, and administration cyber priorities. Such an approach could be more responsive in aligning cybersecurity protection needs at system, agency, and governmentwide levels.”

“Yes, FIPS is a standard. Does anybody actually meet FIPS and be able to work in any kind of environment? Not really.”

“Open SSH uses open SSL, but because it uses interfaces that are very old, we have to modernize it in order for it to use only the FIPS-compliant ones. Huge mess, huge undertaking.”

Overall, the guidance discourages the use of creative, new, or potentially more secure technologies to manage risk.