Project 2 Cloud computing

Security and Privacy Controls for Federal Information Systems and Organizations comprises public domain material from the National Institute of Standards and Technology, U.S. Department

of Commerce. UMGC has modified this work and it is available under the original license.

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

______________________________________________________________________________________________ __

THE FUNDAMENTALS SECURITY CONTROL STRUCTURE, ORGANIZATION, BASELINES, AND ASSURANCE

his chapter presents the fundamental concepts associated with security control selection and specification including: (i) three-tiered risk management; (ii) the structure of security controls and the organization of the controls in the control catalog; (iii) security control

baselines; (iv) the identification and use of common security controls; (v) security controls in external environments; (vi) security control assurance; and (vii) future revisions to the security controls, the control catalog, and baseline controls.

MULTITIERED RISK MANAGEMENT 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 information systems. Risk-based approaches to security control selection and specification consider effectiveness, efficiency, and constraints due to applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidelines. To integrate the risk management process throughout the organization and more effectively address mission/business concerns, a three-tiered approach is employed that addresses risk at the: (i) organization level; (ii) mission/business process level; and (iii) information system level. The risk management process is carried out across the three tiers with the overall objective of continuous improvement in the organization’s risk-related activities and effective inter-tier and intra-tier communication among all stakeholders having a shared interest in the mission/business success of the organization. Figure 1 illustrates the three-tiered approach to risk management.

FIGURE 1: THREE-TIERED RISK MANAGEMENT APPROACH

T

PAGE 7

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

Tier 1 provides a prioritization of organizational missions/business functions which in turn drives investment strategies and funding decisions—promoting cost-effective, efficient information technology solutions consistent with the strategic goals and objectives of the organization and measures of performance. Tier 2 includes: (i) defining the mission/business processes needed to support the organizational missions/business functions; (ii) determining the security categories of the information systems needed to execute the mission/business processes; (iii) incorporating information security requirements into the mission/business processes; and (iv) establishing an enterprise architecture (including an embedded information security architecture) to facilitate the allocation of security controls to organizational information systems and the environments in which those systems operate. The Risk Management Framework (RMF), depicted in Figure 2, is the primary means for addressing risk at Tier 3.27 This publication focuses on Step 2 of the RMF, the security control selection process, in the context of the three tiers in the organizational risk management hierarchy.

FIGURE 2: RISK MANAGEMENT FRAMEWORK

The RMF addresses the security concerns of organizations related to the design, development, implementation, operation, and disposal of information systems and the environments in which those systems operate. The RMF consists of the following six steps:

27 NIST Special Publication 800-37 provides guidance on the implementation of the Risk Management Framework. A complete listing of all publications supporting the RMF and referenced in Figure 2 is provided in Appendix A.

PAGE 8

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

Step 1: Categorize the information system based on a FIPS Publication 199 impact assessment;28 Step 2: Select the applicable security control baseline based on the results of the security categorization and apply tailoring guidance (including the potential use of overlays);

Step 3: Implement the security controls and document the design, development, and implementation details for the controls;

Step 4: Assess the security controls 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;29

Step 5: Authorize information system operation based on a determination of risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation and use of the information system and the decision that this risk is acceptable; and

Step 6: Monitor the security controls in the information system and environment of operation on an ongoing basis to determine control effectiveness, changes to the system/environment, and compliance to legislation, Executive Orders, directives, policies, regulations, and standards.

SECURITY CONTROL 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 eighteen families.30 Each family contains security controls related to the general security topic of the family. A two-character identifier uniquely identifies security control families, for example, PS (Personnel Security). Security controls may involve aspects of policy, oversight, supervision, manual processes, actions by individuals, or automated mechanisms implemented by information systems/devices. Table 1 lists the security control families and the associated family identifiers in the security control catalog.31

TABLE 1: SECURITY CONTROL IDENTIFIERS AND FAMILY NAMES

28 CNSS Instruction 1253 provides security categorization guidance for national security systems. 29 NIST Special Publication 800-53A provides guidance on assessing the effectiveness of security controls. 30 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 Publication 200. One additional family (Program Management [PM] family) provides controls for information security programs required by FISMA. This family, while not specifically referenced in FIPS Publication 200, provides security controls at the organization level rather than the information system level. See Appendix G for a description of and implementation guidance for the PM controls. 31 Privacy controls listed in Appendix J, have an organization and structure similar to security controls, including the use of two-character identifiers for the eight privacy families.

PAGE 9

ID  FAMILY  ID  FAMILY 

AC  Access Control  MP  Media Protection 

AT  Awareness and Training  PE  Physical and environmental Protection 

AU  Audit and Accountability  PL  Planning 

CA  Security assessment and Authorization  PS  Personnel Security 

CM  Configuration Management  RA  Risk Assessment 

CP  Contingency Planning  SA  System and Services Acquisition 

IA  Identification and Authentication  SC  System and Communications Protection 

IR  Incident Response  SI  System and Information Integrity 

MA  Maintenance  PM  Program Management 

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

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-3 CONTENT OF AUDIT RECORDS

Control: The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event.

Supplemental Guidance: Audit record content that may be necessary to satisfy the requirement of this control includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). Related controls: AU-2, AU-8, AU-12, SI-11. Control Enhancements:

(1) CONTENT OF AUDIT RECORDS | ADDITIONAL AUDIT INFORMATION The information system generates audit records containing the following additional information: [Assignment: organization-defined additional, more detailed information]. Supplemental Guidance: Detailed information that organizations may consider in audit records includes, for example, full-text recording of privileged commands or the individual identities of group account users. Organizations consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. This facilitates the use of audit trails and audit logs by not including information that could potentially be misleading or could make it more difficult to locate information of interest.

(2) CONTENT OF AUDIT RECORDS | CENTRALIZED MANAGEMENT OF PLANNED AUDIT RECORD CONTENT The information system provides centralized management and configuration of the content to be captured in audit records generated by [Assignment: organization-defined information system components].

Supplemental Guidance: This control enhancement requires that the content to be captured in audit records be configured from a central location (necessitating automation). Organizations coordinate the selection of required audit content to support the centralized management and configuration capability provided by the information system. Related controls: AU-6, AU-7.

References: None. Priority and Baseline Allocation:

P1 LOW AU-3 MOD AU-3 (1) HIGH AU-3 (1) (2)

The control section prescribes specific security-related activities or actions to be carried out by organizations or by information systems. The term information system refers to those functions that generally involve the implementation of information technology (e.g., hardware, software, and firmware). Conversely, the term organization refers to activities that are generally process- driven or entity-driven—that is, the security control is generally implemented through human or procedural-based actions. Security controls that use the term organization may still require some degree of automation to be fulfilled. Similarly, security controls that use the term information system may have some elements that are process-driven or entity-driven. Using the terms organization and/or information system does not preclude the application of security controls at any of the tiers in the risk management hierarchy (i.e., organization level, mission/business process level, information system level), as appropriate.

CHAPTER 2 PAGE 10

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

For some security controls in the control catalog, a degree of flexibility is provided by allowing organizations to define values for certain parameters associated with the controls. This flexibility is achieved through the use of assignment and selection statements embedded within the security controls and control enhancements. Assignment and selection statements provide organizations with the capability to tailor security controls and control enhancements based on: (i) security requirements to support organizational missions/business functions and operational needs; (ii) risk assessments and organizational risk tolerance; and (iii) security requirements originating in federal laws, Executive Orders, directives, policies, regulations, standards, or guidelines.32

For example, organizations can specify additional information needed for audit records to support audit event processing. See the AU-3(1) example above (i.e., [Assignment: organization-defined additional, more detailed information]). These assignments may include particular actions to be taken by information systems in the event of audit failures, the frequency of conducting system backups, restrictions on password use, or the distribution list for organizational policies and procedures.33 Once specified,34 the organization-defined values for assignment and selection statements become part of the security control, and the control implementation is assessed against the completed control statement. Assignment statements offer a high degree of flexibility by allowing organizations to specify parameter values, without requiring those values to be one of two or more specific predefined choices. In contrast, selection statements narrow the potential input values by providing a specific list of items from which organizations must choose.35

The supplemental guidance section provides non-prescriptive, additional information for a specific security control. Organizations can apply the supplemental guidance as appropriate, when defining, developing, and/or implementing security controls. The supplemental guidance can provide important considerations for implementing security controls in the context of operational environments, mission/business requirements, or assessments of risk and can also explain the purpose or meaning of particular controls. Security control enhancements may also contain supplemental guidance when the guidance is not applicable to the entire control but instead focused on a particular control enhancement. The supplemental guidance sections for security controls and control enhancements may contain a list of related controls. Related controls: (i) directly impact or support the implementation of a particular security control or control enhancement; (ii) address a closely related security capability; or (iii) are referenced in the supplemental guidance. Security control enhancements are by definition related to the base control. Related controls that are listed in the supplemental guidance for the base controls are not repeated in the supplemental guidance for the control enhancements. However, there may be related controls identified for control enhancements that are not listed in the base control.

The security control enhancements section provides statements of security capability to: (i) add functionality/specificity to a control; and/or (ii) increase the strength of a control. In both cases, control enhancements are used in information systems and environments of operation requiring

32 In general, organization-defined parameters used in assignment and selection statements in the basic security controls apply also to all control enhancements associated with those controls. 33 Organizations determine whether specific assignment or selection statements are completed at Tier 1 (organization level), Tier 2 (mission/business process level), Tier 3 (information system level), or a combination thereof. 34 Organizations may choose to define specific values for security control parameters in policies, procedures, or guidance (which may be applicable to more than one information system) referencing the source documents in the security plan in lieu of explicitly completing the assignment/selection statements within the control as part of the plan. 35 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.

PAGE 11

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

greater protection than provided by the base control due to the potential adverse organizational impacts or when organizations seek additions to the base control functionality/specificity based on organizational assessments of risk. Security control enhancements are numbered sequentially within each control so that the enhancements can be easily identified when selected to supplement the base control. Each security control enhancement has a short subtitle to indicate the intended security capability provided by the control enhancement. In the AU-3 example, if the first control enhancement is selected, the control designation becomes AU-3(1). The numerical designation of a control enhancement is used only to identify the particular enhancement within the control. The designation is not indicative of either the strength of the control enhancement or any hierarchical relationship among the enhancements. Control enhancements are not intended to be selected independently (i.e., if a control enhancement is selected, then the corresponding base security control must also be selected). This intent is reflected in the baseline specifications in Appendix D and in the baseline allocation section under each control in Appendix F.

The references section includes a list of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidelines (e.g., OMB Circulars/Memoranda, Homeland Security Presidential Directives, FIPS Publications, and NIST Special Publications) that are relevant to a particular security control.36 The references provide federal legislative and policy mandates as well as supporting information for the implementation of security controls and control enhancements. The references section also contains pertinent websites for organizations to use in obtaining additional information for security control implementation and assessment.

