NIST SP 800-53r3 Chapter 2

From FISMApedia
Jump to: navigation, search

CHAPTER TWO

THE FUNDAMENTALS

SECURITY CONTROL STRUCTURE, ORGANIZATION, BASELINES, AND ASSURANCE

This chapter presents the fundamental concepts associated with security control selection and specification including: (i) the structure of security controls and the organization of the controls in the control catalog; (ii) security control baselines; (iii) the identification and use of common security controls; (iv) security controls in external environments; (v) security control assurance; and (vi) future revisions to the security controls, the control catalog, and baseline controls.


2.1 SECURITY CONTROL ORGANIZATION AND STRUCTURE

Security controls described in this publication have a well-defined organization and structure. For ease of use in the security control selection and specification process, controls are organized into seventeen families.24 [1] Each security control family contains security controls related to the security functionality of the family. A two-character identifier is assigned to uniquely identify each security control family. In addition, there are three general classes of security controls: management, operational, and technical.25 [2] Table 1-1 summarizes the classes and families in the security control catalog and the associated security control family identifiers.

TABLE 1-1: SECURITY CONTROL CLASSES, FAMILIES, AND IDENTIFIERS
IDENTIFIER FAMILY CLASS
AC Access Control Technical
AT Awareness and Training Operational
AU Audit and Accountability Technical
CA Security Assessment and Authorization Management
CM Configuration Management Operational
CP Contingency Planning Operational
IA Identification and Authentication Technical
IR Incident Response Operational
MA Maintenance Operational
MP Media Protection Operational
PE Physical and Environmental Protection Operational
PL Planning Management
PS Personnel Security Operational
RA Risk Assessment Management
SA System and Services Acquisition Management
SC System and Communications Protection Technical
SI System and Information Integrity Operational
PM Program Management Management

To identify each security control, a numeric identifier is appended to the family identifier to indicate the number of the control within the family. For example, CP-9 is the ninth control in the Contingency Planning family and AC-2 is the second control in the Access Control family.

The security control structure consists of the following components: (i) a control section; (ii) a supplemental guidance section; (iii) a control enhancements section; (iv) a references section; and (v) a priority and baseline allocation section. The following example from the Auditing and Accountability family illustrates the structure of a typical security control.

AU-5 RESPONSE TO AUDIT PROCESSING FAILURES

Control: The information system:
a. Alerts designated organizational officials in the event of an audit processing failure; and
b. Takes the following additional actions: [Assignment: organization-defined actions to be taken (e.g., shut down information system, overwrite oldest audit records, stop generating audit records)].
Supplemental Guidance: Audit processing failures include, for example, software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. Related control: AU-4.
Control Enhancements:
(1) The information system provides a warning when allocated audit record storage volume reaches [Assignment: organization-defined percentage] of maximum audit record storage capacity.
(2) The information system provides a real-time alert when the following audit failure events occur: [Assignment: organization-defined audit failure events requiring real-time alerts].
(3) The information system enforces configurable traffic volume thresholds representing auditing capacity for network traffic and [Selection: rejects or delays] network traffic above those thresholds.
(4) The information system invokes a system shutdown in the event of an audit failure, unless an alternative audit capability exists.
References: None.
Priority and Baseline Allocation:
P1 LOW AU-5 MOD AU-5 HIGH AU-5 (1) (2)


The control section provides a concise statement of the specific security capabilities needed to protect a particular aspect of an information system.26 [3] The control statement describes specific security-related activities or actions to be carried out by the organization or by the information system. For some security controls in the control catalog, a degree of flexibility is provided by allowing organizations to selectively define input values for certain parameters associated with the controls. This flexibility is achieved through the use of assignment and selection operations within the control (see Section 3.3). Assignment and selection operations provide an opportunity for an organization to tailor the security controls to support specific mission, business, or operational needs. For example, an organization can specify the actions to be taken by the information system in the event of an audit processing failure (see AU-5 example above), the specific events to be audited within the system, the frequency of conducting system backups, restrictions on password use, or the distribution list for organizational policies and procedures.27 [4]

