NIST SP 800-53r3 Chapter 3

From FISMApedia
Jump to: navigation, search

CHAPTER THREE

THE PROCESS

SELECTION AND SPECIFICATION OF SECURITY CONTROLS

This chapter describes the process of selecting and specifying security controls for an organizational information system to include: (i) applying the organization's approach to managing risk; (ii) categorizing the information system and determining the system impact level in accordance with FIPS 199 and FIPS 200, respectively; (iii) selecting security controls, including tailoring the initial set of baseline security controls and supplementing the tailored baseline as necessary based on an organizational assessment of risk; and (iv) assessing the security controls as part of a comprehensive continuous monitoring process.

3.1 MANAGING RISK

The selection and specification of security controls for an information system is accomplished as part of an organization-wide information security program for the management of risk-that is, the risk to organizational operations and assets, individuals, other organizations, and the Nation associated with the operation of an information system. The management of risk is a key element in the organization's information security program and provides an effective framework for selecting the appropriate security controls for an information system-the security controls necessary to protect individuals and the operations and assets of the organization. The risk-based approach to security control selection and specification considers effectiveness, efficiency, and constraints due to applicable federal laws, Executive Orders, directives, policies, regulations, standards, or guidelines. The following activities related to managing risk, included as part of the Risk Management Framework, are paramount to an effective information security program and can be applied to both new and legacy information systems within the context of the Federal Enterprise Architecture and system development life cycle-

  • Categorize the information system and the information processed, stored, and transmitted by that system based on a FIPS 199 impact analysis.
  • Select an initial set of baseline security controls for the information system based on the system impact level and minimum security requirements defined in FIPS 200; apply tailoring guidance;46 [1] supplement the tailored baseline security controls based on an organizational assessment of risk47 [2] and local conditions including environment of operation, organization-specific security requirements, specific threat information, cost-benefit analyses, or special circumstances; and specify assurance requirements.
  • Implement the security controls and describe how the controls are employed within the information system and its environment of operation.48 [3]
  • Assess the security controls using appropriate assessment procedures 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.49 [4]
  • Authorize information system operation based on a determination of the risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation of the information system and the decision that this risk is acceptable.50 [5]
  • Monitor the security controls in the information system on an ongoing basis including assessing control effectiveness, documenting changes to the system or its environment of operation, conducting security impact analyses of the associated changes, and reporting the security state of the system to designated organizational officials.

Figure 3-1 illustrates the specific activities in the Risk Management Framework and the information security standards and guidance documents associated with each activity.51 [6] The remainder of this chapter focuses on several key activities in the Risk Management Framework associated with security control selection and specification.


FIGURE 3-1: RISK MANAGEMENT FRAMEWORK


3.2 CATEGORIZING THE INFORMATION SYSTEM

FIPS 199, the mandatory security categorization standard, is predicated on a simple and well-established concept-determining appropriate security priorities for organizational information systems and subsequently applying appropriate measures to adequately protect those systems. The security controls applied to a particular information system are commensurate with the potential adverse impact on organizational operations, organizational assets, individuals, other organizations, and the Nation should there be a loss of confidentiality, integrity, or availability. FIPS 199 requires organizations to categorize their information systems as low-impact, moderate-impact, or high-impact for the security objectives of confidentiality, integrity, and availability (RMF Step 1). The potential impact values assigned to the respective security objectives are the highest values (i.e., high water mark) from among the security categories that have been determined for each type of information processed, stored, or transmitted by those information systems.52 [7] The generalized format for expressing the security category (SC) of an information system is:

SC information system = {(confidentiality, impact), (integrity, impact), (availability, impact)},
where the acceptable values for potential impact are low, moderate, or high.

Since the potential impact values for confidentiality, integrity, and availability may not always be the same for a particular information system, the high water mark concept is introduced in FIPS 200 to determine the impact level of the information system for the express purpose of selecting an initial set of security controls from one of the three security control baselines.53 [8] Thus, a low-impact system is defined as an information system in which all three of the security objectives are low. A moderate-impact system is an information system in which at least one of the security objectives is moderate and no security objective is greater than moderate. And finally, a high-impact system is an information system in which at least one security objective is high.

Implementation Tip