The priority and security control baseline allocation section provides: (i) the recommended priority codes used for sequencing decisions during security control implementation; and (ii) the initial allocation of security controls and control enhancements to the baselines. Organizations can use the priority code designation associated with each security control to assist in making sequencing decisions for control implementation (i.e., a Priority Code 1 [P1] control has a higher priority for implementation than a Priority Code 2 [P2] control, a Priority Code 2 [P2] control has a higher priority for implementation than a Priority Code 3 [P3] control, and a Priority Code 0 [P0] indicates the security control is not selected in any baseline). This recommended sequencing prioritization helps to ensure that the foundational security controls upon which other controls depend are implemented first, thus enabling organizations to deploy controls in a more structured and timely manner in accordance with available resources. The implementation of security controls by sequence priority code does not imply the achievement of any defined level of risk mitigation until all of the security controls in the security plan have been implemented. The priority codes are intended only for implementation sequencing, not for making security control selection decisions.

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 most cost-effective, appropriate set of security controls, which if implemented and determined to be effective, would mitigate risk while complying with security requirements defined by applicable federal laws, Executive Orders, regulations, policies, directives, or standards (e.g., FISMA, OMB Circular A-130, HSPD-12, FIPS Publication 200). There is no one correct set of security controls that addresses all organizational security concerns in all situations. Selecting the most appropriate set of security controls for a specific situation or

36 Publications listed in the references section refer to the most recent versions of the publications. References are provided to assist organizations in applying the security controls and are not intended to be inclusive or complete.

PAGE 12

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

information system to adequately mitigate risk is an important task that requires a fundamental understanding of organizational mission/business priorities, the mission and business functions the information systems will support, and the environments of operation where the systems will reside. With that understanding, organizations can demonstrate how to most effectively assure the confidentiality, integrity, and availability of organizational information and information systems in a manner that supports mission/business needs while demonstrating due diligence. Selecting, implementing, and maintaining an appropriate set of security controls to adequately protect the information systems employed by organizations requires strong collaboration with system owners to understand ongoing changes to missions/business functions, environments of operation, and how the systems are used.

To assist organizations in making the appropriate selection of security controls for information systems, 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 information systems determined in accordance with FIPS Publication 199 and FIPS Publication 200, respectively.37 Appendix D provides a listing of the security control baselines. Three security control baselines have been identified corresponding to the low-impact, moderate-impact, and high-impact information systems using the high water mark defined in FIPS Publication 200 and used in Section 3.1 of this document to provide an initial set of security controls for each impact level.38

Appendix F provides a comprehensive catalog of security controls for information systems and organizations, arranged by control families. Chapter Three provides additional information on how to use FIPS Publication 199 security categories and FIPS Publication 200 system impact levels in applying the tailoring guidance to the baseline security controls to achieve adequate risk mitigation. Tailoring guidance, described in Section 3.2, helps organizations to customize the security control baselines selected using the results from organizational assessments of risk. Baseline tailoring actions include: (i) identifying and designating common controls; (ii) applying scoping considerations; (iii) selecting compensating controls; (iv) assigning specific values to security control parameters; (v) supplementing initial baselines with additional security controls or control enhancements; and (vi) providing additional information for control implementation.

37 CNSS Instruction 1253 provides guidance on security control baselines for national security systems. 38 The baseline security controls contained in Appendix D are not necessarily absolutes in that the guidance described in Section 3.2 provides organizations with the ability to tailor controls in accordance with the terms and conditions established by their authorizing officials and documented in their respective security plans.

Implementation Tip

There are security controls and control enhancements that appear in the security control catalog (Appendix F) that are found in only higher-impact baselines or are not used in any of the baselines. These additional security controls and control enhancements for information systems are available to organizations and can be used in tailoring security control baselines to achieve the needed level of protection in accordance with organizational assessments of risk. The set of security controls in the security plan must be sufficient to adequately mitigate risks to organizational operations and assets, individuals, other organizations, and the Nation based on the organizational risk tolerance.

PAGE 13

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

______________________________________________________________________________________________ _ SECURITY CONTROL DESIGNATIONS

There are three distinct types of designations related to the security controls in Appendix F that define: (i) the scope of applicability for the control; (ii) the shared nature of the control; and (iii) the responsibility for control development, implementation, assessment, and authorization. These designations include common controls, system-specific controls, and hybrid controls.

Common controls are security controls whose implementation results in a security capability that is inheritable by one or more organizational information systems. Security controls are deemed inheritable by information systems or information system components when the systems or components receive protection from the implemented controls but the controls are developed, implemented, assessed, authorized, and monitored by entities other than those responsible for the systems or components—entities internal or external to the organizations where the systems or components reside. Security capabilities provided by common controls can be inherited from many sources including, for example, organizations, organizational mission/business lines, sites, enclaves, environments of operation, or other information systems. Many of the controls needed to protect organizational information systems (e.g., security awareness training, incident response plans, physical access to facilities, rules of behavior) are excellent candidates for common control status. In addition, there can also be a variety of technology-based common controls (e.g., Public Key Infrastructure [PKI], authorized secure standard configurations for clients/servers, access control systems, boundary protection, cross-domain solutions). By centrally managing and documenting the development, implementation, assessment, authorization, and monitoring of common controls, security costs can be amortized across multiple information systems.

The organization assigns responsibility for common controls to appropriate organizational officials (i.e., common control providers) and coordinates the development, implementation, assessment, authorization, and monitoring of the controls.39 The identification of common controls is most effectively accomplished as an organization-wide exercise with the active involvement of chief information officers, senior information security officers, the risk executive (function), authorizing officials, information owners/stewards, information system owners, and information system security officers. The organization-wide exercise considers the security categories of the information systems within the organization and the security controls necessary to adequately mitigate the risks arising from the use of those systems (see baseline security controls in Section 2.3).40 Common control identification for the controls that impact multiple information systems, but not all systems across the organization could benefit from taking a similar approach. Key stakeholders collaborate to identify opportunities to effectively employ common controls at the mission/business line, site, or enclave level.

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. If the common controls are not implemented at the highest impact level of the information systems, system owners will need to factor this situation into their assessments of risk and take appropriate risk mitigation actions (e.g., adding security controls or control enhancements, changing assigned values of security control parameters, implementing compensating controls, or changing certain aspects of mission/business processes). Implementing common controls that are less than

39 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). 40 Each common control identified by the organization is reviewed for applicability to each specific organizational information system, typically by information system owners and authorizing officials.

CHAPTER 2 PAGE 14

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

effective or that provide insufficient security capability for higher-impact information systems can have a significant adverse impact on organizational missions or business functions.

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.41 Organizations have the flexibility to describe common controls in a single document or in multiple documents with references or pointers, as appropriate. In the case of multiple documents, the documents describing common controls are included as attachments to the information security program plan. If the information security program plan contains multiple documents, organizations specify in each document the organizational officials responsible for 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.

Common controls, whether employed in organizational information systems or environments of operation, are authorized by senior officials with at least the same level of authority/responsibility for managing risk as the authorization officials for information systems inheriting the controls. Authorization results for common controls are shared with the appropriate information system owners and authorizing officials. A plan of action and milestones is developed and maintained for common controls that have been determined through independent assessments, to be less than effective. Information system owners dependent on common controls that are less than effective consider whether they are willing to accept the associated risk or if additional tailoring is required to address the weaknesses or deficiencies in the controls. Such risk-based decisions are influenced by available resources, the trust models employed by the organization, and the risk tolerance of authorizing officials and the organization.42

41 Information security program plans are described in Appendix G. Organizations ensure that any security capabilities provided by common controls (i.e., security capabilities inheritable by other organizational entities) are described in sufficient detail to facilitate adequate understanding of the control implementation by inheriting entities. 42 NIST Special Publication 800-39 provides guidance on trust models, including validated, direct historical, mediated, and mandated trust models.

Implementation Tip

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

PAGE 15

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

Common controls are subject to the same assessment and monitoring requirements as system- specific controls employed in individual organizational information systems. Because common controls impact more than one system, a higher degree of confidence regarding the effectiveness of those controls may be required.

Security controls not designated as common controls are considered system-specific 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 security controls when one part of the control is common and another part of the control is system-specific. For example, an organization may choose to implement the Incident Response Policy and Procedures security control (IR-1) as a hybrid control with the policy portion of the control designated as common and the procedures portion of the control designated as system-specific. Hybrid controls may also serve as predefined templates for further control refinement. Organizations may choose, for example, to implement the Contingency Planning security control (CP-2) as a predefined template for a generalized contingency plan for all organizational information systems with 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 organizations in implementation and assessment costs as well as a more consistent application of security controls organization-wide. While security control partitioning into common, hybrid, and system-specific controls is straightforward and intuitive conceptually, the actual application takes a significant amount of planning and coordination. At the information system level, determination of common, hybrid, or system-specific security controls follows the development of a tailored baseline. It is necessary to first determine what security capability is needed before organizations assign responsibility for how security controls are implemented, operated, and maintained.

Security plans for individual information systems identify which security controls required for those systems have been designated by organizations 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 common controls. These implementation details are identified and described in the security plans for the individual information systems. Senior information security officers for organizations coordinate with common control providers (e.g., facility/site managers, human resources managers, intrusion detection system owners) to ensure that the required controls are developed, implemented, and assessed for effectiveness. Collectively, the security plans for individual information systems and the organization-wide information security program plans provide complete coverage for all security controls employed within organizations.

The determination as to whether a security control is a common, hybrid, or system-specific is context-based. Security controls cannot be determined to be common, hybrid, or system-specific simply based on reviewing the language of the control. For example, a control may be system- specific for a particular information system, but at the same time that control could be a common control for another system, which would inherit the control from the first system. One indicator of whether a system-specific control may also be a common control for other information systems is to consider who or what depends on the functionality of that particular control. If a certain part of an information system or solution external to the system boundary depends on the control, then that control may be a candidate for common control identification.

PAGE 16

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

EXTERNAL SERVICE PROVIDERS Organizations are becoming increasingly reliant on information system services provided by external providers to conduct important missions and business functions. External information system services are computing and information technology services implemented outside of the traditional security authorization boundaries established by organizations for their information systems. Those traditional authorization boundaries linked to physical space and control of assets, are being extended (both physically and logically) with the growing use of external services. In this context, external services can be provided by: (i) entities within the organization but outside of the security authorization boundaries established for organizational information systems; (ii) entities outside of the organization either in the public sector (e.g., federal agencies) or private sector (e.g., commercial service providers); or (iii) some combination of the public and private sector options. External information system services include, for example, the use of service- oriented architectures (SOAs), cloud-based services (infrastructure, platform, software), or data center operations. External information system services may be used by, but are typically not part of, organizational information systems. In some situations, external information system services may completely replace or heavily augment the routine functionality of internal organizational information systems.

FISMA and OMB policies require that federal agencies using external service providers to process, store, or transmit federal information or operate information systems on behalf of the

Implementation Tip