Once specified, the organization-defined values become part of the control, and the control implementation is assessed against the completed control statement. Selection statements narrow the potential input values by providing a specific list of items from which the organization must choose.

The supplemental guidance28 [5] section provides additional information related to a specific security control, but contains no requirements. Organizations are expected to apply the supplemental guidance as appropriate, when defining, developing, and implementing security controls. The supplemental guidance provides important considerations for implementing security controls in the context of an organization's operational environment, mission requirements, or assessment of risk. Security control enhancements may also contain supplemental guidance. Enhancement supplemental guidance is used in situations where the guidance is not generally applicable to the entire control but instead focused on the particular control enhancement.

The security control enhancements section provides statements of security capability to: (i) build in additional functionality to a control; and/or (ii) increase the strength of a control. In both cases, the control enhancements are used in an information system requiring greater protection due to the potential impact of loss or when organizations seek additions to the basic control functionality based on the results of a risk assessment. Control enhancements are numbered sequentially within each control so that the enhancements can be easily identified when selected to supplement the basic control. In the previous example for AU-5, if the first three control enhancements are selected, the control designation becomes AU-5 (1) (2) (3).29 [6] The numerical designation of a security control enhancement is used only to identify a particular enhancement within the control structure. The designation is neither indicative of the relative strength of the control enhancement nor assumes any hierarchical relationship among the enhancements.

The references section30 [7] includes a list of applicable federal laws, Executive Orders, directives, policies, standards, and guidelines (e.g., OMB Circulars, FIPS, and NIST Special Publications), that are relevant to a particular security control or control enhancement.31 [8] The references provide appropriate federal legislative and policy mandates as well as supporting information for the implementation of specific management, operational, or technical controls/enhancements. The references section also contains pertinent websites for organizations to use in obtaining additional information with regard to security control implementation and assessment.

The priority and baseline allocation section provides: (i) the recommended priority codes used for sequencing decisions during security control implementation (see Appendix D); and (ii) the initial allocation of security controls and control enhancements for low-impact, moderate-impact, and high-impact information systems (see Appendix F).


2.2 SECURITY CONTROL BASELINES

Organizations are required to adequately mitigate the risk arising from use of information and information systems in the execution of missions and business functions. A significant challenge for organizations is to determine the appropriate set of security controls, which if implemented and determined to be effective, would most cost-effectively mitigate risk while complying with the security requirements defined by applicable federal laws, Executive Orders, directives, policies, standards, or regulations (e.g., FISMA, OMB Circular A-130). Selecting the appropriate set of security controls to adequately mitigate risk by meeting the specific, and sometimes unique, security requirements of an organization is an important task—a task that clearly demonstrates the organization's commitment to security and the due diligence exercised in protecting the confidentiality, integrity, and availability of organizational information and information systems.

To assist organizations in making the appropriate selection of security controls for an information system, the concept of baseline controls is introduced. Baseline controls are the starting point for the security control selection process described in this document and are chosen based on the security category and associated impact level of the information system determined in accordance with FIPS 199 and FIPS 200, respectively. The tailored security control baseline (i.e., the appropriate control baseline from Appendix D adjusted in accordance with the guidance in Section 3.3) is the minimum set of security controls for the information system. Because the baseline is intended to be a broadly applicable starting point, supplements to the tailored baseline (see Section 3.3) will likely be necessary in order to achieve adequate risk mitigation. The tailored security control baseline is supplemented based on an organizational assessment of risk and the resulting controls documented in the security plan for the information system.

Appendix D provides a listing of baseline security controls. Three sets of baseline controls have been identified corresponding to the low-impact, moderate-impact, and high-impact information- system levels defined in FIPS 200 and used in Section 3.2 of this document to provide an initial set of security controls for each impact level.32 [9] Appendix F provides a detailed catalog of security controls for information systems, arranged by control families. Chapter Three provides additional information on how to use FIPS 199 security categories and FIPS 200 impact levels in applying the tailoring guidance to the baseline security controls and supplementing the tailored baseline in order to achieve adequate risk mitigation.


Implementation Tip

