NIST SP 800-18r1 Chapter 2

From FISMApedia
Jump to: navigation, search

2. System Boundary Analysis and Security Controls

Before the system security plan can be developed, the information system and the information resident within that system must be categorized based on a FIPS 199 impact analysis. Then a determination can be made as to which systems in the inventory can be logically grouped into major applications or general support systems. The FIPS 199 impact levels must be considered when the system boundaries are drawn and when selecting the initial set of security controls (i.e., control baseline). The baseline security controls can then be tailored based on an assessment of risk and local conditions including organization-specific security requirements, specific threat information, cost-benefit analyses, the availability of compensating controls, or special circumstances. Common security controls, which is one of the tailoring considerations, must be identified prior to system security plan preparation in order to identity those controls covered at the agency level, which are not system-specific. These common security controls can then be incorporated into the system security plan by reference.


2.1 System Boundaries

The process of uniquely assigning information resources9 to an information system defines the security boundary for that system. Agencies have great flexibility in determining what constitutes an information system (i.e., major application or general support system). If a set of information resources is identified as an information system, the resources should generally be under the same direct management control. Direct management control10 does not necessarily imply that there is no intervening management. It is also possible for an information system to contain multiple subsystems.

A subsystem is a major subdivision or component of an information system consisting of information, information technology, and personnel that perform one or more specific functions. Subsystems typically fall under the same management authority and are included within a single system security plan. Figure 3 depicts a general support system with three subsystems.

In addition to the consideration of direct management control, it may be helpful for agencies to consider if the information resources being identified as an information system:

  • Have the same function or mission objective and essentially the same operating characteristics and security needs, and
  • Reside in the same general operating environment (or in the case of a distributed information system, reside in various locations with similar operating environments).


Figure 3: Decomposition of large and complex information systems

While the above considerations may be useful to agencies in determining information system boundaries for purposes of security accreditation, they should not be viewed as limiting the agency's flexibility in establishing boundaries that promote effective information security within the available resources of the agency. Authorizing officials and senior agency information security officers should consult with prospective information system owners when establishing information system boundaries. The process of establishing boundaries for agency information systems and the associated security implications, is an agency-level activity that should include careful negotiation among all key participants-taking into account the mission/business requirements of the agency, the technical considerations with respect to information security, and the programmatic costs to the agency.

FIPS 199 defines security categories for information systems based on potential impact on organizations, assets, or individuals should there be a breach of security-that is, a loss of confidentiality, integrity, or availability. FIPS 199 security categories can play an important part in defining information system boundaries by partitioning the agency's information systems according to the criticality or sensitivity of the information and information systems and the importance of those systems in accomplishing the agency's mission. This is particularly important when there are various FIPS 199 impact levels contained in one information system. The FIPS 199 requirement to secure an information system to the high watermark or highest impact level must be applied when grouping minor applications/subsystems with varying FIPS 199 impact levels into a single general support system or major application unless there is adequate boundary protection, e.g., firewalls and encryption, around those subsystems or applications with the highest impact level. Additionally, there must be assurance that the shared resources, i.e., networks, communications, and physical access within the whole general support system or major application, are protected adequately for the highest impact level. Having the ability to isolate the high impact systems will not only result in more secure systems, but will also reduce the amount of resources required to secure many applications/systems that do not require that level of security. NIST SP 800-53 provides three security control baselines, i.e., low, moderate, and high, that are associated with the three FIPS 199 impact levels; as the impact level increases, so do the minimum assurance requirements. For reporting purposes, i.e., FISMA annual report, when an information system has varying FIPS 199 impact levels, that system is categorized at the highest impact level on that information system.


2.2 Major Applications

All federal applications have value and require some level of protection. Certain applications, because of the information they contain, process, store, or transmit, or because of their criticality to the agency's mission, require special management oversight. These applications are major applications. A major application is expected to have a FIPS 199 impact level of moderate or high. OMB Circular A-130 defines a "major information system" as an information system that requires special management attention because of its importance to an agency mission; its high development, operating, or maintenance costs; or its significant role in the administration of agency programs, finances, property, or other resources. Major applications are by definition major information systems.

Major applications are systems that perform clearly defined functions for which there are readily identifiable security considerations and needs (e.g., an electronic funds transfer system). A major application might comprise many individual programs and hardware, software, and telecommunications components. These components can be a single software application or a combination of hardware/software focused on supporting a specific, mission-related function. A major application may also consist of multiple individual applications if all are related to a single mission function (e.g., payroll or personnel). If a system is defined as a major application and the application is run on another organization's general support system, the major application owner is responsible for acceptance of risk and in addition:


2.3 General Support Systems

A general support system is an interconnected set of information resources under the same direct management control that shares common functionality. A general support system normally includes hardware, software, information, data, applications, communications, facilities, and people and provides support for a variety of users and/or applications. A general support system, for example11, can be a:

  • LAN including smart terminals that support a branch office;
  • Backbone (e.g., agency-wide);
  • Communications network;
  • Agency data processing center including its operating system and utilities,
  • Tactical radio network; or
  • Shared information processing service facility