• Organizations consider the inherited risk from the use of common controls. Security plans, security assessment reports, and plans of action and milestones for common controls (or a summary of such information) are made available to information system owners (for systems inheriting the controls) after the information is reviewed and approved by the senior official or executive responsible and accountable for the controls.

• Organizations ensure that common control providers keep control status information current since the controls typically support multiple organizational information systems. Security plans, security assessment reports, and plans of action and milestones for common controls are used by authorizing officials to make risk-based decisions in the security authorization process for their information systems and therefore, inherited risk from common controls is a significant factor in such risk-based decisions.

• Organizations ensure that common control providers have the capability to rapidly broadcast changes in the status of common controls that adversely affect the protections being provided by and expected of the common controls. Common control providers inform system owners when problems arise in the inherited common controls (e.g., when an assessment or reassessment of a common control indicates the control is flawed or deficient in some manner, or when a new threat or attack method arises that renders the common control less than effective in protecting against the new threat or attack method).

• Organizations are encouraged to employ automated management systems to maintain records of the specific common controls employed in each organizational information system to enhance the ability of common control providers to rapidly communicate with system owners.

• If common controls are provided to organizations by entities external to the organization (e.g., shared and/or external service providers), arrangements are made with the external/shared service providers by the organization to obtain information on the effectiveness of the deployed controls. Information obtained from external organizations regarding effectiveness of common controls is factored into authorization decisions.

PAGE 17

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

federal government, assure that such use meets the same security requirements that federal agencies are required to meet. Security requirements for external service providers including the security controls for external information systems are expressed in contracts or other formal agreements.43 Organizations are responsible and accountable for the information security risk incurred by the use of information system services provided by external providers. Such risk is addressed by incorporating the Risk Management Framework (RMF) as part of the terms and conditions of the contracts with external providers. Organizations can require external providers to implement all steps in the RMF except the security authorization step, which remains an inherent federal responsibility directly linked to managing the information security risk related to the use of external information system services.44 Organizations can also require external providers to provide appropriate evidence to demonstrate that they have complied with the RMF in protecting federal information. However, federal agencies take direct responsibility for the overall security of such services by authorizing the information systems providing the services.

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, service-level agreements), licensing agreements, and/or supply chain exchanges. The growing use of external service providers and new relationships being forged with those providers present new and difficult challenges for organizations, especially in the area of information system security. These challenges include:

• Defining the types of external information system services provided to organizations;

• Describing how those external services are protected in accordance with the information security requirements of organizations; 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.

The degree of confidence that the risk from using external services is at an acceptable level depends on the trust that organizations place in external service providers. In some cases, the level of trust is based on the amount of direct control organizations are able to exert on external service providers with regard to employment of security controls necessary for the protection of the service/information and the evidence brought forth as to the effectiveness of those controls.45 The level of control is usually established by the terms and conditions of the contracts or service- level agreements with the external service providers and can range from extensive control (e.g., negotiating contracts or agreements that specify detailed security requirements for the providers) to very limited control (e.g., using contracts or service-level agreements to obtain commodity

43 Organizations consult the Federal Risk and Authorization Management Program (FedRAMP) when acquiring cloud services from external providers. FedRAMP addresses required security controls and independent assessments for a variety of cloud services. Additional information is available at http://www.fedramp.gov. 44 To effectively manage information security risk, organizations authorize information systems of external providers that are part of the information technologies or services (e.g., infrastructure, platform, or software) provided to the federal government. Security authorization requirements are expressed in the terms and conditions of contracts with external providers of those information technologies and services. 45 The level of trust that organizations place in external service providers 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). NIST Special Publication 800-39 describes different trust models that can be employed by organizations when establishing relationships with external service providers.

PAGE 18

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

services such as commercial telecommunications services).46 In other cases, levels of trust are based on factors that convince organizations that required security controls have been employed and that determinations of control effectiveness exist. For example, separately authorized external information system services provided to organizations through well-established lines of business relationships may provide degrees of trust in such services within the tolerable risk range of the authorizing officials and organizations using the services.