There are additional security controls and control enhancements that appear in the security control catalog (Appendix F) that are found in only higher-impact baselines or not used in any of the baselines. These additional security controls and control enhancements for the information system are available to organizations and can be used in supplementing the tailored baselines to achieve the needed level of protection in accordance with an organizational assessment of risk. Moreover, security controls and control enhancements contained in higher-level baselines can also be used to strengthen the level of protection provided in lower-level baselines, if deemed appropriate. At the end of the security control selection process, the agreed-upon set of controls in the security plan must be sufficient to adequately mitigate risks to organizational operations and assets, individuals, other organizations, and the Nation.

2.3 COMMON CONTROLS

Common controls are security controls that are inheritable by one or more organizational information systems.33 [10] The organization assigns responsibility for common controls to appropriate organizational officials and coordinates the development, implementation, assessment, authorization, and monitoring of the controls.34 [11] The identification of common controls is most effectively accomplished as an organization-wide exercise with the active involvement of the chief information officer, senior information security officer, risk executive (function), authorizing officials, information system owners, information owners/stewards, and information system security officers. The organization-wide exercise considers the security categories and associated impact levels of the information systems within the organization in accordance with FIPS 199 and FIPS 200, as well as the security controls necessary to adequately mitigate the risks arising from the use of those systems (see baseline security controls in Section 2.2).35 [12] For example, common controls can be identified for all low-impact information systems by considering the associated baseline security controls in Appendix D. Similar exercises can be conducted for moderate-impact and high-impact information systems as well. When common controls protect multiple organizational information systems of differing impact levels, the controls are implemented with regard to the highest impact level among the systems.

Many of the security controls needed to protect organizational information systems (e.g., contingency planning controls, incident response controls, security training and awareness controls, personnel security controls, physical and environmental protection controls, and intrusion detection controls) are excellent candidates for common control status. Information security program management controls (see Appendix G, PM family) may also be deemed common controls by the organization since the controls are employed at the organization level and typically serve multiple information systems. By centrally managing and documenting the development, implementation, assessment, authorization, and monitoring of common controls, security costs can be amortized across multiple information systems.

Common controls are generally documented in the organization-wide information security program plan unless implemented as part of a specific information system, in which case the controls are documented in the security plan for that system.36 [13] Organizations have the flexibility to describe common controls in a single document or in multiple documents. In the case of multiple documents, the documents describing the common controls are included as attachments to the information security program plan. If the information security program plan contains multiple documents, the organization specifies in each document the organizational official or officials responsible for the development, implementation, assessment, authorization, and monitoring of the respective common controls. For example, the organization may require that the Facilities Management Office develop, implement, assess, authorize, and continuously monitor physical and environmental protection controls from the PE family when such controls are not associated with a particular information system but instead, support multiple systems. When common controls are included in a separate security plan for an information system (e.g., security controls employed as part of an intrusion detection system providing boundary protection inherited by one or more organizational information systems), the information security program plan indicates which separate security plan contains a description of the common controls.

Security controls not designated as common controls are considered system-specific controls or hybrid controls. System-specific controls are the primary responsibility of information system owners and their respective authorizing officials. Organizations assign a hybrid status to a security control when one part of the control is deemed to be common and another part of the control is deemed to be system-specific. For example, an organization may implement the Incident Response Policy and Procedures security control (IR-1) as a hybrid control with the policy portion of the control deemed to be common and the procedures portion of the control deemed to be system-specific. Hybrid controls may also serve as templates for further control refinement. An organization may choose, for example, to implement the Contingency Planning security control (CP-2) as a template for a generalized contingency plan for all organizational information systems with individual information system owners tailoring the plan, where appropriate, for system-specific uses. Partitioning security controls into common, hybrid, and system-specific controls can result in significant savings to the organization in implementation and assessment costs as well as a more consistent application of the security controls across the organization. While the concept of security control partitioning into common, hybrid, and system-specific controls is straightforward and intuitive, the application within an organization takes significant planning and coordination.