A general support system can have a FIPS 199 impact level of low, moderate, or high in its security categorization depending on the criticality or sensitivity of the system and any major applications the general support system is supporting. A general support system is considered a major information system when special management attention is required, there are high development, operating, or maintenance costs; and the system/information has a significant role in the administration of agency programs. When the general support system is a major information system, the system's FIPS 199 impact level is either moderate or high.

A major application can be hosted on a general support system. The general support system plan should reference the major application system security plan.


2.4 Minor Applications

Agencies are expected to exercise management judgment in determining which of their applications are minor applications and to ensure that the security requirements of minor applications are addressed as part of the system security plan for the applicable general support systems or, in some cases, the applicable major application. It is very common that a minor application may have a majority of its security controls provided by the general support system or major application on which it resides. If this is the case, the information system owner of the general support system or major application is the information system owner for the minor application and is responsible for developing the system security plan. The additional security controls specific to the minor application should be documented in the system security plan as an appendix or paragraph. The minor application owner (often the same as information owner) may develop the appendix or paragraph describing the additional controls. The complete general support system or major application system security plan should be shared with the information owner.

The minor application can have a FIPS 199 security category of low or moderate. However, if the minor application resides on a system that does not have adequate boundary protection, the minor application must implement the minimum baseline controls required by the host or interconnected system.


2.5 Security Controls

FIPS 200 provides seventeen minimum security requirements for federal information and information systems. The requirements represent a broad-based, balanced information security program that addresses the management, operational, and technical aspects of protecting the confidentiality, integrity, and availability of federal information and information systems. An agency must meet the minimum security requirements in this standard by applying security controls selected in accordance with NIST SP 800-53 and the designated impact levels of the information systems. An agency has the flexibility to tailor the security control baseline in accordance with the terms and conditions set forth in the standard. Tailoring activities include: (i) the application of scoping guidance; (ii) the specification of compensating controls; and (iii) the specification of agency-defined parameters in the security controls, where allowed. The system security plan should document all tailoring activities.


2.5.1 Scoping Guidance

Scoping guidance provides an agency with specific terms and conditions on the applicability and implementation of individual security controls in the security control baselines defined in NIST SP 800-53. Several considerations described below can potentially impact how the baseline security controls are applied by the agency. System security plans should clearly identify which security controls employed scoping guidance and include a description of the type of considerations that were made. The application of scoping guidance must be reviewed and approved by the authorizing official for the information system.

Technology-related considerations-

- Security controls that refer to specific technologies (e.g., wireless, cryptography, public key infrastructure) will only be applicable if those technologies are employed or are required to be employed within the information system.
- Security controls will only be applicable to those components of the information system that typically provide the security capability addressed by the minimum security requirements.
- Security controls that can be either explicitly or implicitly supported by automated mechanisms will 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. In situations where automated mechanisms are not readily available or technically feasible, compensating security controls, implemented through non-automated mechanisms or procedures, will be used to satisfy minimum security requirements.

Common security control-related considerations-

- Security controls designated by the agency as common controls will, in most cases, be managed by an organizational entity other than the information system owner. Every control in a security control baseline must be addressed either by the agency through common security controls or by the information system owner. Decisions on common control designations must not, however, affect the agency's responsibility in providing the necessary security controls required to meet the minimum security requirements for the information system. (Additional information on common controls is provided in Section 2.5.3.)

Public access information systems-related considerations-

- Security controls associated with public access information systems must be carefully considered and applied with discretion since some of the security controls from the specified security control baselines (e.g., personnel security controls, identification and authentication controls) may not be applicable to users accessing information systems through public interfaces.12

Infrastructure-related considerations-

- Security controls that refer to agency facilities (e.g., physical access controls such as locks and guards, environmental controls for temperature, humidity, lighting, fire, and power) will be applicable only to those sections of the facilities that directly provide protection to, support for, or are related to the information system (including its information technology assets such as electronic mail or web servers, server farms, data centers, networking nodes, controlled interface equipment, and communications equipment).

Scalability-related considerations-

- Security controls will be scalable by the size and complexity of the particular agency implementing the controls and the impact level of the information system. Scalability addresses the breadth and depth of security control implementation. Discretion is needed in scaling the security controls to the particular environment of use to ensure a cost-effective, risk-based approach to security control implementation.13

Risk-related considerations-

- Security controls that uniquely support the confidentiality, integrity, or availability security objectives can be downgraded to the corresponding control in a lower baseline (or appropriately modified or eliminated if not defined in a lower baseline) if, and only if, the downgrading action: (i) is consistent with the FIPS 199 security categorization for the corresponding security objectives of confidentiality, integrity, or availability before moving to the high watermark;14 (ii) is supported by an agency's assessment of risk; and (iii) does not affect the security-relevant information within the information system.15