To determine the overall impact level of the information system:
  • First, determine the different types of information that are processed, stored, or transmitted by the information system (e.g., financial sector oversight, inspections and auditing, official information dissemination, etc.). NIST Special Publication 800-60 provides guidance on a variety of information types commonly used by organizations.
  • Second, using the impact levels in FIPS 199 and the recommendations of NIST Special Publication 800-60, categorize the confidentiality, integrity, and availability of each information type.
  • Third, determine the information system security categorization, that is, the highest impact level for each security objective (confidentiality, integrity, availability) from among the categorizations for the information types associated with the information system.
  • Fourth, determine the overall impact level of the information system from the highest impact level among the three security objectives in the system security categorization.

3.3 SELECTING SECURITY CONTROLS

Once the impact level of the information system is determined, the organization begins the security control selection process (RMF Step 2). There are three steps in the control selection process carried out sequentially: (i) selecting the initial set of baseline security controls; (ii) tailoring the baseline security controls; and (iii) supplementing the tailored baseline. The following sections describe each of these steps in greater detail.54 [9]

Selecting the Initial Baseline Security Controls

The first step in selecting security controls for the information system is to choose the appropriate set of baseline controls. The selection of the initial set of baseline security controls is based on the impact level of the information system as determined by the security categorization process described in Section 3.2. The organization selects one of three sets of baseline security controls from Appendix D corresponding to the low-impact, moderate-impact, or high-impact rating of the information system. Note that not all security controls are assigned to baselines, as indicated by the phrase not selected. Similarly, not all control enhancements are assigned to baselines, as indicated by the security control being not selected or the enhancement number enclosed in parenthesis, not appearing in any baseline.

Tailoring the Baseline Security Controls

After selecting the initial set of baseline security controls from Appendix D, the organization initiates the tailoring process to appropriately modify and more closely align the controls with the specific conditions within the organization (i.e., conditions specific to the information system or its environment of operation). The tailoring process includes:

  • Applying scoping guidance to the initial baseline security controls to obtain a preliminary set of applicable controls for the tailored baseline;
  • Selecting (or specifying) compensating security controls, if needed, to adjust the preliminary set of controls to obtain an equivalent set deemed to be more feasible to implement; and
  • Specifying organization-defined parameters in the security controls via explicit assignment and selection statements to complete the definition of the tailored baseline.

To achieve a cost-effective, risk-based approach to providing adequate information security organization-wide, the baseline tailoring activities are coordinated with and approved by appropriate organizational officials (e.g., authorizing officials, authorizing official designated representatives, risk executive (function), chief information officers, or senior information security officers) prior to implementing the security controls. Organizations have the flexibility to perform the tailoring process at the organization level for all information systems (either as the required tailored baseline or as the starting point for system-specific tailoring), at the individual information system level, or using a combination of organization-level and system-specific approaches. Tailoring decisions for all affected security controls in the selected baseline, including the specific rationale for those decisions, are documented in the security plan for the information system and approved by appropriate organizational officials as part of the security plan approval process.55 [10]


Scoping Guidance

Scoping guidance provides organizations with specific terms and conditions on the applicability and implementation of individual security controls in the security control baselines. Application of scoping guidance helps to ensure that organizations implement only those controls that are essential to providing the appropriate level of protection for the information system based on specific mission/business requirements and particular environments of operation. There are several scoping considerations described below, that can potentially affect how the baseline security controls are applied and implemented by organizations:

  • COMMON CONTROL-RELATED CONSIDERATIONS-
Security controls designated by the organization as common controls are, in most cases, managed by an organizational entity other than the information system owner. Organizational decisions on which security controls are viewed as common controls may greatly affect the responsibilities of individual information system owners with regard to the implementation of controls in a particular baseline. Every security control in the tailored and supplemented set of controls for an information system is identified in the security plan as a common, system-specific, or hybrid control (see Section 2.3).
Security controls that support only one or two of the confidentiality, integrity, or availability security objectives may be downgraded to the corresponding control in a lower baseline (or modified or eliminated if not defined in a lower baseline) if, and only if, the downgrading action: (i) is consistent with the FIPS 199 security category for the supported security objective(s) before moving to the FIPS 200 impact level (i.e., high water mark);56 [11] (ii) is supported by an organizational assessment of risk; and (iii) does not adversely affect the level of protection for the security-relevant information within the information system.57 [12] The following security controls are recommended candidates for downgrading: (i) confidentiality [MA-3 (3), MP-2 (1), MP-3, MP-4, MP-5 (1) (2) (3), MP-6, PE-5, SC-4, SC-9]; (ii) integrity [SC-8]; and (iii) availability [CP-2, CP-3, CP-4, CP-6, CP-7, CP-8, MA-6, PE-9, PE-10, PE-11, PE-13, PE-15, SC-6].58 [13]
  • SYSTEM COMPONENT ALLOCATION-RELATED CONSIDERATIONS-
