18F response to NIST’s call for comments on revision 5 of SP 800-53 #2
Description
18F comment, in response to NIST's call for comments on SP 800-53 revision 5. (archive.org snapshot from 2016-03-08)
18F welcomes the opportunity to respond to NIST's call for comments in preparation for NIST’s 5th version of Special Publication 800-53.
As a full-service technology shop that develops and hosts a number of production applications for a variety of federal agencies, 18F is very familiar with SP 800-53, FISMA, and other relevant guidance around federal IT security. While 18F does procure some level of IT support, 18F’s principle interaction with SP 800-53 is as direct implementers of security controls, through our in-house engineering and infrastructure professionals.
(Note: 18F is an office of the General Services Administration, but we are not submitting comments on behalf of the GSA, or its Chief Information Officer. These comments reflect 18F’s views only.)
Our comments are below, and have also been published on a repository we use to track public comments and where we welcome discussion. While we generally prefer to discuss technical, security, and policy issues in public forums, we can be reached for direct discussion by contacting devops@gsa.gov.
SP 800-53 should be a website with permalinks for each control
The current document and permalink of reference for SP 800-53 is a single PDF. SP 800-53 should instead be published as a website, with each control having its own permalink. Ideally, each control would have its own full page, with more room for elaboration and supporting material than the current PDF reasonably allows.
As a backbone reference for the federal IT community, it is important that SP 800-53 and its core concepts be communicated and understandable to a broad range of federal employees, and not only those staff formally charged with creating agency-specific policies that encode SP 800-53’s controls.
By being distributed as a multi-page website, SP 800-53 would reach a considerably expanded audience — especially those who are intimidated by or uninterested in opening a 462-page PDF.
In addition, the single-document format of SP 800-53 strongly incentivizes NIST to include only a small amount of information per-control. SP 800-53 would be a much stronger and more useful document if each control included generous amounts of plain-language explanation, example descriptions and links, and substantial implementation guidance for common situations. Publishing SP 800-53 as a website would make such a detailed approach more practical.
In its call for comments, NIST states (emphasis ours):
“NIST is considering the inclusion of hyperlinks throughout the document to make the guidance easier to navigate. For example, each security control in the left hand column in the Appendix D tables could be hyperlinked to the actual control in Appendix F.”
Including hyperlinks would be a serious improvement to SP 800-53, and 18F fully supports adding them. However, it would be a missed opportunity if these hyperlinks only worked in the context of a PDF (allowing intra-document navigation). NIST should ensure that each relevant section and control of SP 800-53 itself has a public web-based permalink, and that SP 800-53 freely links to external sources which can provide valuable supplementary guidance for implementing SP 800-53.
NIST also mentions that they are considering keywords for improved searchability. Publishing SP 800-53 as a website would improve the publication’s online searchability, especially via search engines, and make the manual production of keywords less necessary.
Even if SP 800-53’s primary permalink is a website, NIST may still wish to publish a PDF version of the policy, such as to allow offline signature verification of its contents. 18F encourages NIST to generate that PDF programmatically from the same source content used to generate the website. NIST may also or instead find it useful to create a “print-friendly” single-page website view of SP 800-53, which may also be easily exported as a PDF by modern browsers and tools. This would help keep NIST’s published documentation up to date in every published form.
SP 800-53 should be open source and be updated iteratively
IT security is a continuously evolving field. This is not just true at the level of specific algorithms, ciphers, and protocols — the risks and efficacy of high-level industry and government practices can change from year to year as technology changes and new ideas and attacks are surfaced.
SP 800-53 revisions are currently released 3-4 years apart, which is not sufficient to keep pace with the field whose best practices it attempts to encode. While it may be helpful for NIST to “step back” every few years and evaluate a thorough overhaul of the document, there should be mechanisms to update SP 800-53 “in place” in a more continuous manner. This is especially true for things like supporting examples and guidance (which 18F recommends including above), but is also true even for more fundamental changes in the choice and organization of NIST’s security controls.
To support this effort, NIST should place SP 800-53’s content into public version control so that any member of the public or the federal government can review and follow changes. This would also give NIST the opportunity to version control each control separately.
Discussion should be closely connected to the version control system, so that federal staff and members of the public have the opportunity to discuss proposed changes before they are finalized.
These goals are likely easier to achieve when SP 800-53 is distributed as a website and not as a PDF, as recommended above. In either case, SP 800-53 currently does not offer any formal method of version control. NIST and its audience would benefit from moving SP 800-53 into such a system, and creating an iterative workflow designed to keep SP 800-53 current and connected to the field whose practices it represents.
SP 800-53’s next call for comments should use a public forum
NIST’s publications would generally benefit by holding their public comment periods via public forums, where each comment is posted publicly by either its sender or by NIST, and discussions centered around each comment are possible. This is especially true for SP 800-53, as it is a central document for the entire federal community. When NIST proposes a draft revision 5, its call for comments on that revision should incorporate a public forum and explicitly encourage federal agencies to participate via that public forum.
This will benefit NIST by increasing the visibility, transparency, and robustness of feedback to NIST’s proposed documents. NIST’s calls for comments are always seen by specific audiences, such as portions of agency CIO offices, and other relevant agency oversight offices. However, they may be less well-noticed by parts of the public and federal bureaucracy not formally clued in to NIST’s processes. By creating a more public space for discussion, NIST will draw greater attention from the federal community, industry organizations, and encourage a wider number of commenting parties to participate, especially those who are not routinely told to comment on NIST’s work as part of their formal job description.
As an example of this sort of process, the Office of the Federal CIO (OFCIO) in the White House Office of Management and Budget (OMB) has now held public comment processes on their proposed agency IT policies several times, using GitHub. (In addition to providing hosted git-based version control, GitHub offers a minimalist issue tracker that can be effectively used as a discussion forum for policy issues.)
At the time of this comment, OFCIO is currently managing public comment on a proposed federal source code policy using GitHub issues. A previous example is the proposal which became OMB memorandum M-15-13 (HTTPS), which received public comments from various individuals and organizations, many of which served to directly improve the final product. There are a number of other examples, and they have consistently benefitted from a public comment period.
Of course, GitHub is not the only hosted option for this sort of discussion, and there are also robust open source forum platforms that NIST might choose to deploy, such as Discourse. The principle goal should be that comments are posted publicly, and can be individually discussed by the public and among agencies.
SP 800-53 should be distributed through secure connections
SP 800-53 is currently distributed over plain HTTP, which lacks any guarantees of confidentiality, authenticity, or integrity.
NIST should ensure that SP 800-53 is published exclusively through secure connections. NIST should make use of HTTPS and HSTS, as documented in M-15-13 and https.cio.gov, and in compliance with NIST’s own recommendations for protocols and ciphersuites.
By using secure connections in this way, SP 800-53 can lead by example for some of its own security controls. The configuration for SP 800-53’s distribution should not just meet NIST’s recommended baseline for agencies, but exceed that baseline and be as strong and modern as possible. As NIST’s recommendations evolve in parallel with best practices, NIST should continuously update SP 800-53’s security configuration, so as to keep it as an exemplar to the federal community.
SP 800-53 should strive to use plain language
Implementing controls from a formal security framework, like SP 800-53, is difficult. It requires an accurate understanding of the control requirements, as well as a deep understanding of the system in question. Misunderstandings can be costly, causing missed deadlines, failed audits, financial overruns, and even breaches. Complicated language increases the likelihood of a misunderstanding
NIST should strive to use simple, clear, plain language wherever possible.
For example, AC-7 (Unsuccessful Logon Attempts) in Revision 4 contains:
The information system:
a. Enforces a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and
b. Automatically [Selection: locks the account/node for an [Assignment: organization-defined time period]; locks the account/node until released by an administrator; delays next logon prompt according to [Assignment: organization-defined delay algorithm]] when the maximum number of unsuccessful attempts is exceeded.
This could be rewritten more clearly, employing clear language and eschewing jargon. An example revision might be:
To protect against brute-force attacks, accounts should be locked out after a series of failed login attempts. Alternatively, systems can delay subsequent login attempts, which increases the time required for a brute-force attack.
Organizations may define the number of unsuccessful attempts before a lock or delay takes place, as well as the length of lockout, delay time, and procedure for unlocking accounts.
Clear language makes controls easier to implement. This reduces costs and increases the likelihood of building secure systems.
SP 800-53 should include an overlay addressing controls for “the cloud”
Increasingly, organizations are moving their systems to Infrastructure- or Platform-as-a-Service offerings (a.k.a. “The Cloud”).
These platforms offer a host of benefits, including reduced costs, increased operational agility, improved security, and more. OMB’s draft Data Center Optimization Initiative explicitly calls for consolidation and closure of existing data centers and a move to “The Cloud”.
However, SP 800-53 is not entirely applicable to a cloud environment. Many controls — and several entire control groups — in SP 800-83 are written with physical data centers in mind. For example, the MP, PE, and PL control families mostly don’t apply to cloud deployments. Several other controls, and portions of controls, are similarly not applicable.
SP 800-53 also doesn’t contain any controls that would be applicable to cloud deployments, leaving implementers to determine their own ad hoc controls. For example, Amazon Web Services provides a sophisticated account management system, IAM, which can be used for very fine-grained access control to cloud resources. However, cloud implementations often don’t use IAM, instead sharing a single access credential that has access to the whole account. This credential, if stolen, can be used to disastrous effect. For example, in 2014, a company had its single credential compromised; the attacker deleted so much of the company’s data that the company was forced to shut down. SP 800-53 doesn’t speak explicitly to situations like IAM versus root credentials, leaving too much up to individual interpretation.
SP 800-53 should account for cloud environments by developing an overlay that speaks to cloud deployments specifically. This overlay should document which controls are the responsibility of the service provider (and thus out-of-scope for cloud implementers), and introduce additional controls specific to cloud environments.