The provision of services by external providers may result in certain services without explicit agreements between organizations and the providers. Whenever explicit agreements are feasible and practical (e.g., through contracts, service-level agreements), organizations develop such agreements and require the use of the security controls in Appendix F of this publication. When organizations are not in a position to require explicit agreements with external service providers (e.g., services are imposed on organizations, services are commodity services), organizations establish and document explicit assumptions about service capabilities with regard to security. In situations where organizations are procuring information system services through centralized acquisition vehicles (e.g., governmentwide contracts by the General Services Administration or other preferred and/or mandatory acquisition organizations), it may be more efficient and cost- effective for contract originators to establish and maintain stated levels of trust with external service providers (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 from centralized contracts can take advantage of the negotiated levels of trust established by the procurement originators and thus avoid costly repetition of activities necessary to establish such trust.47 Centralized acquisition vehicles (e.g., contracts) may also require the active participation of organizations. For example, organizations may be required by provisions in contracts or agreements to install public key encryption-enabled client software recommended by external service providers.

Ultimately, the responsibility for adequately mitigating unacceptable risks arising from the use of external information system services remains with authorizing officials. Organizations require that appropriate chains of trust be established with external service providers when dealing with the many issues associated with information system security. Organizations establish and retain a level of trust that participating service providers in the potentially complex consumer-provider relationship provide adequate protection for the services rendered to organizations. The chain of trust can be complicated due to the number of entities participating in the consumer-provider relationship and the types of relationships between the parties. External service providers may also outsource selected services to other external entities, making the chain of trust more difficult and complicated to manage. Depending on the nature of the services, organizations may find it impossible to place significant trust in external providers. This situation is due not to any inherent untrustworthiness on the part of providers, but to the intrinsic level of risk in the services.48

46 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. Organizational assessments of risk and risk mitigation activities reflect this situation. 47 For example, procurement originators could authorize information systems providing external services to the federal government under the specific terms and conditions of the contracts. Federal agencies requesting such services under the terms of the contracts would not be required to reauthorize the information systems when acquiring such services (unless the request included services outside the scope of the original contracts). 48 There may also be risk in disallowing certain functionality because of security concerns. Security is merely one of multiple considerations in an overall risk determination.

PAGE 19

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

Where a sufficient level of trust cannot be established in the external services and/or providers, organizations can: (i) mitigate the risk by employing compensating controls; (ii) accept the risk within the level of organizational risk tolerance; (iii) transfer risk by obtaining insurance to cover potential losses; or (iv) avoid risk by choosing not to obtain the services from certain providers (resulting in performance of missions/business operations with reduced levels of functionality or possibly no functionality at all).49 For example, in the case of cloud-based information systems and/or services, organizations might require as a compensating control, that all information stored in the cloud be encrypted for added security of the information. Alternatively, organizations may require encrypting some of the information stored in the cloud (depending on the criticality or sensitivity of such information)—accepting additional risk but limiting the risk of not storing all information in an unencrypted form.

2.6 ASSURANCE AND TRUSTWORTHINESS Assurance and trustworthiness of information systems, system components, and information system services are becoming an increasingly important part of the risk management strategies developed by organizations. Whether information systems are deployed to support, for example, the operations of the national air traffic control system, a major financial institution, a nuclear power plant providing electricity for a large city, or the military services and warfighters, the systems must be reliable, trustworthy, and resilient in the face of increasingly sophisticated and pervasive threats. To understand how organizations achieve trustworthy systems and the role assurance plays in the trustworthiness factor, it is important to first define the term trust. Trust, in general, is the belief that an entity will behave in a predictable manner while performing specific functions, in specific environments, and under specified conditions or circumstances. The entity may be a person, process, information system, system component, system-of-systems, or any combination thereof.

From an information security perspective, trust is the belief that a security-relevant entity will behave in a predictable manner when satisfying a defined set of security requirements under specified conditions/circumstances and while subjected to disruptions, human errors, component faults and failures, and purposeful attacks that may occur in the environment of operation. Trust is usually determined relative to a specific security capability50 and can be decided relative to an individual system component or the entire information system. However, trust at the information system level is not achieved as a result of composing a security capability from a set of trusted system components—rather, trust at the system level is an inherently subjective determination that is derived from the complex interactions among entities (i.e., technical components, physical components, and individuals), taking into account the life cycle activities that govern, develop, operate, and sustain the system. In essence, to have trust in a security capability requires that there is a sufficient basis for trust, or trustworthiness, in the set of security-relevant entities that are to be composed to provide such capability.

Trustworthiness with respect to information systems, expresses the degree to which the systems can be expected to preserve with some degree of confidence, the confidentiality, integrity, and availability of the information that is being processed, stored, or transmitted by the systems across a range of threats. Trustworthy information systems are systems that are believed to be capable of operating within a defined risk tolerance despite the environmental disruptions, human errors,

49 Alternative providers offering a higher basis for trust, usually at a higher cost, may be available. 50 A security capability is a combination of mutually reinforcing security controls (i.e., safeguards/countermeasures) implemented by technical means (i.e., functionality in hardware, software, and firmware), physical means (i.e., physical devices and protective measures), and/or procedural means (i.e., procedures performed by individuals).

PAGE 20

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

structural failures, and purposeful attacks that are expected to occur in the environments in which the systems operate—systems that have the trustworthiness to successfully carry out assigned missions/business functions under conditions of stress and uncertainty.51

Two fundamental components affecting the trustworthiness of information systems are security functionality and security assurance. Security functionality is typically defined in terms of the security features, functions, mechanisms, services, procedures, and architectures implemented within organizational information systems or the environments in which those systems operate. Security assurance is the measure of confidence that the security functionality is implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system—thus possessing the capability to accurately mediate and enforce established security policies. Security controls address both security functionality and

51 While information is the primary area of concern, trustworthiness applies to the protections for all assets deemed critical by organizations. Furthermore, protections are provided by technology (i.e., hardware, software, firmware), physical elements (i.e., doors, locks, surveillance), and human elements (i.e., people, processes, procedures).

Security Capability

Organizations can consider defining a set of security capabilities as a precursor to the security control selection process. The concept of security capability is a construct that recognizes that the protection of information being processed, stored, or transmitted by information systems, seldom derives from a single safeguard or countermeasure (i.e., security control). In most cases, such protection results from the selection and implementation of a set of mutually reinforcing security controls. For example, organizations may wish to define a security capability for secure remote authentication. This capability can be achieved by the selection and implementation of a set of security controls from Appendix F (e.g., IA-2[1], IA-2[2], IA-2[8], IA-2[9], and SC-8[1]). Moreover, security capabilities can address a variety of areas that can include, for example, technical means, physical means, procedural means, or any combination thereof. Thus, in addition to the above functional capability for secure remote access, organizations may also need security capabilities that address physical means such as tamper detection on a cryptographic module or anomaly detection/analysis on an orbiting spacecraft.

As the number of security controls in Appendix F grows over time in response to an increasingly sophisticated threat space, it is important for organizations to have the ability to describe key security capabilities needed to protect core organizational missions/business functions, and to subsequently define a set of security controls that if properly designed, developed, and implemented, produce such capabilities. This simplifies how the protection problem is viewed conceptually. In essence, using the construct of security capability provides a shorthand method of grouping security controls that are employed for a common purpose or to achieve a common objective. This becomes an important consideration, for example, when assessing security controls for effectiveness.

Traditionally, assessments have been conducted on a control-by-control basis producing results that are characterized as pass (i.e., control satisfied) or fail (i.e., control not satisfied). However, the failure of a single control or in some cases, the failure of multiple controls, may not affect the overall security capability needed by an organization. Moreover, employing the broader construct of security capability allows an organization to assess the severity of vulnerabilities discovered in its information systems and determine if the failure of a particular security control (associated with a vulnerability) or the decision not to deploy a certain control, affects the overall capability needed for mission/business protection. It also facilitates conducting root cause analyses to determine if the failure of one security control can be traced to the failure of other controls based on the established relationships among controls. Ultimately, authorization decisions (i.e., risk acceptance decisions) are made based on the degree to which the desired security capabilities have been effectively achieved and are meeting the security requirements defined by an organization. These risk-based decisions are directly related to organizational risk tolerance that is defined as part of an organization’s risk management strategy.

PAGE 21

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

security assurance. Some controls focus primarily on security functionality (e.g., PE-3, Physical Access Control; IA-2, Identification and Authentication; SC-13, Cryptographic Protection; AC-2, Account Management). Other controls focus primarily on security assurance (e.g., CA-2, Security Assessment; SA-17, Developer Security Architecture and Design; CM-3, Configuration Change Control). Finally, certain security controls can support security functionality and assurance (e.g., RA-5, Vulnerability Scanning; SC-3, Security Function Isolation; AC-25, Reference Monitor). Security controls related to functionality are combined to develop a security capability with the assurance-related controls implemented to provide a degree of confidence in the capability within the organizational risk tolerance.

Assurance Evidence—From Developmental and Operational Activities Organizations obtain security assurance by the actions taken by information system developers, implementers, operators, maintainers, and assessors. Actions by individuals and/or groups during the development/operation of information systems produce security evidence that contributes to the assurance, or measures of confidence, in the security functionality needed to deliver the security capability. The depth and coverage of these actions (as described in Appendix E) also contribute to the efficacy of the evidence and measures of confidence. The evidence produced by developers, implementers, operators, assessors, and maintainers during the system development life cycle (e.g., design/development artifacts, assessment results, warranties, and certificates of evaluation/validation) contributes to the understanding of the security controls implemented by organizations.

The strength of security functionality52 plays an important part in being able to achieve the needed security capability and subsequently satisfying the security requirements of organizations. Information system developers can increase the strength of security functionality by employing as part of the hardware/software/firmware development process: (i) well-defined security policies and policy models; (ii) structured/rigorous design and development techniques; and (iii) sound system/security engineering principles. The artifacts generated by these development activities (e.g., functional specifications, high-level/low-level designs, implementation representations [source code and hardware schematics], the results from static/dynamic testing and code analysis) can provide important evidence that the information systems (including the components that compose those systems) will be more reliable and trustworthy. Security evidence can also be generated from security testing conducted by independent, accredited, third-party assessment organizations (e.g., Common Criteria Testing Laboratories, Cryptographic/Security Testing Laboratories, and other assessment activities by government and private sector organizations).53

In addition to the evidence produced in the development environment, organizations can produce evidence from the operational environment that contributes to the assurance of functionality and ultimately, security capability. Operational evidence includes, for example, flaw reports, records of remediation actions, the results of security incident reporting, and the results of organizational continuous monitoring activities. Such evidence helps to determine the effectiveness of deployed security controls, changes to information systems and environments of operation, and compliance with federal legislation, policies, directives, regulations, and standards. Security evidence,

52 The security strength of an information system component (i.e., hardware, software, or firmware) is determined by the degree to which the security functionality implemented within that component is correct, complete, resistant to direct attacks (strength of mechanism), and resistant to bypass or tampering. 53 For example, third-party assessment organizations assess cloud services and service providers in support of the Federal Risk and Authorization Management Program (FedRAMP). Common Criteria Testing Laboratories test and evaluate information technology products using ISO/IEC standard 15408. Cryptographic/Security Testing Laboratories test cryptographic modules using the FIPS 140-2 standard.

PAGE 22

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

whether obtained from development or operational activities, provides a better understanding of security controls implemented and used by organizations. Together, the actions taken during the system development life cycle by developers, implementers, operators, maintainers, and assessors and the evidence produced as part of those actions, help organizations to determine the extent to which the security functionality within their information systems is implemented correctly, operating as intended, and producing the desired outcome with respect to meeting stated security requirements and enforcing or mediating established security policies—thus providing greater confidence in the security capability.

With regard to the security evidence produced, the depth and coverage of such evidence can affect the level of assurance in the functionality implemented. Depth and coverage are attributes associated with assessment methods and the generation of security evidence. Assessment methods can be applied to developmental and operational assurance. For developmental assurance, depth is associated with the rigor, level of detail, and formality of the artifacts produced during the design and development of the hardware, software, and firmware components of information systems (e.g., functional specifications, high-level design, low-level design, source code). The level of detail available in development artifacts can affect the type of testing, evaluation, and analysis conducted during the system development life cycle (e.g., black-box testing, gray-box testing, white-box testing, static/dynamic analysis). For operational assurance, the depth attribute addresses the number and types of assurance-related security controls selected and implemented. In contrast, the coverage attribute is associated with the assessment methods employed during development and operations, addressing the scope and breadth of assessment objects included in the assessments (e.g., number/types of tests conducted on source code, number of software modules reviewed, number of network nodes/mobile devices scanned for vulnerabilities, number of individuals interviewed to check basic understanding of contingency responsibilities).54

Addressing assurance-related controls during acquisition and system development can help organizations to obtain sufficiently trustworthy information systems and components that are more reliable and less likely to fail. These controls include ensuring that developers employ sound systems security engineering principles and processes including, for example, providing a comprehensive security architecture, and enforcing strict configuration management and control of information system and software changes. Once information systems are deployed, assurance- related controls can help organizations to continue to have confidence in the trustworthiness of the systems. These controls include, for example, conducting integrity checks on software and firmware components, conducting penetration testing to find vulnerabilities in organizational

54 NIST Special Publication 800-53A provides guidance on the generation of security evidence related to security assessments conducted during the system development life cycle.

The Compelling Argument for Assurance

Organizations specify assurance-related controls to define activities performed to generate relevant and credible evidence about the functionality and behavior of organizational information systems and to trace the evidence to the elements that provide such functionality/behavior. This evidence is used to obtain a degree of confidence that the systems satisfy stated security requirements—and do so while effectively supporting the organizational missions/business functions while being subjected to threats in the intended environments of operation.

PAGE 23

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

information systems, monitoring established secure configuration settings, and developing policies/procedures that support the operation and use of the systems.

The concepts described above, including security requirements, security capability, security controls, security functionality, and security assurance, are brought together in a model for trustworthiness for information systems and system components. Figure 3 illustrates the key components in the model and the relationship among the components.

FIGURE 3: TRUSTWORTHINESS MODEL

PAGE 24

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

Developmental and Operational Activities to Achieve High Assurance Raising the bar on assurance can be difficult and costly for organizations—but sometimes essential for critical applications, missions, or business functions. Determining what parts of the organization’s information technology infrastructure demand higher assurance of implemented security functionality is a Tier 1/Tier 2 risk management activity (see Figure 1 in Chapter Two). This type of activity occurs when organizations determine the security requirements necessary to protect organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation. Determining security requirements and the associated security capabilities needed to generate the appropriate protection is an integral part of the organizational risk management process described in NIST Special Publication 800- 39—specifically, in the development of the risk response strategy following the risk framing and risk assessment steps (where organizations establish priorities, assumptions, constraints, risk tolerance and assess threats, vulnerabilities, mission/business impacts, and likelihood of threat occurrence). After the security requirements and security capabilities are determined at Tiers 1 and 2 (including the necessary assurance requirements to provide measures of confidence in the desired capabilities), those requirements/capabilities are reflected in the design of the enterprise architecture, the associated mission/business processes, and the organizational information systems that are needed to support those processes. Organizations can use the Risk Management Framework (RMF), described in NIST Special Publication 800-37, to ensure that the appropriate assurance levels are achieved for the information systems and system components deployed to carry out core missions and business functions. This is primarily a Tier 3 activity but can have some overlap with Tiers 1 and 2, for example, in the area of common control selection.

Trustworthy information systems are difficult to build from a software and systems development perspective. However, there are a number of design, architectural, and implementation principles that, if used, can result in more trustworthy systems. These core security principles include, for example, simplicity, modularity, layering, domain isolation, least privilege, least functionality, and resource isolation/encapsulation. Information technology products and systems exhibiting a higher degree of trustworthiness (i.e., products/systems having the requisite security functionality and security assurance) are expected to exhibit a lower rate of latent design/implementation flaws and a higher degree of penetration resistance against a range of threats including, for example, sophisticated cyber attacks, natural disasters, accidents, and intentional/unintentional errors.55 The vulnerability and susceptibility of organizational missions/business functions and supporting information systems to known threats, the environments of operation where those systems are deployed, and the maximum acceptable level of information security risk, guide the degree of trustworthiness needed.

Appendix E describes the minimum assurance requirements for federal information systems and organizations and highlights the assurance-related controls in the security control baselines in Appendix D needed to ensure that the requirements are satisfied.56

55 Organizations also rely to a great extent on security assurance from an operational perspective as illustrated by the assurance-related controls in Tables E-1 through E-3. Operational assurance is obtained by other than developmental actions including for example, defining and applying security configuration settings on information technology products, establishing policies and procedures, assessing security controls, and conducting a rigorous continuous monitoring program. In some situations, to achieve the necessary security capability with weak or deficient information technology, organizations compensate by increasing their operational assurance. 56 CNSS Instruction 1253 designates security control baselines for national security systems. Therefore, the assurance- related controls in the baselines established for the national security community, if so designated, may differ from those controls designated for non-national security systems.

PAGE 25

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

REVISIONS AND EXTENSIONS The security controls listed in this publication represent the state-of-the-practice safeguards and countermeasures for federal information systems and organizations. The security controls57 will be carefully reviewed and revised periodically to reflect:

• Experience gained from using the controls;

• New federal legislation, Executive Orders, directives, regulations, or policies;

• Changing security requirements;

• Emerging threats, vulnerabilities, and attack methods; and

• Availability of new technologies.

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 is addressed by requiring that proposed modifications to security controls go through a

57 The privacy controls listed in Appendix J will also be updated on a regular basis using similar criteria.

Why Assurance Matters

The importance of security assurance can be described by using the example of a light switch on a wall in the living room of your house. Individuals can observe that by simply turning the switch on and off, the switch appears to be performing according to its functional specification. This is analogous to conducting black-box testing of security functionality in an information system or system component. However, the more important questions might be— • Does the light switch do anything else besides what it is supposed to do? • What does the light switch look like from behind the wall? • What types of components were used to construct the light switch and how was the switch

assembled? • Did the switch manufacturer follow industry best practices in the development process?

This example is analogous to the many developmental activities that address the quality of the security functionality in an information system or system component including, for example, design principles, coding techniques, code analysis, testing, and evaluation.

The security assurance requirements and associated assurance-related controls in Appendix E address the light switch problem from the front of the wall perspective, and potentially from the behind the wall perspective, depending on the measure of confidence needed about the component in question. For organizational missions/business functions that are less critical (i.e., low impact), lower levels of assurance might be appropriate. However, as missions/business functions become more important (i.e., moderate or high impact) and information systems and organizations become susceptible to advanced persistent threats by high-end adversaries, increased levels of assurance may be required. In addition, as organizations become more dependent on external information system services and providers, assurance becomes more important—providing greater insight and measures of confidence to organizations in understanding and verifying the security capability of external providers and the services provided to the federal government. Thus, when the potential impact to organizational operations and assets, individuals, other organizations, or the Nation is great, an increasing level of effort must be directed at what is happening behind the wall.

PAGE 26

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

rigorous public review process to obtain both public and private sector feedback and to build consensus for such change. This provides over time, a stable, flexible, and technically sound set of security controls for the federal government, contractors, and any other organizations using the security control catalog.

PAGE 27

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

______________________________________________________________________________________________

__

THE PROCESS SELECTION AND SPECIFICATION OF SECURITY CONTROLS

his chapter describes the process of selecting and specifying security controls and control enhancements for organizational information systems to include: (i) selecting appropriate security control baselines; (ii) tailoring the baselines; (iii) documenting the security control

selection process; and (iv) applying the control selection process to new development and legacy systems.

SELECTING SECURITY CONTROL BASELINES In preparation for selecting and specifying the appropriate security controls for organizational information systems and their respective environments of operation, organizations first determine the criticality and sensitivity of the information to be processed, stored, or transmitted by those systems. This process, known as security categorization, is described in FIPS Publication 199.58 The security categorization standard is based on a simple and well-established concept—that is, determining the potential adverse impact for organizational information systems. The results of security categorization help guide and inform the selection of appropriate security controls (i.e., safeguards and countermeasures) to adequately protect those information systems. The security controls selected for information systems are commensurate with the potential adverse impact on organizational operations and assets, individuals, other organizations, or the Nation if there is a loss of confidentiality, integrity, or availability. FIPS Publication 199 requires organizations to categorize information systems as low-impact, moderate-impact, or high-impact for the stated security objectives of confidentiality, integrity, and availability (RMF Step 1). The potential impact values assigned to the security objectives are the highest values (i.e., high water mark) from the security categories that have been determined for each type of information processed, stored, or transmitted by those information systems.59 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 (introduced in FIPS Publication 199) is used in FIPS Publication 200 to determine the impact level of the information system for the express purpose of selecting the applicable security control baseline from one of the three baselines identified in Appendix D.60 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

58 CNSS Instruction 1253 provides security categorization guidance for national security systems. 59 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. 60 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, security controls are not categorized by security objective. Rather, the security controls are grouped into baselines to provide a general protection capability for classes of information systems based on impact level.

T

PAGE 28

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

no security objective is greater than moderate. Finally, a high-impact system is an information system in which at least one security objective is high.

Once the impact level of the information system is determined, organizations begin the security control selection process (RMF Step 2). The first step in selecting and specifying security controls for the information system is to choose the appropriate security control baseline.61 The selection of the security control baseline is based on the FIPS 200 impact level of the information system as determined by the security categorization process described above. The organization selects one of three security control baselines from Appendix D corresponding to the low-impact, moderate-impact, or high-impact rating of the information system.62 Note that not all security controls are assigned to baselines, as indicated in Table D-2 by the phrase not selected. Similarly, as illustrated in Tables D-3 through D-19, not all control enhancements are assigned to baselines. Those control enhancements that are assigned to baselines are so indicated by an “x” in the low, moderate, or high columns. The use of the term baseline is intentional. The security controls and control enhancements in the baselines are a starting point from which controls/enhancements may be removed, added, or specialized based on the tailoring guidance in Section 3.2.

The security control baselines in Appendix D address the security needs of a broad and diverse set of constituencies (including individual users and organizations). Some assumptions that generally underlie the baselines in Appendix D include, for example: (i) the environments in which organizational information systems operate; (ii) the nature of operations conducted by organizations; (iii) the functionality employed within information systems; (iv) the types of threats facing organizations, missions/business processes, and information systems; and (v) the type of information processed, stored, or transmitted by information systems. Articulating the underlying assumptions is a key element in the initial risk framing step of the risk management process described in NIST Special Publication 800-39. Some of the assumptions that underlie the baselines in Appendix D include:

61 The general security control selection process may be augmented or further detailed by additional sector-specific guidance as described in Section 3.3, Creating Overlays, and Appendix I, template for developing overlays. 62 CNSS Instruction 1253 provides security control baselines for national security systems.

Implementation Tip

To determine the impact level of an information system:

• First, determine the different types of information that are processed, stored, or transmitted by the information system. NIST Special Publication 800-60 provides common information types.

• Second, using the impact values in FIPS Publication 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 value 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 value among the three security objectives in the system security categorization.

Note: For national security systems, organizations use CNSSI 1253 for security categorization.

PAGE 29

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

• Information systems are located in physical facilities;

• User data/information in organizational information systems is relatively persistent;63

• Information systems are multi-user (either serially or concurrently) in operation;

• Some user data/information in organizational information systems is not shareable with other users who have authorized access to the same systems;

• Information systems exist in networked environments;

• Information systems are general purpose in nature; and

• Organizations have the necessary structure, resources, and infrastructure to implement the controls.64

If one or more of these assumptions is not valid, then some of the security controls assigned to the initial baselines in Appendix D may not be applicable—a situation that can be readily addressed by applying the tailoring guidance in Section 3.2 and the results of organizational assessments of risk. Conversely, there are also some possible situations that are specifically not addressed in the baselines. These include:

• Insider threats exist within organizations;

• Classified data/information is processed, stored, or transmitted by information systems;

• Advanced persistent threats (APTs) exist within organizations;

• Selected data/information requires specialized protection based on federal legislation, directives, regulations, or policies; and

• Information systems need to communicate with other systems across different security domains.

If any of the above assumptions apply, then additional security controls from Appendix F would likely be needed to ensure adequate protection—a situation that can also be effectively addressed by applying the tailoring guidance in Section 3.2 (specifically, security control supplementation) and the results of organizational assessments of risk.

TAILORING BASELINE SECURITY CONTROLS After selecting the applicable security control baseline from Appendix D, organizations initiate the tailoring process to modify appropriately and align the controls more closely with the specific conditions within the organization (i.e., conditions related to organizational missions/business functions, information systems, or environments of operation). The tailoring process includes:

• Identifying and designating common controls in initial security control baselines;

• Applying scoping considerations to the remaining baseline security controls;

• Selecting compensating security controls, if needed;

63 Persistent data/information refers to data/information with utility for a relatively long duration (e.g., days, weeks). 64 In general, federal departments and agencies will satisfy this assumption. The assumption becomes more of an issue for nonfederal entities such as municipalities, first responders, and small (business) contractors. Such entities may not be large enough or sufficiently resourced to have elements dedicated to providing the range of security capabilities that are assumed by the baselines. Organizations consider such factors in their risk-based decisions.

PAGE 30

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

• Assigning specific values to organization-defined security control parameters via explicit assignment and selection statements;

• Supplementing baselines with additional security controls and control enhancements, if needed; and

• Providing additional specification information for control implementation, if needed.

The tailoring process, as an integral part of security control selection and specification, is part of a comprehensive organizational risk management process—framing, assessing, responding to, and monitoring information security risk. Organizations use risk management guidance to facilitate risk-based decision making regarding the applicability of security controls in the security control baselines. Ultimately, organizations use the tailoring process to achieve cost-effective, risk-based security that supports organizational mission/business needs. Tailoring activities are approved by authorizing officials in coordination with selected organizational officials (e.g., risk executive [function], chief information officers, senior information security officers, information system owners, common control providers) 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 a required tailored baseline or as the starting point for system-specific tailoring activities), in support of a particular line of business or mission/business process, at the individual information system level, or by using a combination of the above.65