Security controls in the baseline represent an information system-wide set of controls that may not be necessary for or applicable to every component in the system. Security controls are applicable only to the components of the information system that provide or support the security capability addressed by the control and are sources of potential risk being mitigated by the control. For example, auditing controls are typically allocated to components of an information system that provide auditing capability (e.g., servers, etc.) and are not necessarily applied to every user-level workstation within the organization; or when information system components are single-user, not networked, or part of a physically isolated network, one or more of these characteristics may provide appropriate rationale for not allocating selected controls to that component. Organizations assess the inventory of information system components to determine which security controls are applicable to the various components and subsequently make explicit decisions regarding where to allocate the controls in order to satisfy organizational security requirements.59 [14]
  • TECHNOLOGY-RELATED CONSIDERATIONS-
Security controls that refer to specific technologies (e.g., wireless, cryptography, public key infrastructure) are applicable only if those technologies are employed or are required to be employed within the information system. Security controls that can be supported by automated mechanisms do not require the development of such mechanisms if the mechanisms do not already exist or are not readily available in commercial or government off-the-shelf products. For example, automated mechanisms may be used to maintain up-to-date, complete, accurate, and readily available baseline configurations of organizational information systems. If automated mechanisms are not readily available, cost-effective, or technically feasible, compensating security controls, implemented through nonautomated mechanisms or procedures, are used to satisfy specified security control requirements (see terms and conditions for selecting and applying compensating controls below).
  • PHYSICAL INFRASTRUCTURE-RELATED CONSIDERATIONS-
Security controls that refer to organizational facilities (e.g., physical controls such as locks and guards, environmental controls for temperature, humidity, lighting, fire, and power) are applicable only to those sections of the facilities that directly provide protection to, support for, or are related to the information system (including its information technology assets such as electronic mail or web servers, server farms, data centers, networking nodes, workstations, boundary protection devices, and communications equipment).
  • POLICY/REGULATORY-RELATED CONSIDERATIONS-
Security controls that address matters governed by applicable federal laws, Executive Orders, directives, policies, standards, or regulations (e.g., privacy impact assessments) are required only if the employment of those controls is consistent with the types of information and information systems covered by the applicable laws, Executive Orders, directives, policies, standards, or regulations.
  • OPERATIONAL/ENVIRONMENTAL-RELATED CONSIDERATIONS-
Security controls that are based on specific assumptions about the operational environment are applicable only if the information system is employed in the assumed environment. For example, certain physical security controls may not be applicable to space-based information systems, and temperature and humidity controls may not be applicable to remote sensors that exist outside of the indoor facilities that contain information systems.
  • SCALABILITY-RELATED CONSIDERATIONS-
Security controls are scalable with regard to the extent and rigor of the implementation. Scalability is guided by the FIPS 199 security categorization and associated FIPS 200 impact level of the information system being protected. For example, a contingency plan for a high-impact information system may be quite lengthy and contain a significant amount of implementation detail. In contrast, a contingency plan for a low-impact information system may be considerably shorter and contain much less implementation detail. Organizations use discretion in applying the security controls to information systems, giving consideration to the scalability factors in particular environments. This approach facilitates a cost-effective, risk-based approach to security control implementation that expends no more resources than necessary, yet achieves sufficient risk mitigation and adequate security.
  • PUBLIC ACCESS-RELATED CONSIDERATIONS-
When public access to organizational information systems is allowed, security controls are applied with discretion since some security controls from the specified control baselines (e.g., identification and authentication, personnel security controls) may not be applicable to public access. For example, while the baseline controls require identification and authentication of organizational personnel that maintain and support information systems providing the public access services, the same controls might not be required for access to those information systems through public interfaces to obtain publicly available information. On the other hand, identification and authentication would be required for users accessing information systems through public interfaces in some instances, for example, to access/change their personal information.

Compensating Security Controls

