NIST SP 800-53r3 Footnotes

From FISMApedia
Jump to: navigation, search

__NOTOC_

1

The E-Government Act (P.L. 107-347) recognizes 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.

2

The term agency is used in this publication in lieu of the more general term organization only in those circumstances where its usage is directly related to other source documents such as federal legislation or policy.

3

While federal agencies are required to follow certain specific NIST Special Publications in accordance with OMB policy, there is flexibility in how agencies apply the guidance. Federal agencies should apply the security concepts and principles articulated in the NIST Special Publications in accordance with and in the context of the agency's missions, business functions, and environment of operation. Consequently, the application of NIST guidance by federal 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 federal agency compliance with NIST Special Publications, Inspectors General, evaluators, auditors, and assessors, should consider the intent of the security concepts and principles articulated within the specific guidance document and how the agency applied the guidance in the context of its mission/business responsibilities, operational environment, and unique organizational conditions.

4

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.

5

In certain situations within an organization, an information system can be viewed from both a logical and physical perspective as a complex system-of-systems (e.g., Federal Aviation Administration National Air Space System) when there are multiple information systems involved with a high degree of connectivity and interaction among the systems.

6

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

7

The term organization describes an entity of any size, complexity, or positioning within an organizational structure (e.g., a federal agency or, as appropriate, any of its operational elements).

8

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.

9

Risk is a measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Information system-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and consider the adverse impacts to organizational operations and assets, individuals, other organizations, and the Nation.

10

Includes risk to U.S. critical infrastructure/key resources as described in Homeland Security Presidential Directive 7.

11

Information system components include, for example, mainframes, workstations, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications.

12

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.

13

CNSS Instruction 1253 provides implementing guidance for NIST Special Publication 800-53 for national security systems.

14

At the agency level, this position is known as the Senior Agency Information Security Officer. Organizations may also refer to this position as the Senior Information Security Officer or the Chief Information Security Officer.

15

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

16

NIST Special Publication 800-53A provides guidance on assessing the effectiveness of security controls defined in this publication.

17

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

18

See FIPS Publication 200, footnote 7.

19

Risk assessments can be accomplished in a variety of ways depending on the specific needs of an organization. NIST Special Publication 800-30 provides guidance on the assessment of risk as part of an overall risk management process.

20

Considerations for potential national-level impacts and impacts to other organizations in categorizing organizational information systems derive from the USA PATRIOT Act and Homeland Security Presidential Directives.

21

The authorizing official or designated representative, by accepting the security plan, agrees to the set of security controls proposed to meet the security requirements for the information system.

22

NIST Special Publication 800-64 provides guidance on security considerations in life cycle management.

23

NIST Special Publication 800-39 provides guidance on organization-wide risk management.

24

Of the eighteen security control families in NIST Special Publication 800-53, seventeen families are described in the security control catalog in Appendix F, and are closely aligned with the seventeen minimum security requirements for federal information and information systems in FIPS 200. One additional family (Program Management [PM] family) in Appendix G provides controls for information security programs. This family, while not referenced in FIPS 200, provides security controls at the organizational rather than the information-system level.

25

A control family is associated with a given class based on the dominant characteristics of the controls in that family.

26

Security controls are generally designed to be technology and implementation independent and therefore, do not contain specific requirements in these areas. Organizations provide such requirements as deemed necessary in the security plan for the information system.

27

The organization determines whether a specific assignment or selection operation is completed at the organizational level, information system level, or a combination of the two.

28

The supplemental guidance section may contain information on related controls (i.e., security controls that either directly impact or support the control). For example, AC-6 (Least Privilege) is a related control to AC-3 (Access Control Enforcement) because AC-6 is a source for some of the authorizations to be enforced by AC-3.

29

AU-5 Enhancement (3) is an example of a requirement in the security control catalog (Appendix F) that is not in any of the control baselines (Appendix D). Such requirements can be used by organizations in supplementing the tailored baselines as described in Section 3.3 in order to achieve what the organization deems to be adequate risk mitigation.

30