Conversely, organizations do not remove security controls for operational convenience. Tailoring decisions regarding security controls should be defensible based on mission/business needs and accompanied by explicit risk-based determinations.66 Tailoring decisions, including the specific rationale for those decisions, are documented in the security plans for organizational information systems. Every security control from the applicable security control baseline is accounted for either by the organization (e.g., common control provider) or by the information system owner. If certain security controls are tailored out, then the associated rationale is recorded in security plans (or references/pointers to other relevant documentation are provided) for the information systems and approved by the responsible organizational officials as part of the security plan approval process.67

Documenting 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 with regard to the authorization of information systems. Since information systems, environments of operation, and personnel associated with the system development life cycle are subject to change, providing the assumptions, constraints, and rationale supporting those important risk decisions allows for a better understanding in the future of the security state of the information systems or environments of operation at the time the original risk decisions were made and facilitates identifying changes, when previous risk decisions are revisited.

65 See also Section 3.3, Creating Overlays, and Appendix I, template for developing overlays. 66 Tailoring decisions can also be based on timing and applicability of selected security controls under certain defined conditions. That is, security controls may not apply in every situation or the parameter values for assignment statements may change under certain circumstances. Overlays can define these special situations, conditions, or timing-related considerations. 67 The level of detail required in documenting tailoring decisions in the security control selection process is at the discretion of organizations and reflects the impact levels of the respective information systems implementing or inheriting the controls.

PAGE 31

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

Identifying and Designating Common Controls Common controls are controls that may be inherited by one or more organizational information systems. If an information system inherits a common control, then that system does not need to explicitly implement that control—that is, the security capability is being provided by another entity. Therefore, when the security controls in Appendix F call for an information system to implement or perform a particular security function, it should not be interpreted to mean that all systems that are part of larger, more complex systems or all components of a particular system need to implement the control or function. Organizational decisions on which security controls are designated as common controls may greatly affect the responsibilities of individual system owners with regard to the implementation of controls in a particular baseline. Common control selection can also affect the overall resource expenditures by organizations (i.e., the greater the number of common controls implemented, the greater potential cost savings).

Applying Scoping Considerations Scoping considerations, when applied in conjunction with risk management guidance, provide organizations with a more granular foundation with which to make risk-based decisions.68 The application of scoping considerations can eliminate unnecessary security controls from the initial security control baselines and help to ensure that organizations select only those controls that are needed to provide the appropriate level of protection for organizational information systems— protection based on the missions and business functions being supported by those systems and the environments in which the systems operate. Organizations may apply the scoping considerations described below to assist with making risk-based decisions regarding security control selection and specification—decisions that can potentially affect how the baseline security controls are applied and implemented by organizations:

• CONTROL ALLOCATION AND PLACEMENT CONSIDERATIONS— The term information system can refer to systems at multiple levels of abstraction ranging from system-of-systems to individual single-user systems. The growing complexity of many information systems requires careful analysis in the allocation/placement of security controls within the three tiers in the risk management hierarchy (organization level, mission/business process level, and information system level) without imposing any specific architectural views or solutions.69 Security controls in the initial baselines represent an information system-wide set of controls that may not be applicable to every component in the system. Security controls are applicable only to information system components that provide or support the information security capability addressed by the controls.70 Organizations make explicit risk-based decisions about where to apply or allocate specific security controls in organizational information systems in order to achieve the needed security capability and to satisfy security requirements.71 An example of this type of allocation is applying the

68 The scoping considerations listed in this section are exemplary and not intended to limit organizations in rendering risk-based decisions based on other organization-defined considerations with appropriate rationale. 69 This is especially true with the advent of service-oriented architectures where specific services are provided to implement a single function. 70 For example, auditing controls are typically applied 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. Organizations should carefully assess the inventory of components that compose their information systems to determine which security controls are applicable to the various components. 71 As information technology advances, more powerful and diverse functionality can be found in smart phones, tablets, and other types of mobile devices. While tailor guidance may support not allocating a particular security control to a specific technology or device, any residual risk associated with the absence of that control must be addressed in risk assessments to adequately protect organizational operations and assets, individuals, other organizations, and the Nation.

PAGE 32

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

requirement from AC-18(1) (i.e., protecting wireless access to information systems using authentication/encryption) to all wireless access except for wireless access to visitor subnetworks which are not connected to other system components.

• OPERATIONAL/ENVIRONMENTAL-RELATED CONSIDERATIONS— Several of the security controls in the baselines are based on the assumption of the existence of certain operational/environmental factors. Where these factors are absent or significantly diverge from the baseline assumptions, it is justifiable to tailor the baseline. Some of the more common operational/environmental factors include:

- Mobility The mobility of physical hosting environments can impact the security controls selected for organizational information systems. As noted above, the set of security controls assigned to each baseline in Appendix D assumes the operation of information systems in fixed facilities and nonmobile locations. If those information systems operate primarily in mobile environments, the security control baseline should be tailored appropriately to account for the differences in mobility and accessibility of the specific locations where the systems reside. For example, many of the security controls in the Physical and Environmental Protection (PE) family that are selected in all three baselines reflect the assumption that the information systems reside in physical facilities/complexes that require appropriate physical protections. Such controls would likely not provide added value for mobile environments such as ships, aircraft, automobiles, vans, or space-based systems.72

- Single-User Systems and Operations For information systems that are designed to operate as single-user systems (e.g., smart phones), several of the security controls that address sharing among users may not be needed. A single-user system or device refers to a system/device that is only intended to be used by a single individual over time (i.e., exclusive use). Systems or devices that are shared by multiple users over time are not considered single-user. Security controls such as AC-10, Concurrent Session Control, SC-4, Information in Shared Resources, and AC- 3, Access Enforcement73 may not be required in single-user systems/operations and could reasonably be tailored out of the baseline at the discretion of organizations.

- Data Connectivity and Bandwidth While many information systems are interconnected, there are some systems which for security or operational reasons, lack networking capabilities—that is, the systems are air gapped from the network. For nonnetworked systems, security controls such as AC-17, Remote Access, SC-8, Transmission Confidentiality and Integrity, and SC-7, Boundary Protection, are not applicable and may be tailored out of the security control baselines at the discretion of organizations. In addition to nonnetworked information systems, there are systems that have very limited or sporadic bandwidth (e.g., tactical systems that support warfighter or law enforcement missions). For such systems, the application of security controls would need to be examined carefully as the limited and/or sporadic bandwidth could impact the practicality of implementing those controls and the viability of adversaries staging cyber attacks over the limited bandwidth.

72 The mobile nature of devices means that it is possible that, for some period of time, the devices may reside in fixed facilities or complexes in fixed locations. During that time, the PE controls would likely apply. 73 Organizations consider whether individual users have administrator privileges before removing AC-3 from security control baselines.

PAGE 33

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

- Limited Functionality Systems or System Components What constitutes an information system under the E-Government Act of 2002 is quite broad. Fax machines, printers, scanners, pagers, smart phones, tablets, E-readers, and digital cameras can all be categorized as information systems (or system components). These types of systems and components may lack the general processing capabilities assumed in the security control baselines. The nature of these constraints may limit the types of threats that these systems face, and hence the appropriateness of some of the security controls. Thus, a control such as SI-3, Malicious Code Protection (required in all control baselines) may not be practical for information systems or components that are not capable of executing code (e.g., text-only pagers). However, because there is often no clear delineation between these types of information systems or components (e.g., smart phones combine the digital capabilities of telephones, cameras, and computers), it is important that the application of security controls to limited functionality systems or components be done judiciously and always take into account the intended use of the systems, system capabilities, and the risk of compromise.

- Information and System Non-Persistence There is often an assumption that user information within organizational information systems is persistent for a considerable period of time. However, for some applications and environments of operation (e.g., tactical systems, industrial control systems), the persistence of user information is often very limited in duration. For information systems processing, storing, or transmitting such non-persistent information, several security controls in the Contingency Planning (CP) family such as CP-6, Alternate Storage Site, CP-7, Alternate Processing Site, and CP-9, Information System Backup, may not be practical and can be tailored out at the discretion of organizations. For similar reasons, controls such as MP-6, Media Sanitization, and SC-28, Protection of Information at Rest, are good candidates for removal through tailoring.74 In addition to the non-persistence of information, the information systems/services may be non-persistent as well. This can be achieved by the use of virtualization techniques to establish non-persistent instantiations of operating systems and applications. Depending on the duration of the instantiations, some baseline controls might not be applicable.

- Public Access When public access to organizational information systems is allowed, security controls should be applied with discretion since some security controls from the specified control baselines (e.g., identification and authentication, personnel security controls) may not be applicable for public access. Thus, in the case of the general public accessing federal government websites (e.g., to download publically accessible information such as forms, emergency preparedness information), security controls such as AC-7, Unsuccessful Logon Attempts, AC-17, Remote Access, IA-2, Identification and Authentication, IA-4, Identifier Management, and IA-5, Authenticator Management, typically would not be relevant for validating access authorizations or privileges. However, many of these controls would still be needed for identifying and authenticating organizational personnel that maintain and support information systems providing such public access websites and services. Similarly, many of the security controls may still be required for users accessing nonpublic information systems through such public interfaces, for example, to access or change personal information.

74 Organizations balance information persistence with the sensitivity of the information. Non-persistent information may still require sanitization after deletion. In addition, organizations consider the duration of information sensitivity— some information may be persistent, but only be sensitive for a limited time.

PAGE 34

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