Organizations may find it necessary on occasion, to employ compensating security controls. This may occur, for example, when an organization is unable to implement a security control in the baseline or when, due to the specific nature of an information system or its environment of operation, the control in the baseline is not a cost-effective means of obtaining the needed risk mitigation. A compensating security control is a management, operational, or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines described in Appendix D, that provides an equivalent or comparable level of protection for an information system and the information processed, stored, or transmitted by that system.60 [15] Compensating controls are typically selected after applying the scoping considerations in the tailoring guidance to the initial set of baseline security controls. For example, compensating controls may be needed by the organization when applying technology-based considerations addressing the lack of capability to support automated mechanisms as part of a security control or control enhancement requirement. A compensating control for an information system may be employed only under the following conditions:

  • The organization selects the compensating control from NIST Special Publication 800-53, or if an appropriate compensating control is not available, the organization adopts a suitable compensating control from another source;61 [16]
  • The organization provides supporting rationale for how the compensating control delivers an equivalent security capability for the information system and why the related baseline security control could not be employed; and
  • The organization assesses and formally accepts the risk associated with employing the compensating control in the information system.

Organization-Defined Security Control Parameters

Security controls containing organization-defined parameters (i.e., assignment and/or selection operations) give organizations the flexibility to define certain portions of the controls to support specific organizational requirements or objectives (see AU-5 example in Section 2.1). After the application of scoping guidance and selection of compensating security controls, organizations review the list of security controls for assignment and selection operations and determine the appropriate organization-defined values for the identified parameters. Values for organization-defined parameters are adhered to unless more restrictive values are prescribed by applicable federal laws, Executive Orders, directives, policies, standards, guidelines, or regulations. Organizations may choose to specify values for security control parameters before selecting compensating controls since the specification of those parameters completes the definition of the security control and may affect the compensating control requirements.

Supplementing the Tailored Baseline

The tailored security control baseline is the foundation or starting point for determining the needed set of security controls for an information system. As described in Section 3.1, the final determination of the appropriate set of security controls necessary to provide adequate security for an information system is a function of the organization's assessment of risk and what is required to sufficiently mitigate the risks to organizational operations and assets, individuals, other organizations, and the Nation.62 [17] In many cases, additional security controls or control enhancements will be needed to address specific threats to and vulnerabilities in an information system and to satisfy the requirements of applicable federal laws, Executive Orders, directives, policies, standards, or regulations. The risk assessment at this stage in the security control selection process provides important inputs to determine the sufficiency of the security controls in the tailored baseline. Organizations are encouraged to make maximum use of the security control catalog in Appendix F to facilitate the process of enhancing security controls and/or adding controls to the tailored baseline.63 [18]

In selecting the security controls and control enhancements to supplement the tailored baseline, an organization can employ a requirements definition approach or a gap analysis approach. In the requirements definition approach, the organization acquires specific and credible threat64 [19] information (or makes a reasonable assumption) about the activities of adversaries with certain capabilities or attack potential (e.g., skill levels, expertise, available resources). To effectively withstand cyber attacks from adversaries with the stated capabilities or attack potential, the organization strives to achieve a certain level of security capability or cyber preparedness. Organizations can choose additional security controls and control enhancements from Appendix F to obtain such security capability or level of preparedness. In contrast to the requirements definition approach, the gap analysis approach begins with an organizational assessment of its current security capability or level of cyber preparedness. From that initial security capability assessment, the organization determines the types of threats it can reasonably expect to address. If the organization's current security capability or level of cyber preparedness is insufficient, the gap analysis determines the required capability and level of preparedness. The organization subsequently defines the security controls and control enhancements from Appendix F needed to achieve the desired capability or cyber preparedness level.65 [20]

There may be situations in which an organization is employing information technology beyond its ability to adequately protect essential missions and business functions (e.g., certain web-based, social networking, and collaborative computing-based technologies). That is, the organization cannot apply sufficient security controls within an information system to adequately reduce or mitigate risk. In those situations, an alternative strategy is needed to prevent the mission and business functions from being adversely affected; a strategy that considers the mission/business risks that result from an aggressive use of information technology. Restrictions on the types of technologies used and how the information system is employed provide an alternative method to reduce or mitigate risk when security controls cannot be implemented within technology/resource constraints, or when controls lack reasonable expectation of effectiveness against identified threat sources. Restrictions on the use of information systems and specific information technologies are in many situations, the only practical or reasonable course of action an organization can take in order to have the ability to carry out its assigned missions and business functions in the face of determined adversaries. Examples of use restrictions include:

  • Limiting the information an information system can process, store, or transmit or the manner in which an organizational mission or business function is automated;
  • Prohibiting external access to organizational information by removing selected information system components from the network (i.e., air gapping); and
  • Prohibiting public access to moderate-impact or high-impact information systems, unless an explicit determination is made authorizing such access.

