NIST SP 800-53r2 Footnotes

From FISMApedia
Jump to: navigation, search

1

While agencies are required to follow NIST guidance in accordance with OMB policy, there is flexibility within NIST's guidance in how agencies apply the guidance. Unless otherwise specified by OMB, the 800-series guidance documents published by NIST generally allow agencies some latitude in their application. Consequently, the application of NIST guidance by agencies can result in different security solutions that are equally acceptable, compliant with the guidance, and meet the OMB definition of adequate security for federal information systems. When assessing agency compliance with NIST guidance, auditors, evaluators, and/or assessors should consider the intent of the security concepts and principles articulated within the particular guidance document and how the agency applied the guidance in the context of its specific mission responsibilities, operational environments, and unique organizational conditions.

2

The one-year compliance date for revisions to NIST Special Publications applies only to the new and/or updated material in the publications resulting from the periodic revision process. Agencies are expected to be in compliance with previous versions of NIST Special Publications within one year of the publication date of the previous versions.

3

An information system is a discrete set of information resources organized expressly for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. Information systems also include specialized systems such as industrial/process controls systems, telephone switching/private branch exchange (PBX) systems, and environmental control systems.

4

Organizational operations include mission, functions, image, and reputation.

5

Security control effectiveness addresses the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the information system in its operational environment.

6

The E-Government Act (P.L. 107-347), passed by the one hundred and seventh Congress and signed into law by the President in December 2002, recognized the importance of information security to the economic and national security interests of the United States. Title III of the E-Government Act, entitled the Federal Information Security Management Act (FISMA), emphasizes the need for organizations to develop, document, and implement an organization-wide program to provide security for the information systems that support its operations and assets.

7

Information system components include, but are not limited to, mainframes, servers, workstations, network components, operating systems, middleware, and applications. Network components can include, for example, such devices as firewalls, sensors (local or remote), switches, guards, routers, gateways, wireless access points, and network appliances. Servers can include, for example, database servers, authentication servers, electronic mail and web servers, proxy servers, domain name servers, and network time servers. Information system components are either purchased commercially off-the-shelf or are custom-developed and can be deployed in land-based, sea-based, airborne, and/or space-based information systems.

8

A federal information system is an information system used or operated by an executive agency, by a contractor of an executive agency, or by another organization on behalf of an executive agency.

9

NIST Special Publication 800-59 provides guidance on identifying an information system as a national security system.

10

Security controls from the audit, defense, healthcare, intelligence, and standards communities are contained in the following publications: (i) Government Accountability Office, Federal Information System Controls Audit Manual; (ii) Department of Defense Instruction 8500.2, Information Assurance Implementation; (iii) Department of Health and Human Services Centers for Medicare and Medicaid Services, Core Security Requirements; (iv) Director of Central Intelligence Directive 6/3 Manual, Protecting Sensitive Compartmented Information within Information Systems; (v) NIST Special Publication 800-26, Security Self-Assessment Guide for Information Technology Systems; and (vi) International Organization for Standardization/International Electrotechnical Commission 17799:2005, Code of Practice for Information Security Management.

11

Security requirements are those requirements levied on an information system that are derived from laws, Executive Orders, directives, policies, instructions, regulations, or organizational (mission) needs to ensure the confidentiality, integrity, and availability of the information being processed, stored, or transmitted.

12

NIST Special Publication 800-53A, Guide for Assessing the Security Controls in Federal Information Systems (Second Public Draft), April 2006, provides guidance on assessment methods and procedures for security controls defined in this publication. Special Publication 800-53A can also be used to conduct self-assessments of information systems.

13

An organization typically exercises direct managerial, operational, and/or financial control over its information systems and the security provided to those systems, including the authority and capability to implement the appropriate security controls necessary to protect organizational operations, organizational assets, and individuals.

14

Risk assessments can be accomplished in a variety of ways depending on the specific needs of the organization. The assessment of risk is a process that should be incorporated into the system development life cycle. NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems, provides guidance on the assessment and mitigation of risk as part of an overall risk management process.

15

NIST Special Publication 800-18, Guide for Developing Security Plans for Federal Information Systems, provides guidance on documenting information system security controls. The general guidance in Special Publication 800-18 is augmented by Special Publication 800-53 with recommendations for information and rationale to be included in the system security plan.

16

Successful life cycle management depends on having qualified personnel to oversee and manage the information systems within an organization. The skills and knowledge of organizational personnel with information systems (and information security) responsibilities should be carefully evaluated (e.g., through performance, certification, etc.).

17