2.5.2 Compensating Controls

Compensating security controls are the management, operational, or technical controls employed by an agency in lieu of prescribed controls in the low, moderate, or high security control baselines, which provide equivalent or comparable protection for an information system. Compensating security controls for an information system will be employed by an agency only under the following conditions: (i) the agency selects the compensating controls from the security control catalog in NIST SP 800-53; (ii) the agency provides a complete and convincing rationale and justification for how the compensating controls provide an equivalent security capability or level of protection for the information system; and (iii) the agency assesses and formally accepts the risk associated with employing the compensating controls in the information system. The use of compensating security controls must be reviewed, documented in the system security plan, and approved by the authorizing official for the information system.


2.5.3 Common Security Controls

An agency-wide view of the information security program facilitates the identification of common security controls that can be applied to one or more agency information systems. Common security controls can apply to: (i) all agency information systems; (ii) a group of information systems at a specific site (sometimes associated with the terms site certification/accreditation); or (iii) common information systems, subsystems, or applications (i.e., common hardware, software, and/or firmware) deployed at multiple operational sites (sometimes associated with the terms type certification/accreditation). Common security controls, typically identified during a collaborative agency-wide process with the involvement of the CIO, SAISO, authorizing officials, information system owners, and information system security officers (and by developmental program managers in the case of common security controls for common hardware, software, and/or firmware), have the following properties:

  • The development, implementation, and assessment of common security controls can be assigned to responsible agency officials or organizational elements (other than the information system owners whose systems will implement or use those common security controls); and
  • The results from the assessment of the common security controls can be used to support the security certification and accreditation processes of agency information systems where those controls have been applied.


Many of the management and operational controls (e.g., contingency planning controls, incident response controls, security awareness and training controls, personnel security controls, and physical security controls) needed to protect an information system may be excellent candidates for common security control status. The objective is to reduce security costs by centrally managing the development, implementation, and assessment of the common security controls designated by the agency-and subsequently, sharing assessment results with the owners of information systems where those common security controls are applied. Security controls not designated as common controls are considered system-specific controls and are the responsibility of the information system owner. System security plans should clearly identify which security controls have been designated as common security controls and which controls have been designated as system-specific controls.

For efficiency in developing system security plans, common security controls should be documented once and then inserted or imported into each system security plan for the information systems within the agency. The individual responsible for implementing the common control should be listed in the security plan. Effectively maximizing the application of common controls in the system security planning process depends upon the following factors:

  • The agency has developed, documented, and communicated its specific guidance on identifying common security controls;
  • The agency has assigned the responsibility for coordinating common security control identification and review and obtaining consensus on the common control designations, to a management official with security program responsibilities such as the CIO or SAISO;
  • System owners have been briefed on the system security planning process including use of common controls; and
  • Agency experts in the common control areas identified have been consulted as part of the process.


An agency may also assign a hybrid status to security controls in situations where one part of the control is deemed to be common, while another part of the control is deemed to be system-specific. For example, an agency may view the IR-1 (Incident Response Policy and Procedures) security control as a hybrid control with the policy portion of the control deemed to be common and the procedures portion of the control deemed to be system-specific. Hybrid security controls may also serve as templates for further control refinement. An agency may choose, for example, to implement the CP-2 (Contingency Plan) security control as a master template for a generalized contingency plan for all agency information systems with individual information system owners tailoring the plan, where appropriate, for system-specific issues.

Information system owners are responsible for any system-specific issues associated with the implementation of an agency's common security controls. These issues are identified and described in the system security plans for the individual information systems. The SAISO, acting on behalf of the CIO, should coordinate with agency officials (e.g., facilities managers, site managers, personnel managers) responsible for the development and implementation of the designated common security controls to ensure that the required controls are put into place, the controls are assessed, and the assessment results are shared with the appropriate information system owners.

Partitioning security controls into common security controls and system-specific security controls can result in significant savings to the agency in control development and implementation costs. It can also result in a more consistent application of the security controls across the agency at large. Moreover, equally significant savings can be realized in the security certification and accreditation process. Rather than assessing common security controls in every information system, the certification process draws upon any applicable results from the most current assessment of the common security controls performed at the agency level. An agency-wide approach to reuse and sharing of assessment results can greatly enhance the efficiency of the security certifications and accreditations being conducted by an agency and significantly reduce security program costs.

While the concept of security control partitioning into common security controls and system-specific controls is straightforward and intuitive, the application of this principle within an agency takes planning, coordination, and perseverance. If an agency is just beginning to implement this approach or has only partially implemented this approach, it may take some time to get the maximum benefits from security control partitioning and the associated reuse of assessment evidence. Because of the potential dependence on common security controls by many of an agency's information systems, a failure of such common controls may result in a significant increase in agency-level risk-risk that arises from the operation of the systems that depend on these controls.

Retrieved from "http://fismapedia.org/index.php?title=NIST_SP_800-18r1_Chapter_2&oldid=31444"