Publications listed in the References section of security controls refer to the most recent versions of the publications. Organizations confirm from the respective official sources of the publications (e.g., OMB, NIST, NARA), that the most recent versions are being used for organizational application.

31

The references listed in the security control references section are provided to assist organizations in applying the controls and are not intended to be inclusive or complete.

32

The baseline security controls contained in Appendix D are not necessarily absolutes in that the tailoring guidance described in Section 3.3 provides organizations with the ability to eliminate certain controls or specify compensating controls in accordance with the terms and conditions established by authorizing officials.

33

A security control is inheritable by an information system or application when that system or application receives protection from the security control (or portions of the security control) and the control is developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the system or application—entities either internal or external to the organization where the system or application resides.

34

The Chief Information Officer, Senior Information Security Officer, or other designated organizational officials at the senior leadership level assign responsibility for the development, implementation, assessment, authorization, and monitoring of common controls to appropriate entities (either internal or external to the organization). Organizational entities assigned responsibility for common controls use the Risk Management Framework described in Chapter Three to help ensure appropriate security capabilities are provided.

35

Each common control identified by the organization is reviewed for applicability to each specific organizational information system.

36

Information security program plans are described in Appendix G.

37

The authorizing official role, whether applied to information systems or common controls, has inherent U.S. Government authority and is assigned to government personnel only.

38

When common controls are inherited from external environments, organizations should consult Section 2.4.

39

See Implementation Tip in Section 3.3 for applying the Risk management Framework to external service providers.

40

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).

41

Commercial providers of commodity-type services typically 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, there may 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 reflect this situation.

42

In situations where an organization is procuring information system services or technologies through a centralized acquisition vehicle (e.g., governmentwide contract by the General Services Administration or other preferred and/or mandatory acquisition organization), it may be more efficient and cost-effective for the originator of the contract to establish and maintain a stated level of trust with the external provider (including the definition of required security controls and level of assurance with regard to the provision of such controls). Organizations subsequently acquiring information system services or technologies from the centralized contract can take advantage of the negotiated trust level established by the procurement originator and thus avoid costly repetition of the activities necessary to establish such trust. For example, a procurement originator could authorize an information system providing external services to the federal government under specific terms and conditions of the contract. A federal agency requesting information system services under the terms of the contract would not be required to reauthorize the information system when acquiring such services (unless the request included services outside the scope of the original contract).

43

In this context, a developer/implementer is an individual or group of individuals responsible for the development or implementation of security controls. This may include in addition to organizational personnel, for example, hardware and software vendors providing the security controls and contractors implementing the controls.

44

Assurance requirements imposed upon developers and implementers of security controls are addressed in this special publication. Assurance gained from the assessment of security controls (e.g., by testers, evaluators, auditors, Inspectors General, information system owners) is addressed in NIST Special Publication 800-53A.

45

The security control catalog in Appendix F will be updated as needed with new controls developed from national-level threat databases containing information on known cyber attacks. 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. Organizations may develop new controls when appropriate controls are not available in Appendix F.

46

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

47

NIST Special Publication 800-30 provides guidance on the assessment of risk.

48

For legacy systems, some or all of the security controls selected may already be implemented.

49

NIST Special Publication 800-53A provides guidance on assessing the effectiveness of security controls.

50

NIST Special Publication 800-37 provides guidance on the security authorization of information systems.

51

NIST Special Publication 800-39 provides guidance on organization-wide risk management including the development of risk management strategies, risk-related governance issues, defining protection requirements and associated risks for organizational mission/business processes, integration of security and privacy requirements into enterprise architectures, and managing risk within the system development life cycle.

52

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.

53

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 based on the individual impact levels for confidentiality, integrity, and availability (see Section 3.3).

54

The general security control selection process may be augmented or further detailed by additional sector-specific guidance such as that provided for industrial control systems in Appendix I.

55

The level of detail required in documenting tailoring decisions in the security control selection process is strictly at the discretion of the organization and is consistent with the impact level of the information system.

56

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.

57

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.

58