The seventeen security control families in NIST Special Publication 800-53 are closely aligned with the seventeen security-related areas in FIPS 200 specifying the minimum security requirements for protecting federal information and information systems. Families are assigned to their respective classes based on the dominant characteristics of the controls in that family. Many security controls, however, can be logically associated with more than one class. For example, CP-1, the policy and procedures control from the Contingency Planning family, is listed as an operational control but also has characteristics that are consistent with security management as well.

18

A supplemental guidance section is also used for security control enhancements in situations where the guidance is not generally applicable to the entire control but instead focused on the particular control enhancement.

19

An information system may require security controls at different layers within the system. For example, an operating system or network component typically provides an identification and authentication capability. An application may also provide its own identification and authentication capability rendering an additional level of protection for the overall information system. The selection and specification of security controls should consider components at all layers within the information system as part of effective security and privacy architectures.

20

FIPS 199 security categories are based on the potential impact on an organization or individuals should certain events occur which jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals.

21

The baseline security controls contained in Appendix D are not necessarily absolutes in that the tailoring guidance described in Section 3.3 provides the organization the ability to eliminate certain controls or specify compensating controls under strict terms and conditions.

22

NIST Special Publication 800-37 provides guidance on security certification and accreditation of information systems.

23

In March 2004, OMB initiated a governmentwide analysis of selected lines of business supporting the President's Management Agenda goal to expand Electronic Government. Interagency task forces examined business and information technology data and best practices for each line of business-Case Management, Financial Management, Grants Management, Human Resources Management, Federal Health Architecture, Information Systems Security, Budget Formulation and Execution, Geospatial, and IT Infrastructure. The goal of the effort is to identify opportunities to reduce the cost of government and improve services to citizens through business performance improvements.

24

Information exchanges may be required among the many possible relationships with external service providers. The risk of exchanging information among business partners and other external entities must be assessed and appropriate security controls employed. There may be contract language that establishes specific requirements to protect information exchanged and/or that specifies particular remedies for failure to protect the information as prescribed. In addition, there may be laws or regulations that protect this information from unauthorized disclosure.

25

The level of trust that an organization places in an external service provider can vary widely ranging from those who are highly trusted (e.g., business partners in a joint venture that share a common business model and common goals) to those who are less trusted and represent greater sources of risk (e.g., business partners in one endeavor who are also competitors in another market sector).

26

In reality, the provision of services by providers external to the organization may result in some services without explicit agreements between the organization and the external entities responsible for the services. Whenever explicit agreements are feasible and practical (e.g., through contracts, service-level agreements, etc.), the organization should develop such agreements and require the use of the security controls in Special Publication 800-53. When the organization is not in a position to require explicit agreements with external service providers (e.g., when the service is imposed on the organization or when the service is commodity service), the organization should establish explicit assumptions about the service capabilities with regard to security. Contracts between the organization and external service providers may also require the active participation of the organization. For example, the organization may be required by the contract to install public key encryption-enabled client software recommended by the service provider.

27

Normally, commercial providers of commodity-type services (e.g., telecommunications services) organize their business models and services around the concept of shared resources and devices for a broad and diverse customer base. Therefore, unless organizations obtain fully dedicated services from commercial service providers (including dedicated devices and management systems), there will likely be a need for greater reliance on compensating security controls to provide the necessary protections for the information system that relies on those external services. The organization's risk assessment and risk mitigation activities should reflect this situation.

28

Confidence that the necessary security controls have been effectively implemented in organizational information systems provides a foundation for trust between organizations that depend upon the information processed, stored, or transmitted by those information systems.

29

In this context, a developer/implementer is an individual or group of individuals responsible for the development or implementation of security controls for an information system. This may include, for example, hardware and software vendors providing the controls, contractors implementing the controls, or organizational personnel such as information system owners, information system security officers, system and network administrators, or other individuals with security responsibility for the information system.

30

Currently, NIST plans to review and revise the security control catalog and security control baselines in Special Publication 800-53 on a biennial basis. The proposed modifications to security controls and security control baselines will be carefully weighed with each revision cycle, considering the desire for stability on one hand, and the need to respond to changing threats and vulnerabilities, new attack methods, new technologies, and the important objective of raising the foundational level of security over time.

31

Tailoring guidance provides organizations with specific considerations on the applicability and implementation of individual security controls in the control baselines (see Section 3.3).

32

NIST Special Publication 800-30, Risk Management Guide for Information Technology Systems, provides guidance on the assessment and mitigation of risk.

33

NIST Special Publication 800-18, Guide for Developing Security Plans for Federal Information Systems, provides guidance on documenting information system security controls.