Organizations document the decisions taken during the security control selection process, providing a sound rationale for those decisions. This documentation is essential when examining the security considerations for information systems with respect to potential mission/business impact. The resulting set of security controls along with the supporting rationale for selection decisions and any information system use restrictions are documented in the security plan for the information system. Documenting in the security plan any significant risk management decisions in the security control selection process is imperative in order for authorizing officials to have the necessary information to make credible, risk-based decisions regarding the authorization of organizational information systems. In addition, without such information, the understanding, assumptions, and rationale supporting those important risk decisions will, in all likelihood, not be available when the state of the information systems or environments of operation change, and the original risk decisions are revisited.

Figure 3-2 summarizes the security control selection process,66 [21] including tailoring of the initial security control baseline and any additional modifications to the baseline required based on an organizational assessment of risk.67 [22]

FIGURE 3-2: SECURITY CONTROL SELECTION PROCESS


Implementation Tip

Many organizations own and operate large and complex information systems, sometimes referred to as a system-of-systems. System architecture plays a key part in the security control selection process for these types of information systems. Organizations can address a large and complex system by dividing the system into two or more subsystems and applying the FIPS 199 security categorization and FIPS 200 impact level determination to each subsystem. Applying separate impact levels to each subsystem does not change the overall impact level of the information system; rather, it allows the constituent subsystems to receive a separate allocation of security controls instead of deploying higher impact controls across every subsystem. It is not valid to treat the subsystems as entirely independent entities, however, since the subsystems are interdependent and interconnected. The organization develops a security architecture to allocate security controls among the subsystems including monitoring and controlling communications at key internal boundaries within the large and complex system (or system-of-systems) and provides system-wide controls that meet or exceed the highest information system impact level of the constituent subsystems inheriting the security capability from those system-wide controls.

The organization considers that replicated subsystems within a large and complex information system may exhibit common vulnerabilities that can be exploited by a common threat source; thereby negating the redundancy that might be relied upon as a risk mitigation measure. The impact due to a security incident against one constituent subsystem might cascade and impact many subsystems at the same time. Risk levels can be adjusted upward or downward based on the actual deployment of security controls, the effectiveness of the controls, the environment in which the information system is operating, and how the organization is using its information technology.

New Development and Legacy Systems

The security control selection process described in this section can be applied to organizational information systems from two different perspectives: (i) new development; and (ii) legacy. For a new development system, the security control selection process is applied from a requirements definition perspective since the information system does not yet exist and the organization is conducting an initial security categorization. The security controls included in the security plan for the information system serve as a security specification for the organization and are expected to be incorporated into the system during the development and implementation phases of the system development life cycle. In contrast, for a legacy information system, the security control selection process is applied from a gap analysis perspective when the organization is anticipating significant changes to the system (e.g., during major upgrades, modifications, or outsourcing). Since the information system already exists, the organization in all likelihood has completed the security categorization and security control selection processes resulting in the documentation of a previously agreed-upon set of security controls in the security plan and the implementation of those controls within the information system. Therefore, the gap analysis can be applied in the following manner:

  • First, reconfirm or update as necessary, the FIPS 199 security category and FIPS 200 impact level for the information system based on the different types of information that are currently being processed, stored, or transmitted by the system.
  • Second, review the existing security plan that describes the security controls that are currently employed considering any updates to the security category and information system impact level as well as any changes to the organization, the system, or the operational environment. Reassess the risk and revise the security plan as necessary, including documenting any additional security controls that would be needed by the system to ensure that the risk to organizational operations, organizational assets, individuals, other organizations, and the Nation, remains at an acceptable level.
  • Third, implement the security controls described in the updated security plan, document in the plan of action and milestones any controls not implemented, and continue with the remaining steps in the Risk Management Framework in the same manner as a new development system.

Applying Gap Analyses to External Service Providers

The gap analysis perspective is also applied when interacting with external service providers. As described in Section 2.4, organizations are becoming increasingly reliant on external providers for critical information system services. Using the steps in the gap analysis described above, the organization can effectively use the acquisition process and appropriate contractual vehicles to require external providers to carry out, in collaboration with the organization, the security categorization and security control selection steps in the RMF. The resulting information can help determine what security controls the external provider either has in place or intends to implement for the information system services that are to be provided to the organization. If a security control deficit exists, the responsibility for adequately mitigating unacceptable risks arising from the use of external information system services remains with the authorizing official. In such situations, the organization can reduce the organizational risk to an acceptable level by:

  • Using the existing contractual vehicle to require the external provider to meet the additional security control requirements established by the organization;
  • Negotiating with the provider for additional security controls (including compensating controls) if the existing contractual vehicle does not provide for such added requirements; or
  • Employing alternative risk mitigation measures68 [23] within the organizational information system when a contract either does not exist or the contract does not provide the necessary leverage for the organization to obtain needed security controls.


