SP 800-53 is essential for security in federal government IT systems

The National Institute of Standards and Technology (NIST) Special Publication (SP) SP 800-53 provides a unified information security framework to achieve information system security and effective risk management across the entire Federal Government. In previous articles in this series, Paul J. Brusil summarized the risk management framework and the catalog of security controls offered in SP 800-53. In this last of four articles, Brusil reviews the relationship of Recommended Security Controls for Federal Information Systems and Organizations, Rev. 3 to other standards as well as its suitability for government and non-governmental organizations. Everything that follows is Brusil's work with minor edits.

* * *

Communities Impacted by SP800-53

SP 800-53 (Appendix H) provides two-way mappings between security controls defined in SP 800-53 and security controls defined in international security standard ISO/IEC 27001, Information Security Management Systems. The latter standard applies to all types of organizations and non-government communities. SP 800-53 also outlines a strategy for harmonizing and converging these two standards.

Part 1, Part 2 and Part 3

SP 800-53 (Appendix I) also contains additions to the SP 800-53 Appendix D security control baselines so that such augmented security control baselines (in Appendix I) can be used in the Industrial Control Systems community. SP 800-53 (Appendix I) also contains community-specific, security control tailoring guidelines and other supplemental guidance for 64 of the security controls applicable to Industrial Control Systems from the SP 800-53 (Appendix D) security control catalog.

First and foremost, SP 800-53 is essential for security in U.S. federal government IT systems. Federal agencies and their external service providers must comply with FISMA, the Federal Information Systems Management Act of 2002, and the set of associated federal documents – FIPS 199 (Standards for Security Categorization of Federal Information and Information Systems), FIPS 200 (Minimum Security Requirements for Federal Information and Information Systems) and SP 800-53 – that delineate standards, specifications and recommendations for implementing FISMA. FISMA requires agencies in the US government and their contractors to understand risk and to undertake a risk management process on all their IT systems.

Specifically, FISMA requires that all agencies develop, document and implement agency-wide IA programs that support operations and assets and provide "adequate security." Every year, Inspectors General evaluate agency progress to achieve such requirements in the context of each agency's unique mission, environment and organization. SP800-53 is used as a guiding document to implement and to improve security under FISMA.

What the critics say

Although SP 800-53 is generally getting high marks from the IA community, it, and FISMA, are not without their critics.

Some say that certain agencies are not proficient in conducting a meaningful risk assessment and therefore will have difficulty identifying vital risks. Some feel that SP800-53 should have included measurable testing, third-party validation and certification that IT systems meet their security requirements. 

Yet others argue that most threats are now high-end threats. Since systems are so interconnected and often have ill-defined, inadequate, leaky borders, low-impact systems are effectively higher-impact systems because low-impact systems can become insider attack platforms against interconnected higher-impact systems. Accordingly, they dismiss SP800-53's discussion of low-impact and moderate-impact targets as irrelevant; all systems need to be protected against the types of attacks/attackers associated with high impact systems.

Some say that FISMA and the SP800-53 revision process are too static to keep up with quickly emerging threat landscapes or emerging protection technologies. Others say SP 800-53 is too flexible and is overly complex because so many security control choices are offered.

With regard to the latter point, some believe that a narrower subset or profile of SP800-53 provides the most critical security controls that address the most critical risks common to all parties. They feel some of the basic critical risks include
• Not knowing the instantaneous inventory of hardware, software and configurations.
• Providing "good" security features but not necessarily the "necessary" security features.
• Not providing auditing to validate security and to verify ongoing protection over time.

Unlike SP 800-53's security control baselines, proponents of an alternative feel there is only a small set of common and critical technical and operational controls that are applicable to all parties. Additional, organization-unique controls may be added as necessary. These common controls, called the "20 Critical Security Controls", can also be used by auditors to check if organizations are compliant with the standards of SP 800-53. The majority of these Critical Security Controls can also be automated for testing. Automation might make it easier to ensure that systems maintain information security and assurance over time. NIST officials are planning to include more automation, where feasible, in the next update to SP 800-53.

Still others feel the burden of multiple, independent, overlapping and/or redundant compliance regulations applicable to an organization, such as HIPAA, FISMA and others. They argue there needs to be a converged security and compliance strategy to minimize overlap and redundancy.

Some feel that periodically demonstrating compliance to regulations is overly complex and time-consuming thereby leaving less time to focus on an organization's missions. In part to address such concerns, an updated version of NIST's SP 800-37 Certification and Accreditation (C&A) Guidelines will refocus C&A from a periodic, one-time event to a more continuous process. Furthermore, new helpful technologies, such as continuous file integrity monitoring (see for example the white paper on "Continuous File Integrity Monitoring with Minimal System Impact and No Repeat Scans" from McAfee), are emerging to facilitate a shift from point-compliance testing to continuous compliance assurance.