34

NIST Special Publication 800-53A, Guide for Assessing the Security Controls in Federal Information Systems (Second Public Draft), April 2006, provides guidance for determining the effectiveness of security controls.

35

NIST Special Publication 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, provides guidance on the security authorization of information systems.

36

NIST Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, provides guidance on the assignment of security categories to information systems.

37

The high water mark concept is employed because there are significant dependencies among the security objectives of confidentiality, integrity, and availability. In most cases, a compromise in one security objective ultimately affects the other security objectives as well. Accordingly, the security controls in the control catalog are not categorized by security objective-rather, they are grouped into baselines to provide a general protection capability for classes of information systems based on impact level. The application of scoping guidance may allow selective security control baseline tailoring (see Section 3.3).

38

It is important for organizations to document the decisions taken during the security control baseline tailoring process, providing a sound rationale for those decisions whenever possible. This documentation is essential when examining the overall security considerations for information systems with respect to potential mission and/or business case impact.

39

For example, auditing controls would typically be applied to the components of an information system that provide or should provide auditing capability (servers, etc.) and would not necessarily be applied to every user-level workstation within the organization. Organizations should carefully assess the inventory of components that compose their information systems to determine which security controls are applicable to the various components. As technology advances, more powerful and diverse functionality can be found in such devices as personal digital assistants and cellular telephones, which may require the application of security controls in accordance with an organizational assessment of risk. While the tailoring guidance may support not applying a particular security control to a specific component (e.g., the audit example above), any residual risks associated with the absence of that control must still be addressed and mitigated as necessary to adequately protect the organization's operations, assets, and individuals.

40

When applying the "high water mark" process in Section 3.2, some of the original FIPS 199 confidentiality, integrity, or availability security objectives may have been upgraded to a higher baseline of security controls. As part of this process, security controls that uniquely support the confidentiality, integrity, or availability security objectives may have been upgraded unnecessarily. Consequently, it is recommended that organizations consider appropriate and allowable downgrading actions to ensure cost-effective, risk-based application of security controls.

41

Information that is security-relevant at the system level (e.g., password files, network routing tables, cryptographic key management information) is distinguished from user-level information within an information system. Certain security controls within an information system are used to support the security objectives of confidentiality and integrity for both user-level and system-level information. Caution should be exercised in downgrading confidentiality or integrity-related security controls to ensure that the downgrading action does not result in insufficient protection for the security-relevant information within the information system. Security-relevant information must be protected at the high water mark in order to achieve that level of protection for any of the security objectives related to user-level information.

42

Certain security controls that are uniquely attributable to confidentiality, integrity, or availability that would ordinarily be considered as potential candidates for downgrading (e.g., AC-16, AU-10, CP-5, IA-7, PE-12, PE-14, PL-5, SC-5, SC-13, SC-14, SC-16) are eliminated from consideration because the controls are either selected for use in all baselines and have no enhancements that could be downgraded, or the controls are optional and not selected for use in any baseline. Organizations should exercise extreme caution when considering downgrading actions on any security controls that do not appear in the list in Section 3.3 to ensure that the downgrading action does not affect security objectives other than the objectives targeted for downgrading.

43

More than one compensating control may be required to provide the equivalent or comparable protection for a particular security control in NIST Special Publication 800-53. For example, an organization with significant staff limitations may have difficulty in meeting the separation of duty security control but may employ compensating controls by strengthening the audit, accountability, and personnel security controls within the information system.

44

Organizations should make every attempt to select compensating controls from the security control catalog in NIST Special Publication 800-53. Organization-defined compensating controls should be used only as a last resort when the security control catalog does not contain suitable compensating controls.

45

The depth and rigor of the rationale provided should be scaled to the FIPS 199 impact level of the information system, with significantly less explanation needed for a low-impact system than for a high-impact system.

46

The organization also considers potential impacts to other organizations and, in accordance with the USA PATRIOT Act and Homeland Security Presidential Directives, potential national-level impacts in categorizing the information system.

47

Organizations should determine the specific types of events that would trigger a modification to the security plan and changes to the security controls within the information system. The decision to commit resources in light of such events should be guided by an organizational assessment of risk to the organization's operations and assets, or to individuals, that would result if these modifications and changes are not made.

48