Security plans for individual information systems identify which security controls required for those systems have been designated by the organization as common controls and which controls have been designated as system-specific or hybrid controls. Information system owners are responsible for any system-specific implementation details associated with an organization's common controls. These implementation details are identified and described in the security plans for the individual information systems. The senior information security officer for the organization coordinates with common control providers (e.g., facilities/site manager, human resources manager, intrusion detection system owner) to ensure that the required controls are developed, implemented, and assessed for effectiveness. The security plans for individual information systems and the organization-wide information security program plan together, provide complete coverage for all security controls employed within the organization.

Common controls, whether employed in an information system or in the environment of operation, are authorized by a senior organizational official37 [14] with at least the same level of authority and responsibility for managing risk as the authorization officials for information systems inheriting the controls.38 [15] Authorization results relating to common controls are shared with the appropriate information system owners. A plan of action and milestones is developed and maintained for the common controls that are deemed through assessment to be less than effective. Common controls are subject to the same continuous monitoring requirements as system-specific security controls employed in individual organizational information systems.


Implementation Tip

The selection of common controls is most effectively accomplished on an organization-wide basis with the involvement of the organization's senior leadership (i.e., authorizing officials, chief information officer, senior information security officer, information system owners, mission/business owners, information owners/stewards, risk executive [function]). These individuals have the collective corporate knowledge to understand the organization's priorities, the importance of the organization's operations and assets, and the relative importance of the organizational information systems that support those operations and assets. The organization's senior leaders are also in the best position to select the common controls for each security control baseline and assign organizational responsibilities for developing, implementing, assessing, authorizing, and monitoring those controls.

2.4 SECURITY CONTROLS IN EXTERNAL ENVIRONMENTS

Organizations are becoming increasingly reliant on information system services provided by external providers to carry out important missions and business functions. External information system services are services implemented outside of the authorization boundaries established by the organization for its information systems. These external services may be used by, but are not part of, organizational information systems. In some situations, external information system services may completely replace the functionality of internal information systems. Organizations are responsible and accountable for the risk incurred by use of services provided by external providers and address this risk by implementing compensating controls when the risk is greater than the authorizing official or the organization is willing to accept.

Relationships with external service providers are established in a variety of ways, for example, through joint ventures, business partnerships, outsourcing arrangements (i.e., through contracts, interagency agreements, lines of business arrangements), licensing agreements, and/or supply chain exchanges. The growing dependence on external service providers and new relationships being forged with those providers present new and difficult challenges for the organization, especially in the area of information system security. These challenges include:

  • Defining the types of external services provided to the organization;
  • Describing how the external services are protected in accordance with the security requirements of the organization; and
  • Obtaining the necessary assurances that the risk to organizational operations and assets, individuals, other organizations, and the Nation arising from the use of the external services is acceptable.

FISMA and OMB policy require external providers handling federal information or operating information systems on behalf of the federal government to meet the same security requirements as federal agencies. Security requirements for external providers including the security controls for information systems processing, storing, or transmitting federal information are expressed in appropriate contracts or other formal agreements using the Risk Management Framework and associated NIST security standards and guidelines described in Chapter Three. Organizations can require external providers to implement all steps in the Risk Management Framework described in Chapter Three with the exception of the security authorization step, which remains an inherent federal responsibility that is directly linked to the management of risk related to the use of external information system services.39 [16]

The assurance or confidence that the risk from using external services is at an acceptable level depends on the trust40 [17] that the organization places in the external service provider. In some cases, the level of trust is based on the amount of direct control the organization is able to exert on the external service provider with regard to employment of security controls necessary for the protection of the service and the evidence brought forth as to the effectiveness of those controls. The level of control is usually established by the terms and conditions of the contract or service- level agreement with the external service provider and can range from extensive (e.g., negotiating a contract or agreement that specifies detailed security control requirements for the provider) to very limited (e.g., using a contract or service-level agreement to obtain commodity services41 [18] such as commercial telecommunications services). In other cases, the level of trust is based on factors that convince the organization that the requisite security controls have been employed and that a credible determination of control effectiveness exists. For example, a separately authorized external information system service provided to an organization through a well-established line of business relationship may provide a degree of trust in the external service within the tolerable risk range of the authorizing official.