3.4 MONITORING SECURITY CONTROLS

After the security controls are implemented and assessed for effectiveness, the information system is authorized for operation in accordance with the organization's risk management strategy (RMF Steps 3, 4, and 5). The organization subsequently initiates specific follow-on actions as part of a comprehensive continuous monitoring program. The continuous monitoring program includes an ongoing assessment of security control effectiveness to determine if there is a need to modify or update the current deployed set of security controls based on changes in the information system or its environment of operation (RMF Step 6). In particular, the organization revisits on a regular basis, the risk management activities described in the Risk Management Framework. In addition to the ongoing activities associated with the implementation of the Risk Management Framework, there are certain events which can trigger the immediate need to assess the security state of the information system and if required, modify or update the current security controls. These events include, for example:

  • An incident results in a breach to the information system, producing a loss of confidence by the organization in the confidentiality, integrity, or availability of information processed, stored, or transmitted by the system;
  • A newly identified, credible, information system-related threat to organizational operations and assets, individuals, other organizations, or the Nation is identified based on intelligence information, law enforcement information, or other credible sources of information;
  • Significant changes to the configuration of the information system through the removal or addition of new or upgraded hardware, software, or firmware or changes in the operational environment69 [24] potentially degrade the security state of the system; or
  • Significant changes to the organizational risk management strategy, information security policy, supported missions and/or business functions, or information being processed, stored, or transmitted by the information system.

When such events occur, organizations, at a minimum, take the following actions:70 [25]

The organization reexamines the FIPS 199 security category and FIPS 200 impact level of the information system to confirm that the security category and system impact level previously established and approved by the authorizing official are still valid. The resulting analysis may provide new insights as to the overall importance of the information system in allowing the organization to fulfill its mission/business responsibilities.
  • Assess the current security state of the information system and the risk to organizational operations and assets, individuals, other organizations, and the Nation.
The organization investigates the information system vulnerability (or vulnerabilities) exploited by the threat source (or potentially exploitable by a threat source) and the security controls currently implemented within the system as described in the security plan. The exploitation of information system vulnerabilities by a threat source may be traced to one or more factors including but not limited to: (i) the failure of currently implemented security controls; (ii) missing security controls; (iii) insufficient strength of security controls; and/or (iv) an increase in the capability of the threat source. Using the results from the assessment of the current security state, the organization reassesses the risks arising from use of the information system.
  • Plan for and initiate any necessary corrective actions.
Based on the results of an updated risk assessment, the organization determines what additional security controls and/or control enhancements or corrective actions for existing controls are necessary to adequately mitigate risk. The security plan for the information system is updated to reflect any initial changes to the original plan. A plan of action and milestones is developed for any noted weaknesses or deficiencies that are not immediately corrected and for the implementation of any security control upgrades or additional controls. After the security controls and/or control upgrades have been implemented and any other weaknesses or deficiencies corrected, the controls are assessed for effectiveness to determine if the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the information system. If necessary, the security plan is updated to reflect any additional corrective actions taken by the organization to mitigate risk.
  • Consider reauthorizing the information system.
Depending on the severity of the event, the adverse impact on organizational operations and assets, individuals, other organizations, and the Nation, and the extent of the corrective actions required to fix the identified weaknesses or deficiencies in the information system, the organization may need to consider reauthorizing the information system in accordance with the provisions of NIST Special Publication 800-37. The authorizing official makes the final determination on the need to reauthorize the information system in consultation with the risk executive (function), system and mission/business owners, the senior information security officer, and the chief information officer. The authorizing official may choose to conduct a limited reauthorization focusing only on the affected components of the information system and the associated security controls and/or control enhancements which have been changed during the update. Authorizing officials have sufficient information available from security control assessments to initiate, with an appropriate degree of confidence, necessary corrective actions.


Footnotes

  1. Tailoring guidance provides organizations with specific considerations on the applicability and implementation of individual security controls in the control baselines (see Section 3.3).
  2. NIST Special Publication 800-30 provides guidance on the assessment of risk.
  3. For legacy systems, some or all of the security controls selected may already be implemented.
  4. NIST Special Publication 800-53A provides guidance on assessing the effectiveness of security controls.
  5. NIST Special Publication 800-37 provides guidance on the security authorization of information systems.
  6. 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.
  7. 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.
  8. 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).
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.