Downgrading actions apply only to the moderate and high baselines. 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, 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 caution when considering downgrading 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.

59

As technology advances, more powerful and diverse functionality can be found in such devices as personal digital assistants and cellular telephones. These devices may require the application of security controls in accordance with an organizational assessment of risk. While the scoping guidance may support not allocating a particular security control to a specific component, any residual risk associated with the absence of that control must be addressed to adequately protect organizational operations and assets, individuals, other organizations, and the Nation.

60

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 compensate for the separation of duty security control by strengthening the audit, accountability, and personnel security controls within the information system. Acceptable compensating controls do not necessarily require the development of new security controls.

61

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

62

Considerations for potential national-level impacts and impacts to other organizations in categorizing organizational information systems derive from the USA PATRIOT Act and Homeland Security Presidential Directives.

63

Security controls and control enhancements selected to supplement tailored baselines are allocated to appropriate information system components in the same manner as the control allocations carried out by the organization in the initial baselines. See Section 3.3, Scoping Guidance, for security control allocation.

64

While this example focuses on threats to information systems from purposeful attacks, the scope of concern to most organizations also includes environmental disruptions and human errors.

65

NIST Special Publication 800-30 provides guidance on conducting risk assessments. Future updates to Special Publication 800-30 will include additional information on threat taxonomies and security capabilities.

66

Some of the steps in the Risk Management Framework are represented by actual security controls (e.g., RA-2, Security Categorization, CA-2, Security Assessment, CA-6, Security Authorization, and CA-7, Continuous Monitoring) in Appendix F. A few other selected security controls must be implemented initially to complete the first two steps in the Risk Management Framework. For example, RA-3, Risk Assessment, is implemented to conduct an organizational assessment of risk to support selecting, tailoring, and supplementing the security control baseline. Security control PL-2, Security Plan, is implemented to document the agreed-upon security controls upon completion of the control selection process. Organizations select and implement security controls in the appropriate sequence to fully execute the steps in the Risk Management Framework.

67

An information system can employ security controls at different layers within the system. An operating system, for example, typically provides an access control capability that includes the identification and authentication of users. An application, hosted by that operating system, may also provide its own access control capability requiring users to go through a second level of identification and authentication, thus rendering an additional level of protection for the information system. Organizations carrying out the security control selection process consider components at all layers within the information system as part of effective organizational security architecture implementing a defense-in-depth security strategy.

68

For example, local policies, procedures, and/or compensating controls could be established on the organization side to serve as alternative mitigation measures for risks identified in a gap analysis.

69

Examples of significant changes in the operational environment are interconnection of external information systems and large increases or decreases in the size of the community of users accessing the information system.

70

Organizations determine the specific types of events that would trigger changes to the security controls within the information system or its environment of operation and a resulting modification to the security plan. The decision to commit resources in light of such events is guided by an organizational assessment of risk.

71

A complete description of all security controls is provided in Appendices F and G. In addition, separate documents for individual security control baselines (listed as Annexes 1, 2, and 3) are available at http://csrc.nist.gov/publications.

72

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., CP-4 Contingency Plan Testing and Exercises—Moderate: CP-4 (1)) meets a stronger set of security requirements for that control than the next lower impact level of the same control (e.g., CP-4 Contingency Plan Testing and Exercises—Low: CP-4).

73

In this context, a developer/implementer is an individual or group of individuals responsible for the development or implementation of security controls. This may include in addition to organizational personnel, for example, hardware and software vendors providing the controls and contractors implementing the controls.

74

Assessment procedures for program management controls and common controls can be found in NIST Special Publication 800-53A.

75

In situations where common controls are inherited from external environments, organizations should consult the guidance provided in Section 3.4.

76

ISO/IEC 27001 was published in October 2005 by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC).

77

The use of the term XX-1 controls in mapping Table H-2 refers to the set of security controls represented by the first control in each family in NIST Special Publication 800-53, where XX is a placeholder for the two-letter family identifier. These security controls primarily focus on policies and procedures for each topic area addressed by the respective security control family.

78

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.

79

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

80

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.


Footnotes