• SECURITY OBJECTIVE-RELATED CONSIDERATIONS— 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) only if the downgrading action: (i) reflects the FIPS Publication 199 security category for the supported security objective(s) before moving to the FIPS Publication 200 impact level (i.e., high water mark);75 (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.76 For example, if an information system is categorized as moderate impact using the high water mark concept because confidentiality and/or integrity are moderate but availability is low, there are several controls that only support the availability security objective and that potentially could be downgraded to low baseline requirements—that is, it may be appropriate not to implement CP-2(1) because the control enhancement supports only availability and is selected in the moderate baseline but not in the low baseline. The following security controls and control enhancements are potential candidates for downgrading:77

- Confidentiality: AC-21, MA-3(3), MP-3, MP-4, MP-5, MP-5(4), MP-6(1), MP-6(2), PE- 4, PE-5, SC-4, SC-8, SC-8(1);

- Integrity: CM-5, CM-5(1), CM-5(3), SC-8, SC-8(1), SI-7, SI-7(1), SI-7(5), SI-10; and

- Availability: CP-2(1), CP-2(2), CP-2(3), CP-2(4), CP-2(5), CP-2(8), CP-3(1), CP-4(1), CP-4(2), CP-6, CP-6(1), CP-6(2), CP-6(3), CP-7, CP-7(1), CP-7(2), CP-7(3), CP-7(4), CP-8, CP-8(1), CP-8(2), CP-8(3), CP-8(4), CP-9(1), CP-9(2), CP-9(3), CP-9(5), CP- 10(2), CP-10(4), MA-6, PE-9, PE-10, PE-11, PE-11(1), PE-13(1), PE-13(2), PE-13(3), PE-15(1).

• 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 organizational information systems. Security controls that can be explicitly or implicitly 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. If automated mechanisms are not readily available,

75 When applying the high water mark in Section 3.1, some of the original FIPS Publication 199 confidentiality, integrity, or availability security objectives may have been upgraded to a higher security control baseline. 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. 76 Information that is security-relevant at the information system level (e.g., password files, network routing tables, cryptographic key management information) is distinguished from user-level information within the same system. Certain security controls 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 downgrading actions do 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 a similar level of protection for any of the security objectives related to user-level information. 77 Downgrading actions apply only to the moderate and high baselines. 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, SC-5, SC-13, 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 downgrading security controls that do not appear in the list in Section 3.2 to ensure that downgrading actions do not affect security objectives other than the objectives targeted for downgrading.

PAGE 35

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

cost-effective, or technically feasible, compensating security controls, implemented through nonautomated mechanisms or procedures, are used to satisfy specified security controls or control enhancements (see terms and conditions for applying compensating controls below).

• MISSION REQUIREMENTS-RELATED CONSIDERATIONS— Some security controls may not be applicable (or appropriate) if implementing those controls has the potential to degrade, debilitate, or otherwise hamper critical organizational missions and/or business functions. For example, if the mission requires that an uninterrupted display of mission-critical information be available at an operator console (e.g., air traffic controller console), the implementation of AC-11, Session Lock, or SC-10, Network Disconnect, may not be appropriate.

Selecting Compensating Security Controls Organizations may find it necessary on occasion to employ compensating security controls. Compensating controls are alternative security controls employed by organizations in lieu of specific controls in the low, moderate, or high baselines described in Appendix D—controls that provide equivalent or comparable protection for organizational information systems and the information processed, stored, or transmitted by those systems.78 This may occur, for example, when organizations are unable to effectively implement specific security controls in the baselines or when, due to the specific nature of the information systems or environments of operation, the controls in the baselines are not a cost-effective means of obtaining the needed risk mitigation. Compensating controls are typically selected after applying the scoping considerations in the tailoring guidance to the applicable security control baseline. Compensating controls may be employed by organizations under the following conditions:

• Organizations select compensating controls from Appendix F; if appropriate compensating controls are not available, organizations adopt suitable compensating controls from other sources;79

• Organizations provide supporting rationale for how compensating controls provide equivalent security capabilities for organizational information systems and why the baseline security controls could not be employed; and

• Organizations assess and accept the risk associated with implementing compensating controls in organizational information systems.

Assigning Security Control Parameter Values Security controls and control enhancements containing embedded parameters (i.e., assignment and selection statements) give organizations the flexibility to define certain portions of controls and enhancements to support specific organizational requirements. After the initial application of scoping considerations and the selection of compensating controls, organizations review the security controls and control enhancements for assignment/selection statements and determine appropriate organization-defined values for the identified parameters. Parameter values may be prescribed by applicable federal laws, Executive Orders, directives, regulations, policies, or standards. Once organizations define the parameter values for security controls and control

78 More than one compensating control may be required to provide the equivalent protection for a particular security control in Appendix F. For example, organizations with significant staff limitations may compensate for the separation of duty security control by strengthening the audit, accountability, and personnel security controls. 79 Organizations should make every attempt to select compensating controls from the security control catalog in Appendix F. Organization-defined compensating controls are employed only when organizations determine that the security control catalog does not contain suitable compensating controls.

PAGE 36

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

enhancements, the assignments and selections become a part of the control and enhancement.80 Organizations may choose to specify the values for security control parameters before selecting compensating controls since the specification of the parameters completes the control definitions and may affect compensating control requirements. There can also be significant benefits in collaborating on the development of parameter values. For organizations that work together on a frequent basis, it may be useful for those organizations to develop a mutually agreeable set of uniform values for security control parameters. Doing so may assist organizations in achieving a greater degree of reciprocity when depending upon the information systems and/or services offered by other organizations.

Supplementing Security Control Baselines The final determination of the appropriate set of security controls necessary to provide adequate security for organizational information systems and the environments in which those systems operate is a function of the assessment of risk and what is required to sufficiently mitigate the risks to organizational operations and assets, individuals, other organizations, and the Nation.81 In many cases, additional security controls or control enhancements (beyond those controls and enhancements contained in the baselines in Appendix D) will be required to address specific threats to and vulnerabilities in organizations, mission/business processes, and/or information systems and to satisfy the requirements of applicable federal laws, Executive Orders, directives, policies, standards, or regulations.82 The risk assessment in the security control selection process provides essential information in determining the necessity and sufficiency of the security controls and control enhancements in the initial baselines. Organizations are encouraged to make maximum use of Appendix F to facilitate the process of supplementing the initial baselines with additional security controls and/or control enhancements.83

Situations Requiring Potential Baseline Supplementation Organizations may be subject to conditions that, from an operational, environmental, or threat perspective, warrant the selection and implementation of additional (supplemental) controls to achieve adequate protection of organizational missions/business functions and the information systems supporting those missions/functions. Examples of conditions and additional controls that might be required are provided below.

• ADVANCED PERSISTENT THREAT Security control baselines do not assume that the current threat environment is one where adversaries have achieved a significant foothold and presence within organizations and organizational information systems—that is, organizations are dealing with an advanced persistent threat (APT). Adversaries continue to attack organizational information systems and the information technology infrastructure and are successful in some aspects of such attacks. To more fully address the advanced persistent threat, concepts such as insider threat

80 CNSS Instruction 1253 provides assignment of minimum values for organization-defined variables applicable to national security systems. Parameter values can also be defined as part of overlays described in Section 3.4. 81 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. 82 In previous versions of Special Publication 800-53, tailoring referred only to the removal of security controls from baselines and supplementation referred only to the addition of controls to baselines. In this document, the term tailoring has been redefined to include both the addition of security controls to baselines (i.e., tailoring up) and the removal of controls from baselines (i.e., tailoring down). 83 Security controls and control enhancements selected to supplement baselines are allocated to appropriate information system components in the same manner as the control allocations carried out by organizations in the initial baselines.

PAGE 37

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations ________________________________________________________________________________________________

protection (CM-5(4)), heterogeneity (SC-29), deception (SC-26 and SC-30), non-persistence (SC-25 and SC-34), and segmentation (SC-7(13)) can be considered.

• CROSS-DOMAIN SERVICES Security control baselines do not assume that information systems have to operate across multiple security domains. The baselines assume a flat view of information flows (i.e., the same security policies in different domains when information moves across authorization boundaries). To address cross-domain services and transactions, some subset of the AC-4 security control enhancements can be considered to ensure adequate protection of information when transferred between information systems with different security policies.

• MOBILITY The use of mobile devices might result in the need for additional security controls and control enhancements not selected in the initial baselines. For example, AC-7(2), which requires the purging/wiping of information after an organization-defined number of unsuccessful logon attempts, or MP-6 (8), which requires the capability for remote purging/wiping, could be selected in order to address the threat of theft or loss of mobile devices.

• CLASSIFIED INFORMATION In some environments, classified and sensitive information84 may be resident on national security systems without all users having the necessary authorizations to access all of the information. In those situations, additional security controls are required to ensure that information requiring strict separation is not accessed by unauthorized users. More stringent access controls include, for example, AC-3(3) and AC-16. When classified information is being processed, stored, or transmitted on information systems that are jointly owned by multiple entities (e.g., coalition partners in military alliances), more restrictive controls for maintenance personnel may be required including, for example, MA-5(4).

Processes for Identifying Additional Needed Security Controls Organizations can employ a requirements definition approach or a gap analysis approach in selecting security controls and control enhancements to supplement initial baselines. In the requirements definition approach, organizations obtain specific and credible threat85 information (or make reasonable assumptions) 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, organizations strive to achieve a certain level of defensive capability or cyber preparedness. Organizations can select additional security controls and control enhancements from Appendix F to obtain such defensive capability or level of preparedness. In contrast to the requirements definition approach, the gap analysis approach begins with an organizational assessment of its current defensive capability or level of cyber preparedness. From that initial capability assessment, organizations determine the types of threats they can reasonably expect to counter. If the current organizational defensive capabilities or levels of cyber preparedness are insufficient, the gap analysis determines the required capabilities and levels of preparedness. Organizations subsequently define the security controls and control enhancements from Appendix F needed to achieve the desired capabilities or cyber-preparedness levels. Both of the approaches described above require timely and accurate

84 The example is illustrative only. CNSS Instruction 1253 provides specific guidance regarding security controls required for national security systems. 85 While this example focuses on threats to information systems from purposeful attacks, the threat space of concern to organizations also includes environmental disruptions and human errors.

CHAPTER 3 PAGE 38

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations ________________________________________________________________________________________________

threat information. It is essential that organizations work with the appropriate threat identification component to obtain such information.

During the tailoring process, organizations consider reevaluating the priority codes from the security control baselines to determine if any changes to those priorities are appropriate. This is especially important when adding security controls that are not included in any of the baselines, because those controls have priority codes of P0. The reevaluation of priority codes can be based on organizational assessments of risk or design/developmental decisions related to the security architecture or the systems and security engineering process that may require certain sequencing in security control implementation.

Enhancing Information Security without Changing Control Selection There may be situations in which organizations cannot apply sufficient security controls within their information systems to adequately reduce or mitigate risk (e.g., when using certain types of information technologies or employing certain computing paradigms). Therefore, alternative strategies are needed to prevent organizational missions/business functions from being adversely affected— strategies that consider the mission and business risks resulting from an aggressive use of information technology. Restrictions on the types of technologies used and how organizational information systems are employed provide an alternative method to reduce or mitigate risk that may be used in conjunction with, or instead of, supplemental security controls. Restrictions on the use of information systems and specific information technologies may be, in some situations, the only practical or reasonable actions organizations can take in order to have the capability to carry out assigned missions/business functions in the face of determined adversaries. Examples of use restrictions include:

• Limiting the information that information systems can process, store, or transmit or the manner in which organizational missions/business functions are automated;

• Prohibiting external access to organizational information by removing selected information system components from networks (i.e., air gapping); and

• Prohibiting moderate- or high-impact information on organizational information system components to which the public has access, unless an explicit risk determination is made authorizing such access.

Providing Additional Specification Information for Control Implementation Since security controls are statements of security capability at higher levels of abstraction, the controls may lack sufficient information for successful implementation. Therefore, additional detail may be necessary to fully define the intent of a given security control for implementation purposes and to ensure that the security requirements related to that control are satisfied. For example, additional information may be provided as part of the process of moving from control to specification requirement, and may involve refinement of implementation details, refinement of scope, or iteration to apply the same control differently to different scopes. Organizations ensure that if existing security control information (e.g., selection and assignment statements) is not sufficient to fully define the intended application of the control, such information is provided. Organizations have the flexibility to determine whether additional detail is included as a part of the control statement, in supplemental guidance, or in a separate control addendum section. When providing additional detail, organizations are cautioned not to change the intent of the security control or modify the original language in the control. The additional implementation information can be documented either in security plans or systems and security engineering plans. The type of

CHAPTER 3 PAGE 39

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations ________________________________________________________________________________________________

additional detail that might be necessary to fully specify a security control for implementation purposes is provided in the SI-7(6) example below:

SI-7 SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY

(6) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | CRYPTOGRAPHIC PROTECTION The information system implements cryptographic mechanisms to detect unauthorized changes to software, firmware, and information. Supplemental Guidance: Cryptographic mechanisms used for the protection of integrity include, for example, digital signatures and the computation and application of signed hashes using asymmetric cryptography, protecting the confidentiality of the key used to generate the hash, and using the public key to verify the hash information. Related control: SC-13.

Additional implementation detail for SI-7(6):

Digital signatures are applied to all traffic for which non-repudiation is required employing SHA-256 or another approved NIST algorithm demonstrably of at least the same strength of mechanism.

3.3 CREATING OVERLAYS The previous sections described the process of tailoring security control baselines to achieve a more focused and relevant security capability for organizations. In certain situations, it may be beneficial for organizations to apply tailoring guidance to the baselines to develop a set of security controls for community-wide use or to address specialized requirements, technologies, or unique missions/environments of operation.86 For example, the federal government may decide to establish a governmentwide set of security controls and implementation guidance for: (i) public key infrastructure (PKI) systems that could be uniformly applied to all PKI systems implemented within federal agencies; (ii) cloud-based information systems that are uniformly applied to all federal agencies procuring or implementing cloud services; or (iii) industrial control systems (ICSs) at federal facilities producing electric power or controlling environmental systems in federal facilities. Alternatively, to address particular communities of interest with specialized requirements, the Department of Defense, for example, may decide to establish a set of security controls and implementation guidance for its tactical operations and environments by applying the tailoring guidance to the standard security control baselines for national security systems to achieve more specialized solutions. In each of the above examples, tailored baselines can be developed for each information technology area or for the unique circumstances/environments and promulgated to large communities of interest—thus achieving standardized security capabilities, consistency of implementation, and cost-effective security solutions.

To address the need for developing community-wide and specialized sets of security controls for information systems and organizations, the concept of overlay is introduced. An overlay is a fully specified set of security controls, control enhancements, and supplemental guidance derived from the application of tailoring guidance in Section 3.2 to security control baselines in Appendix D.87 Overlays complement the initial security control baselines by: (i) providing the opportunity to add or eliminate controls; (ii) providing security control applicability and interpretations for specific information technologies, computing paradigms, environments of operation, types of information systems, types of missions/operations, operating modes, industry sectors, and statutory/regulatory requirements; (iii) establishing community-wide parameter values for assignment and/or selection statements in security controls and control enhancements; and (iv) extending the supplemental guidance for security controls, where necessary. Organizations typically use the overlay concept

86 This type of tailoring can be conducted at the federal level or by individual organizations. 87 CNSS Instruction 1253 provides tailoring guidance and security control baselines for national security systems.

CHAPTER 3 PAGE 40

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations ________________________________________________________________________________________________

when there is divergence from the basic assumptions used to create the initial security control baselines (see Section 3.1). If organizations are not divergent from the basic assumptions for the initial baselines, there is likely no need to create an overlay. Alternatively, the baselines may be missing key assumptions which would justify creating an overlay with additional assumptions.

The full range of tailoring activities can be employed by organizations to provide a disciplined and structured approach for developing tailored baselines supporting the areas described above. Overlays provide an opportunity to build consensus across communities of interest and develop security plans for organizational information systems that have broad-based support for very specific circumstances, situations, and/or conditions. Categories of overlays that may be useful include, for example:

• Communities of interest, industry sectors, or coalitions/partnerships (e.g., healthcare, law enforcement, intelligence, financial, transportation, energy, allied collaboration/sharing);

• Information technologies/computing paradigms (e.g., cloud/mobile, PKI, Smart Grid, cross- domain solutions);

• Environments of operation (e.g., space, tactical);

• Types of information systems and operating modes (e.g., industrial/process control systems, weapons systems, single-user systems, standalone systems);

• Types of missions/operations (e.g., counterterrorism, first responders, research, development, test, and evaluation); and

• Statutory/regulatory requirements (e.g., Foreign Intelligence Surveillance Act, Health Insurance Portability and Accountability Act, Privacy Act).

Organizations can effectively use the risk management concepts defined in NIST Special Publication 800-39 when developing overlays. The successful development of overlays requires the involvement of: (i) information security professionals who understand the specific subject area that is the focus of the overlay development effort; and (ii) subject matter experts in the overlay area who understand the security controls in Appendix F and the initial baselines in Appendix D. The format and structure for developing overlays is provided in Appendix I.

Multiple overlays can be applied to a single security control baseline. The tailored baselines that result from the overlay development process may be more or less stringent than the original security control baselines. Risk assessments provide information necessary to determine if the risk from implementing the tailored baselines falls within the risk tolerance of the organizations or communities of interest developing the overlays. If multiple overlays are employed, it is possible that there could be a conflict between the overlays. If the use of multiple overlays results in conflicts between the application or removal of security controls, the authorizing official (or designee), in coordination with the mission/business owner and/or information owner/steward, can resolve the conflict. In general, overlays are intended to reduce the need for ad hoc tailoring of baselines by organizations through the selection of a set of controls and control enhancements that more closely correspond to common circumstances, situations, and/or conditions. However, the use of overlays does not preclude organizations from performing further tailoring to reflect organization-specific needs, assumptions, or constraints. Tailoring of overlays is accomplished within the constraints defined within the overlay and may require the concurrence/approval of the authorizing official or other organization-designated individuals. For example, an overlay created for an industrial control system (ICS) may require tailoring for applicability to a specific type of ICS and its environment of operation. But it is anticipated that the use of overlays would greatly reduce the number and extent of organization-specific ad hoc tailoring.

CHAPTER 3 PAGE 41

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

3.4 DOCUMENTING THE CONTROL SELECTION PROCESS Organizations document the relevant 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 organizational information systems with respect to the potential mission/business impact. The resulting set of security controls and the supporting rationale for the selection decisions (including any information system use restrictions required by organizations) are documented in the security plans. Documenting significant risk management decisions in the security control selection process is imperative so that authorizing officials can have access to the necessary information to make informed authorization decisions for organizational information systems.88 Without such information, the understanding, assumptions, constraints, and rationale supporting those risk management 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 4 summarizes the security control selection process, including the selection of initial baselines and the tailoring of the baselines by applying the guidance in Section 3.2.

FIGURE 4: SECURITY CONTROL SELECTION PROCESS

Iterative and Dynamic Nature of Security Control Tailoring The security control tailoring process described above, while appearing to be sequential in nature, can also have an iterative aspect. Organizations may choose to execute the tailoring steps in any order based on organizational needs and the information generated from risk assessments. For example, some organizations may establish the parameter values for security controls in the initial baselines prior to selecting compensating controls. Other organizations may delay completing assignment and selection statements in the controls until after the supplementation activities have been completed. Organizations may also discover that when fully specifying security controls for the intended environments of operation, there may be difficulties that arise which may trigger the need for additional (supplemental) controls. Finally, the security control tailoring process is not static—that is, organizations revisit the tailoring step as often as needed based on ongoing organizational assessments of risk.

88 The security control selection process also applies to common control providers and the authorizing officials rendering authorization decisions for common controls deployed within organizations.

CHAPTER 3 PAGE 42

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations ________________________________________________________________________________________________

In addition to the iterative and dynamic nature of the security control tailoring process, there may also be side effects as controls are added and removed from the baselines. Security controls in Appendix F can have some degree of dependency and functional overlap with other controls. In many cases, security controls work together to achieve a security capability. Thus, removing a particular security control from a baseline during the tailoring process may have unintended side effects (and potentially adverse impacts) on the remaining controls. Alternatively, adding a new security control to a baseline during the tailoring process may eliminate or reduce the need for certain specific controls because the new control provides a better security capability than the capability provided by other controls. For example, if organizations implement SC-30(2) using virtualization techniques to randomly/frequently deploy diverse and changing operating systems and applications, this approach could potentially limit the requirement to update the security configurations in CM-2(2). Therefore, the addition or removal of security controls is viewed with regard to the totality of the information security needs of the organization and its information systems, and not simply with regard to the controls being added or removed.

Other Considerations Organizational tailoring decisions are not carried out in a vacuum. While such decisions are rightly focused on information security considerations, it is important that the decisions be aligned with other risk factors that organizations address routinely. Risk factors such as cost, schedule, and performance are considered in the overall determination of which security controls to employ in organizational information systems and environments of operation. For example, in military command and control systems in which lives may be at stake, the adoption of security controls is balanced with operational necessity. With respect to the air traffic control system and consoles used by air traffic controllers, the need to access the consoles in real time to control the air space outweighs the security need for an AC-11, Session Lock. In short, the security control selection process (to include tailoring activities described in Section 3.2) should be integrated into the overall risk management process as described in NIST Special Publication 800-39.

Finally, organizations factor scalability into the security control selection process—that is, controls are scalable with regard to the extent/rigor of the implementation. Scalability is guided by the FIPS Publication 199 security categorizations and the associated FIPS Publication 200 impact levels of the information systems where the controls are to be applied. For example, contingency plans for high-impact information systems may contain significant amounts of

Implementation Tip

In diverging from the security control baselines during the tailoring process, organizations consider some very important linkages between various controls and control enhancements. These linkages are captured in the selection of controls and enhancements in the baselines and are especially significant when developing overlays (described in Section 3.3 and Appendix I). In some instances, the linkages are such that it is not meaningful to include a security control or control enhancement without some other control or enhancement. The totality of the controls and enhancements provide a required security capability. Some linkages are obvious such as the linkage between Mandatory Access Control enhancement (AC-3(3)) and Security Attributes (AC-16). But other linkages may be more subtle. This is especially true in the case where the linkage is between security functionality- related controls and security assurance-related controls as described in Appendix E. For example, it is not particularly meaningful to implement AC-3(3) without also implementing a Reference Monitor (AC-25). Organizations are encouraged to pay careful attention to the related controls section of the Supplemental Guidance for the security controls to help in identifying such linkages.

CHAPTER 3 PAGE 43

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

implementation detail and be quite lengthy. In contrast, contingency plans for low-impact systems may contain considerably less detail and be quite succinct. Organizations use discretion in applying the security controls to organizational information systems, giving consideration to the scalability factors in particular operational environments. Scaling controls to the appropriate system impact level facilitates a more cost-effective, risk-based approach to security control implementation—expending only the level of resources necessary to achieve sufficient risk mitigation and adequate security.

3.5 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 new development systems, the security control selection process is applied from a requirements definition perspective since the systems do not yet exist and organizations are conducting initial security categorizations. The security controls included in the security plans for the information systems serve as a security specification and are expected to be incorporated into the systems during the development and implementation phases of the system development life cycle. In contrast, for legacy information systems, the security control selection process is applied from a gap analysis perspective when organizations are anticipating significant changes to the systems (e.g., during major upgrades, modifications, or outsourcing). Since the information systems already exist, organizations in all likelihood have completed the security categorization and security control selection processes resulting in the establishment of previously agreed-upon security controls in the respective security plans and the implementation of those controls within the information systems. Therefore, the gap analysis can be applied in the following manner:

• First, reconfirm or update as necessary, the security category and impact level for the information system based on the 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, mission/business processes, 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.

Implementation Tip

Maintaining a record of security control selection and control status can be addressed in one or multiple documents or security plans. If using multiple documents, consider providing references to the necessary information in the relevant documents rather than requiring duplication of information. Using references to relevant documentation reduces the amount of time and resources needed by organizations to generate such information. Other benefits include greater security awareness and understanding of the information system capabilities. Increased security awareness/understanding supports more effective integration of information security into organizational information systems.

PAGE 44

Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

________________________________________________________________________________________________

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.5, organizations are becoming increasingly reliant on external providers for information system services. Using the steps in the gap analysis described above, organizations can effectively use the acquisition process and appropriate contractual vehicles to require external providers to carry out 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. If a security control deficit exists, the responsibility for adequately mitigating unacceptable risks arising from the use of external information system services remains with authorizing officials. In such situations, organizations 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 if the existing contractual vehicle does not provide for such added requirements;

• Approving the use of compensating controls by the provider; or

• Employing alternative risk mitigation actions89 within the organizational information system when a contract either does not exist or the contract does not provide the necessary leverage for organizations to obtain the needed security controls.

89 For example, local policies, procedures, and/or compensating controls could be established by organizations to serve as alternative mitigation actions for risks identified in a gap analysis.

Implementation Tip

Many organizations operate and maintain complex information systems, often referred to as a system-of-systems. Enterprise architecture plays a key part in the security control selection process for these types of information systems. Organizations can address the complex system problem 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 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.

Organizations develop security architectures to allocate security controls among subsystems including monitoring and controlling communications at key internal boundaries within the system and provide system-wide controls that meet or exceed the highest information system impact level of the constituent subsystems inheriting security capabilities from those controls. Organizations also consider that replicated subsystems within complex systems may exhibit common vulnerabilities that can be exploited by common threat sources—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.

PAGE 45