The hierarchical nature applies to the security requirements of each control (i.e., the base control plus all of its enhancements) at the low-impact, moderate-impact, and high-impact level in that the control requirements at a particular impact level (e.g., AC-18 Wireless Access Restrictions-Moderate: AC-18 (1)) meets a stronger set of security requirements for that control than the next lower impact level of the same control (e.g., AC-18 Wireless Access Restrictions-Low: AC-18). Since the numerical designation of a control enhancement is neither indicative of the relative strength of the enhancement nor assumes any hierarchical relationship among enhancements, there are some controls (e.g., IA-2) that may not appear to satisfy the hierarchical nature of the security requirements of each control even though they do. For example, with IA-2 User Identification and Authentication, enhancement (1) is called out for the moderate baseline and enhancements (2) and (3) are called out for the high baseline. In this case, high [IA-2(2)(3)] is hierarchical to moderate [IA-2(1)] with regard to the security requirements being imposed.

49

In this context, a developer/implementer is an individual or group of individuals responsible for the development or implementation of security controls for an information system. This may include, for example, hardware and software vendors providing the controls, contractors implementing the controls, or organizational personnel such as information system owners, information system security officers, system and network administrators, or other individuals with security responsibility for the information system.

50

NIST Special Publications listed in the supplemental guidance sections of security controls are assumed to refer to the most recent updates to those publications. For example, a reference to NIST Special Publication 800-18 refers to the Special Publication 800-18, Revision 1, which is the latest version of the security planning guideline.

51

The security control mapping table includes references to: (i) ISO/IEC 17799:2005, Code of Practice for Information Security Management; (ii) NIST Special Publication 800-26, Security Self-Assessment Guide for Information Technology Systems; (iii) GAO, Federal Information System Controls Audit Manual; (iv) Director of Central Intelligence Directive 6/3 Policy and Manual, Protecting Sensitive Compartmented Information within Information Systems; and (v) Department of Defense Instruction 8500.2, Information Assurance Implementation. The designations in the respective columns indicate the paragraph identifier(s) or number(s) in the above documents where the security controls, control objectives, or associated implementation guidance may be found.

52

ISO/IEC 17799, Code of Practice for Information Security Management, is expected to be renamed to ISO 27002 consistent with the new designations for the ISO series of information security publications. ISO/IEC 17799 security controls are also referenced in ISO/IEC 27001:2005 Specification for an Information Security Management System.

53

References in this column are to both DCI Directive 6/3 and to its Manual (Administrative update, December 2003). Paragraphs cited from the Directive are preceded by "DCID" and where there are also references for the same control from the Manual, these are preceded by "Manual." Where only paragraph numbers appear, they are references to the Manual. References to paragraphs in the Manual should be construed to encompass all subparagraphs related to those paragraphs. It should also be noted that Special Publication 800-53 contains a set of security controls that cover personnel, physical, and technical security measures, and therefore, the scope of the publication is broader than DCID 6/3. Some of the controls in Special Publication 800-53 are explicitly not included in DCID 6/3 because they are addressed in other DCID and Intelligence Community (IC) policy documents. The difference in scope/breadth between Special Publication 800-53 and DCID 6/3 impacts the degree of correlation between the two documents. Thus, the lack of a "mapping" for a particular Special Publication 800-53 control to a DCID 6/3 requirement does not mean that there is no similar IC requirement. The IC Translation Review Board provided information for the DCID 6/3 mapping.

54

Appropriate authorizing officials approve the use of specific technologies, including Voice Over Internet Protocol. See also DCID 6/3 paragraph 2.B.4.d and 9.D.1.a.

55

There are certain FIPS and NIST Special Publications that are listed in the crosswalk for a particular security control in Appendix H that do not appear in the supplemental guidance for that control. The supplemental guidance for security controls lists only the most relevant NIST publications associated with that control or the publications that provide the most extensive guidance for that security control area.

56

An ICS is an information system used to control industrial processes such as manufacturing, product handling, production, and distribution. Industrial control systems include supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and programmable logic controllers (PLC). ICS are typically found in the electric, water, oil and gas, chemical, pharmaceutical, pulp and paper, food and beverage, and discrete manufacturing (automotive, aerospace, and durable goods) industries as well as in air and rail transportation control systems.

57

See Executive Order 13231 on Critical Infrastructure Protection, October 16, 2001.

58

NIST Special Publication 800-53 employs the term organization to refer to the owner or operator of an information system. In this Appendix, organization may refer to the owner or operator of an ICS.

59

In certain cases, the ICS-specific Supplemental Guidance developed during the ICS Security Project has applicability to general purpose information systems. As such, the ICS-specific guidance in Appendix I that is generally applicable to all information systems will be added to Appendix F during the next scheduled update to NIST Special Publication 800-53, Revision 3, projected for publication in December 2008.