NIST writes for everyone but no one in particular

Looking objectively at each stakeholder in the Framework process–the developers and the private companies, the authorizing officials, the Information Security Officers, the technical writers, the policy writers, the legislators, and executives–all are following the incentive structure that the Framework creates. NIST writes the documents, includes different perspectives, incorporates new ideas, addresses new technologies, fosters public discussion, and creates documents for everyone to use and benefit from.

Security and privacy control assessments are not about checklists, simple pass/fail results, or generating paperwork to pass inspections or audits.

- Executive summary, NIST SP 800-53A

The unintended outcome of that public, inclusive Framework is that practitioners are put in a position where they feel they must use the Risk Management Framework as a checklist, despite the fact that NIST specifically says not to do so. In later documentation, NIST laments, but acknowledges, this common practice.

An unintended and undesirable consequence of this has been that many security programs have focused on the individual controls as a compliance checklist, with little consideration given to how the controls work together to protect the confidentiality, integrity, and availability of information and systems.

- 3.1.1 Supports Strong Systems Engineering of Security Capabilities, NISTIR 8011

But if practitioners don’t treat the Framework as a checklist, they may have to explain why they chose to include or exclude specific security overlays or security controls. This creates a situation in which, if a problem were to occur after a system was authorized, it could be the fault of the Authorizing Official for not using a particular control on the list. Alternatively, If they complete the entire list of controls and then a problem arises, they can point to a completed checklist. In the latter situation, the blame is transferred from the Authorizing Official to whomever wrote the list, or no one at all.

The Framework incentivizes using the complete set of controls¹ as a checklist, regardless of whether controls are relevant, or unnecessarily slow or expensive to implement. Even when the process inflates costs, causes delays, or even lowers security, no one is at fault for implementing more controls. Everyone is acting applicably within the scope of the guidance.

This may happen in part because NIST writes for the widest possible audience.

“NIST documents are for very broad audiences. Even if you just wrote it for Federal agencies, that would be broad enough. But they are often written for any organization that wants to use the documents. So, trying to be prescriptive with how to do things for any organization of any size, in any sector, in any country or state or province with customers from whatever parts of the world, with whatever types of sensitive data, whatever platforms they have, programming languages, and on, and on, it’s impossible…. How will that get fixed in the future? Maybe through a lot of automation. But today there is no fix. Nobody has a solution to that.”

NIST carefully considered the broadest set of security standards and thoughtfully addressed them at length. But, by taking the widest possible approach to security, NIST has inadvertently subjected most practitioners to the highest effort approach to technical security.

“The way NIST created the 800-53 controls, they were trying to be as absolutely broad as possible and cover anything that could be considered an information system. And as a result a lot of the security controls sometimes… read as non-sequitur in the context of whatever system you’re actually trying to get through the process.”

1. Outlined in NIST Special Publication 800-53 ↩