The provision of services by external providers 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 develops such agreements and requires 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 providers (e.g., the service is imposed on the organization or the service is commodity service), the organization establishes explicit assumptions about the service capabilities with regard to security.42 [19] Contracts between the organization and external 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.

Ultimately, the responsibility for adequately mitigating unacceptable risks arising from the use of external information system services remains with the authorizing official. Organizations require that an appropriate chain of trust be established with external service providers when dealing with the many issues associated with information system security. A chain of trust requires that the organization establish and retain a level of confidence that each participating service provider in the potentially complex consumer-provider relationship provides adequate protection for the services rendered to the organization. The chain of trust can be complicated due to the number of entities participating in the consumer-provider relationship and the type of relationship between the parties. External service providers may also in turn outsource the services to other external entities, making the chain of trust even more complicated and difficult to manage. Depending on the nature of the service, it may simply be unwise for the organization to place significant trust in the provider—not due to any inherent untrustworthiness on the provider's part, but due to the intrinsic level of risk in the service. Where a sufficient level of trust cannot be established in the external services and/or service providers, the organization employs compensating controls or accepts a greater degree of risk.


2.5 SECURITY CONTROL ASSURANCE

Assurance is the grounds for confidence that the security controls implemented within an information system are effective in their application. Assurance can be obtained in a variety of ways including:

  • Actions taken by developers, implementers, and operators in the specification, design, development, implementation, operation, and maintenance of security controls;43 [20] and
  • Actions taken by security control assessors to determine 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 system.

Appendix E describes the minimum assurance requirements44 [21] for security controls in low-impact, moderate-impact, and high-impact information systems. For security controls in low-impact systems, the emphasis is on the control being in place with the expectation that no obvious errors exist and that as flaws are discovered, they are addressed in a timely manner. For security controls in moderate-impact systems, in addition to the assurance requirements for low-impact systems, the emphasis is on increasing the grounds for confidence in control correctness. While flaws are still likely to be uncovered (and addressed expeditiously), the control developer or control implementer incorporates, as part of the control, specific capabilities to increase grounds for confidence that the control meets its function or purpose. For security controls in high-impact systems, in addition to the assurance requirements for moderate-impact systems, the emphasis is on requiring within the control, the capabilities that are needed to support ongoing, consistent operation of the control and to support continuous improvement in the control's effectiveness. There are additional assurance requirements available to developers/implementers of security controls supplementing the minimum assurance requirements for the moderate-impact and high- impact information systems in order to protect against threats from highly skilled, highly motivated, and well-resourced threat agents. This level of protection is necessary for those information systems where the organization is not willing to accept the risks associated with the type of threat agents cited above.


2.6 REVISIONS AND EXTENSIONS

The set of security controls listed in this publication represents the current state-of-the-practice safeguards and countermeasures for federal information systems and organizations. The security controls will be carefully reviewed and revised periodically to reflect:

  • Experience gained from using the controls;
  • Changing security requirements;
  • Emerging threats, vulnerabilities, and attack methods; and
  • Availability of new technologies.45 [22]

The security controls in the security control catalog are expected to change over time, as controls are withdrawn, revised, and added. The security controls defined in the low, moderate, and high baselines are also expected to change over time as the level of security and due diligence for mitigating risks within organizations changes. In addition to the need for change, the need for stability will be addressed by requiring that proposed additions, deletions, or modifications to the catalog of security controls go through a rigorous public review process to obtain government and private sector feedback and to build consensus for the changes. A stable, yet flexible and technically rigorous set of security controls will be maintained in the security control catalog.


Footnotes

  1. Of the eighteen security control families in NIST Special Publication 800-53, eighteen 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.
  2. A control family is associated with a given class based on the dominant characteristics of the controls in that family.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Each common control identified by the organization is reviewed for applicability to each specific organizational information system.
  13. Information security program plans are described in Appendix G.
  14. 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.
  15. When common controls are inherited from external environments, organizations should consult Section 2.4.
  16. See Implementation Tip in Section 3.3 for applying the Risk management Framework to external service providers.
  17. 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).
  18. 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.
  19. 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).
  20. 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.
  21. 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.
  22. 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.