RMF Phase 2

Selecting Security Controls

Abstract

This chapter introduces the second phase of the RMF: selecting the correct security controls.

Table of Contents

Chapter Overview and Key Learning Points

In this chapter common controls will be identified and their inheritance will be verified by validating the controls approval to operate indicating they are valid to be inherited. Security controls will be selected based on the information types and organizational mission defined in the last step, additionally a monitoring strategy will be developed that ensures the security controls required for compliance and security are functioning as required. The systems security plan will be developed ensuring it details the application of the correct security controls and has the required components after it is developed it will be approved by the AO completing this step. The chapter concludes with exercises that will reinforce the steps in this part of the RMF.

Selecting Security Controls

The activities in phase 2 of the RMF serve as a bridge in the system development ife cycle with an RMF-required milestone document, an approved SSP serving as a gate deliverable between phases 1 and 2 of the SDLC. Information systems will be in phase one, the initiation phase, of the SDLC when they enter phase 2 of the RMF but exit phase 2 of the RMF in the second phase of SDLC, the development or acquisition phase. It is important for the organization to understand the relationship between the RMF and SDLC and add the required RMF deliverables to the organization’s SDLC program.

Identification of common controls reduces the number of controls that the information system developer or system owner is required to implement by detaching common controls that have been authorized and are available for inheritance from the security control set the information system owner is responsible for implementing and maintaining. Selecting the security controls for the system defines the specific security requirements for the information set and information system itself. These selected controls require the development of a maintenance program that will provide continuous monitoring of the protections provided by these controls and the continued functionality of the controls themselves. Finally, the information from phase 2 is added to the information gathered in phase 1 to finalize a system security plan, which can then be approved by the authorizing official.

Dissecting Security Controls

Before beginning any of the tasks in this phase it is important to understand the structure of the security controls contained in the security controls catalog. The best way to understand the structure of these controls is by reviewing the components of one security control and its enhancements. For this example, we look at Control AC-2, Account Management. Each component of the control is discussed after the example. The example is quoted from SP 800-53 and reads as follows:

The security control structure is composed of five sections; these are described from top to bottom and are control section, supplemental guidance section, control enhancement section, references section, and the priority and baseline section.

The Control Section

The header of the control begins with the controls identifier. This is a two-part alphanumeric designation for each individual control, and in this case the identifier is AC-2. This identifier can be broken into two parts: the two-character alphabetical family identifier and the numeric designation for the number of the control in the family. In this case, “AC” indicates this control is in the access control family and “2” indicates it is the second control in that family. This designation is followed by the control’s name; for AC-2, the control name is “Account Management” and completes the control’s title. The eighteen control families are listed in Table B-1 in Appendix B.

The next portion of the control selection describes the specific requirements needed to provide a specific security protection and comply with the control. In this example, AC-2 has ten requirements (a through j) that the organization must meet as it manages information system accounts. The final item, j, “reviewing accounts,” has an organizationally defined variable that must be defined; in this case, setting the frequency that the accounts must be reviewed. Organizationally defined variables give the organization the opportunity to tailor some controls to support specific organization, mission, or system requirements. For an information system owner to meet the requirements of this control, he or she must build into the system the ability to manage system accounts in compliance with these ten requirements. If the information system owner fails just one of the ten requirements, the control will be determined to be non-compliant during the controls assessment.

Supplemental Guidance

The supplemental guidance section of the control does not provide any specific requirements needed to comply with the control but rather provides additional information related to the specific control. This information further defines the control and provides important considerations for defining, designing, and implementing the controls. This section serves to describe how the control should be implemented and what the intent of the control is. The final portion of this section contains a listing of controls that have components that are related to or support this control.

Control Enhancement Section

The control enhancement section defines additional components that can be added that will provide additional security functionality or increase the strength of the control. The control enhancements are numbered sequentially; in this case, 1 through 7. The enhancements, unlike the requirements listed in the control section, are treated as individual requirements, allowing for individual enhancements to be selected based on security control baseline, tailoring, or compensating control guidance.

The number of enhancements required can vary greatly based on the information system’s categorization. As can be seen in Table D-2 in SP 800-53, the variation of the number of enhancements between low, moderate, and high for all controls can be evaluated. Evaluation of the control AC-2 underscores this, as systems implementing the control with a low baseline will only be required to implement the base control with no enhancements. Moderate systems, on the other hand, will be required to implement the baseline control AC-2 and enhancements 1 through 4. Additionally, organization and system tailoring can add, and in some cases remove, enhancements from the information system’s baseline. Before implementing control enhancements, it is important for organizations to define the organizationally defined variables for each of the enhancements that indicate this requirement; in the case of AC-2, they are enhancements 2, 3, and 5a.

Reference Section

The reference section defines appropriate federal, legislative, and policy mandates that impact or drive the control. These could be federal laws, executive orders, directives, policies, standards, or guidelines, including OMB circulars, FIPS, NIST, and SP. The reference section can also contain websites, publications, or other resources that provide guidance or information on the control. In the case of AC-2, there are no references listed.

Priority and Baseline Allocations Section

The final section is a table that provides two key factors for implementing the control: the priority and the baseline allocation. The priority is used for sequencing the controls from P1 to P3 but also includes P0. When the system owner begins implementing the control, he or she can use the priority code to sequence the order the controls need to be implemented in. This is especially important if there is a possibility that some of the controls or enhancements may not be implemented due to time constraints, as items with a higher priority will be implemented before those of a lower priority. Security controls listed as P1 should be implemented first, followed by those listed as P2, which in turn are followed by P3. The code P0 is used for controls not selected in any of the baselines of low, moderate, or high and is integrated into the prioritization based on the direction of the information system owner, AO, and SISO. The baseline allocation defines the minimum control and enhancements required based on the system’s categorization. By matching the system’s categorization of low, moderate, or high to the correct block, Low, Mod, or High, the baseline for the information system is defined. In the case of AC-2, Low only requires the implementation of the base control and Moderate and High require the baseline plus enhancements 1 through 4.

Task 1, Phase 2: Common Control Identification

The introduction of the concept of common controls is one of the features that increases the effectiveness and efficiency of authorizing an information system using the RMF. Through the proper use of common controls, organizations can reduce the amount of duplication of effort caused by implementing and assessing identical control requirements at different levels in the organization and in different information systems. NIST identifies three benefits of maximizing the use of common controls in the organization: “(i) significantly reduces the cost of development, implementation, and assessment of security controls; (ii) allows organizations to centralize security control assessments and to amortize the cost of those assessments across all information systems organization-wide; and (iii) increases overall security control consistency.” This means that if the control is effectively managed by the higher level in the organization and this control is providing the required level of protection to one or more systems, it can be appropriately authorized and inherited by organizational systems and other programs that can leverage and use the control organization-wide without having to authorize the same control at the system level. This is one example of how inheritance can increase the efficiency and effectiveness of the RMF. If all of the organization’s information systems reside in a single data center, the physical security protections for that location could be identified, assigned to a common control provider, and processed for an approval.

The approval process for common control sets follows the RMF with a control provider (person or group) being identified as responsible for the control, or group of controls, and an authorizing official (AO) being selected to assume responsibility for the security of the controls by providing the controls with an authorization to operate. This authorization document, as well as other documentation from the common control provider, forms the body of evidence—records that can be reviewed by information system owners and information owners to ensure that the controls offered are providing the levels of protection required. After reviewing the protections offered by the common control providers, system owners can elect to inherit the controls, alleviating the need to implement them at the system level. If the system owner decides to inherit the controls, they would simply document the inheritance in the system security plan by defining the inheritance from the common control provider or referencing the common controls’ security plan and body of evidence.

In many organizations, common controls are identified by the chief information officer and the senior information security officer, in collaboration with the information security architect and those officials representing the offices that are responsible for developing and maintaining the common control or controls. The organization selects senior organizational officials or executives to serve as the authorizing official for specific controls or groups of controls. The common control providers follow the RMF to develop a body of evidence similar to that of the information system owner’s, with only slight modifications. The authorizing official then evaluates the protections provided by the controls through formal control assessments and the documents presented to the AO in the control’s body of evidence. This body of evidence includes a common control security plan or equivalent document, findings from a qualified and independent security controls assessment team presented in a security assessment report (SAR), a plan of action and milestones (POA&M) developed by the common control provider for those controls that have been identified as not meeting specified requirements, and a continuous monitoring plan for the controls identified as assigned to this common control provider. The AO uses this information, along with input from the organization’s risk executive (function), to make an informed decision on authorizing the controls and accepting responsibility for the controls’ effectiveness. If the AO believes the controls are effective, or are effective when implemented with the POA&M, he or she can issue the common control provider an approval to operate (ATO), allowing the controls to then be inherited by other organizational units or systems within the organization. This is done for all controls in the organization that can be considered to be common controls from those listed in the controls catalog (NIST 800-53). The final output from this exercise should be a listing of the organization’s common control providers, and for each of these providers, a listing of the controls approved for inheritance.

The organization’s system owners and developers must remain diligent to ensure that the controls they are inheriting are, in fact, approved to be inherited and have a valid ATO.

The fact that common controls can be authorized, implemented, and maintained at high levels in the organization and can then be inherited by system owners, reducing the number of controls that need to be implanted at the system level, is one of the advantages of using the RMF. Common control providers are responsible for ensuring that the controls they are in control of are authorized like any information system before offering them for inheritance by other programs or information systems. Many departments, groups, and sections of an organization should be assessed to determine the applicability of defining these areas as common control providers, including, but not limited to, training, physical and personnel security controls, and high-level organizational policy. For example, most organizations develop a number of high-level organizational policies that include a number that can be mapped directly to required security controls.

These policies are first evaluated to determine which individual security controls and enhancements are met by the policies. These controls and enhancements can then be grouped into a common, logical package under a single common control provider; in most cases, an individual or group that will maintain the controls. Each of the common controls in the provider’s control set is evaluated to ensure that it is providing the required level of protection for the organization. The packet is processed and presented to the AO or designated authorizing official (DAO), who will then make a determination on authorizing the controls or denying them authorization. If the controls are authorized, they enter a continuous monitoring phase, like any system would, ensuring that they continue to provide the protection needed. These controls can then be inherited by systems, other programs in the organization, and in some cases, by programs and systems outside the organization. In this case, system owners are not responsible for developing individual policies when a more effective method is to inherit the approved overarching control set offered by the common control provider.

Careful evaluation of each control in the controls catalog will lead an organization to effectively assign a number of the controls to different common control providers in the organization, making the RMF much more efficient than other older certification and accreditation processes by evaluating and authorizing these controls once at higher levels of the organization, instead of each time a system is developed or re-evaluated. Proper development of common control providers can result in hundreds of controls being removed from the responsibility of the system owners and developers and responsibility transferred to the organizational common control providers.

The process of developing common controls, common control providers, evaluating common security controls, and maintaining these controls at the organizational level at the highest possible level can reduce the burden of developing, assessing, and maintaining these controls multiple times and in multiple locations in different systems, reducing system development cost for the organization; it will lead to providing a secure structure for security control maintenance. This will not only reduce the cost associated with security control management but will also reduce system development time by reducing the number of controls information system owners are required to implement at the system level.

While implementation of common controls are effective for most systems, some system developers, system owners, and data owners may decide that a common control does not provide the required level of security needed by the system design or information type. In this case, the security engineer can decide to inherit a common control and then add additional security features, creating a hybrid control that is managed by both the organization common control provider and the information system owner. In this case, the organization’s common control provider manages and is responsible for the portion of the control that is included in the authorized common control, and the system owner is responsible for and manages the control or enhancements required by the system’s design or agreements between stakeholders. For example, an organization may have a training department that develops, presents, and tracks general user security training on an annual basis. A system owner and an AO may determine that the users of the system being developed require additional training based on specific technologies. Many organizations that implement mobile devices require these users to take additional training for the use of these devices. In these cases, the user computer security training responsibility is shared between the organization providing annual basic user security training and the system developing, presenting, and tracking specific training for the mobile devices; the control is then categorized as a hybrid control and managed by both.

Controls in the control set that will be inherited as common controls from the organization or other systems should also be thoroughly documented in the security plan. The documentation can summarize the control’s implementation or simply reference the common control provider or information system’s body of evidence, including the applicable security plan. Information system owners should carefully examine the security authorization packages for all inherited controls to ensure that the control’s authorization is still valid and the protections provided by the control provider provide adequate protection for the information system and the data it contains. Controls that do not provide adequate security can be reinforced and enhanced by the system owner, resulting in a hybrid control, or the system can reject the inheritance entirely and implement the control fully in the system’s design.

In addition to controls that can be inherited from organizational common control providers and other organizational information systems, controls can also be inherited from external providers through contracts, interagency agreements, licensing, and other agreements. The organization defines the services to be provided, describes how the external services will be protected by the provider, and evaluates the risk introduced by using this provider, ensuring that it is at a level that is acceptable to the organization.

The effective use of the common control structure requires planning and coordination at various levels of the organization, including organization, business, and system levels. Failure of a common control in a provider’s common control set not only impacts that control provider but also every system owner and business component that has inherited the control. It is advisable to ensure that common control providers are diligent in implementing the approved continuous monitoring plan to validate that all of the controls in the control set are working as planned.

Task 2, Phase 2: Security Control Selection

Security control selection is the process of using the system’s categorization to identify the security controls required by the security controls catalog (NIST SP 800-53). The security controls catalog currently defines over six hundred controls and enhancements that can be implemented to secure information systems and programs, and this number is planned to jump to over eight hundred when revision 4 of the catalog is released. In fact, by the time this book is published, it is possible that revision 4 of SP 800-53 will be out of draft and in full publication. This does not mean that all of these controls need to be, or should be, implemented on every system or even in every organization. Instead, having this wide selection of controls allows the information security architect and system owner to select those controls that are needed to properly secure the information system and its data based on specific configurations and requirements. The authorizing official, information systems security officer, and information systems security engineer can assist the information system security architect and information system owner in this task to ensure that it is completed as accurately as possible.

In phase 1, the information system was categorized High, Moderate, or Low using the high water mark based on the information types processed and other system characteristics. The system’s categorization can now be used to select the security baseline controls. This is done by identifying the system’s categorization, evaluating the controls listed in the security controls catalog, and identifying the controls required at the selected categorization level. For example, a system categorized at the moderate level would have a baseline that includes every control from the catalog that is noted under the MOD (moderate) column of table D-2: Security Control Baselines, in the security controls catalog. A section of table D-2 is presented in the following figure, showing the controls in the access control family (AC).

Evaluation of this table uncovers thirty-five controls or enhancements required in the AC family for systems with a moderate categorization. These controls and enhancements are: AC-1, AC-2, AC-2(1), AC-2(2), AC-2(3), AC-2(4), AC-3, AC-4, AC-5, AC-6, AC-6(1), AC-6(2), AC-7, AC-8, AC-11, AC-14, AC-14(1), C-17, AC-17(1), AC-17(2), AC-17(3), AC-17(4), AC-17(5), AC-17(7), AC-17(8), AC-18, AC-18(1), AC-19, AC-19(1), AC-19(2), AC-19(3), AC-20, AC-20(1), AC-20(2), and AC-22. This process is done for each of the remaining families, resulting in a table or listing of every control or enhancement required by the information system’s categorization. This resulting set of controls becomes the security control’s baseline and is also the beginning of the system’s security controls tractability matrix (SCTM), a document that is covered in more detail later. Many organizations list these controls in a spreadsheet application to organize the security requirements of the system as it develops, while other organizations opt to invest in specific tools to assist in system approvals that also manage the SCTM. The baseline serves as a starting point for developing a comprehensive set of controls that can be used to provide information system and data security. This baseline sets the basic security requirements that will be required to be built into the system based on the system’s categorization, but does not include all the controls that may be required. When completing this task, considerations should be made to include system scoping, parameterization, and compensating control guidance to help design the correct control set selection.

Once the baseline control set is determined, the controls can be further tailored to provide a custom set of security controls that address the security concerns for each unique system. Scoping or tailoring is the act of adding or removing controls as needed to develop a control set that is customized to provide protection for each particular information system. Adding controls can increase cost and time to the system’s development, but increasing system security and removing controls can expose the system to unnecessary risk while reducing control implementation costs and system development time; therefore, this step must be completed carefully and accurately. Enhancing the control set is often needed to ensure that unique system design and environmental characteristics are factored into the security considerations for the system. Uniqueness in the organizational security needs is normally developed from the organization’s risk management process and often identifies distinctive threats that must be factored into the control set tailoring.

Controls that are not required, do not provide added protection, or are not applicable to the system can be removed from the system’s baseline by the authorizing official by providing written documentation. The system security plan is then updated, listing the controls that have been removed from the baseline, the justification for their removal, and who authorized the removal. The AO, with help from the information system owner and information owner, will also document controls that have been added to the control set through tailoring, as well. Controls may be added to the control set to counter specific risks and threats from identified vectors and to meet the requirements of specific technologies or architectural designs. Many organizations require that the AOs provide written tailoring guidance be included as an appendix to the SSP. The controls that remain in the baseline after removing the common controls, as well as controls that were removed or added in the tailoring process, are then added to the security plan as the system’s required security control set and become the required set of security controls. The documentation of each of these controls in the SSP should be in enough detail to allow system and security engineers to ensure that the system’s design and development comply with each control. To ensure that this level of detail is conveyed to the system security engineer, the organization should train these engineers in the use of NIST SP 800-53 to further define the controls and NIST SP 800-53A to detail how the controls are assessed, to ensure that they are providing the required level of protections.

Parameterization is the process of defining organizational, business unit, or system specific characteristics for controls that have variables that have been left open by NIST for assignment at the organization level or below. As an example, review AC-1 in security controls catalog SP 800-53. The control is defined as follows: “Control: The organization develops, disseminates, and reviews/updates [Assignment: organization-defined frequency]: a. A formal, documented access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and b. Formal, documented procedures to facilitate the implementation of the access control policy and associated access controls.” The assignment value identified by the square brackets is a placeholder awaiting definition by the organization. The specific value assignment can be done for each control with a variable at the organizational level or distributed throughout the organization at the organizational level, business level, and information system level; in any case, the requirement to define these variables should be done in writing.

As the values for these variables are defined, the organization should develop a repository for storing and accessing the approved minimum values for these variables. Using the example presented earlier of AC-1, the organization could define the frequency as at least annually. On the other hand, while it is not advisable for this control, the organization could pass the assignment of this variable to the business or even system level. The delegation of responsibility for providing the requirements for variables at the business or system level could make more sense for some of the controls in the catalog, but it is recommended that the majority of these variables be defined at the organizational level to promote uniformity across the organization. A concentrated effort should be made at the organizational level to define and make available the organizationally defined variables for each of the controls and enhancements in the security controls catalog. If this is the case, the organization should update the local implementation of the controls catalog to indicate the level at which this parameter should be defined, for example, at the business, information system, or common control provider level.

Compensating control guidance is used when a required security control can’t be implemented as required by the security controls catalog, including any additional organizationally required variables. The compensating control guidance provides additional security measures in a manner different than that directed by the control to provide a level of protection that is commensurate with the protections that would be in effect if the security control were implemented correctly. For example, assume there is a requirement that each user use a unique identifier to access the information system (IA-4). Further assume that the system in development is being designed as a watch terminal, meaning many different users could be required to use the same user credentials during a period of time, which is a mission requirement. In this case, additional physical, manual logging of individuals on shift (the watch) should be required as well as ensuring that the logging procedures define when system access is to be logged. This compensating control is evaluated by the AO, with assistance from the risk executive (function) and the SISO, to determine if the compensating control mitigates the security gap remaining if the required security control is not implemented. The use of compensating controls is only used in situations that meet strict requirements. According to NIST SP 800-53, the compensating control can only be used if the compensating control is selected from the controls catalog itself, the agency or organization provides justification detailing how the compensating control will provide an equivalent level of protection or security to the system (as would the baseline control), and the agency or organization formally assesses and accepts the risks associated with implementing the compensating control in writing.

Net-centric systems provide unique challenges when developing control sets. In these architectures, subsystems can be added and removed quickly and dynamically as the user’s needs change. In these cases, the system designers and security professionals need to evaluate each subsystem to determine the security impact to the overarching system as each subsystem is implemented. In some cases, the introduction of a new subsystem will not change the security posture of the overarching system and no modifications to the control set will be needed. In other cases, the subsystem will introduce increased risk or a technology that will change the overall control baseline. In these cases the controls can be implemented in the subsystem’s design without impacting the larger system’s assessment, or the subsystem changes may cause the entire overarching system to be reassessed prior to allowing that subsystem to operate. In any case, new controls that are required by the subsystem’s inclusion must be documented in the overarching systems security plan.

When implementing a system with dynamic subsystems, the security plan for the overarching system should contain descriptions of the subsystem’s functions, security controls implemented by each subsystem, subsystem constraints and assumptions, subsystem dependencies, and the impact that each subsystem will have on the main system if that subsystem is implemented. The security plan should also contain documents that ensure that the subsystem conforms with the overarching security plan and requirements. Finally, procedures for determining that required controls are implemented in the subsystem must be in place. The subsystem’s implementation is monitored over the system’s life cycle and the system security plan is updated as changes to the subsystem or threat environment occur. In addition to major changes, aggregate minor changes to the individual subsystem over time could result in a security-relevant change to the system that would require reassessment of the entire system or removal of that specific subsystem.

In some cases, careful evaluation at the organizational level may find controls that are not required based on the organization’s authorized technological architecture and approved technologies. For example, if the organization has a policy prohibiting wireless technology, many controls designed to secure wireless communication devices can be removed from the organization’s control set, with the organization determining the controls that would remain. In this case of wireless technology, the organization may decide to remove all controls impacted by wireless technology, with the exception of the controls requiring a wireless policy (making it unauthorized) and those controls used to monitor for unauthorized wireless devices and connections. The determination to remove controls from the baseline set of the organizationally defined control set is normally done in a formal, documented communication by the organization’s AO. To be most effective, this organizational-level tailoring should take place before system tailoring even begins.

The security controls selection based on the security control’s baseline after scoping, compensating control guidance, and parameterization becomes the system’s required control set. This control set is added to the system’s security documentation and includes a plan on how each control will be implemented in the SSP. This listing also becomes the required controls that are listed in the security controls tractability matrix (SCTM).

Task 3, Phase 2: Developing a Monitoring Strategy

The organization must develop a continuous monitoring plan, for each control, that will detail the volatility and vulnerability of the control, which will in turn determine the frequency and level of effort that each control’s implementation and effectiveness will be reviewed. This task ensures that the system developers have planned for changes that will happen to a system over time throughout the life of the information system. To be effective, the organization should develop an organizational continuous monitoring program that monitors security controls in an ongoing manner to ensure that they remain effective across the enterprise. The system developers should build upon this organizational continuous monitoring plan by developing a continuous monitoring strategy for those controls that the system is responsible for entirely, or in the case of hybrid controls, the portion of the control that the system is responsible for maintaining. Common control providers should also use the organizational plan as a base for the control set’s continuous monitoring strategy. In this way, the overarching organizational continuous monitoring program is supplemented and reinforced by the common control provider and information systems owner’s plans, while the common control provider and information system owner gain structure and guidance from the organization’s plan.

Many people are confused about continuous monitoring and incorrectly believe the continuous monitoring strategy and plan should only cover technical controls. Not only is this incorrect, but it could also leave systems and programs unprotected from a full range of threats and reduce the RMF’s ability to reduce reauthorization timelines. To be effective, the organization’s continuous monitoring strategy and the CCP/information system’s continuous monitoring program should monitor all of the controls that are listed in the system’s SCTM and the organization should monitor all of the controls as required across the enterprise technical, operational, and managerial classes of controls. NIST has developed a publication, titled Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, SP 800-137, that describes how to develop a continuous monitoring program for a system or organization.

The system owner and common control provider, with help from the risk executive (function), authorizing official, chief information officer, senior information security officer, information owner, and information systems security officer, develop a plan to monitor the security controls employed within or inherited by the information system. The common control provider is responsible for continuously monitoring those controls that they have been approved to be offered for inheritance and the information owner is responsible for monitoring those controls that have not been inherited or are inherited and reinforced (hybrid controls) on a continuous basis. To be most effective, this plan should be developed early in the system’s development life cycle, normally in the design phase or the COTS procurement process. System development decisions should be based on the overall cost of developing and maintaining the system over time. For the decisions to be effective, organizational decision-makers and budget officials must know not only the cost of developing the system, but also the cost of operating and maintaining (O&M) the system over time, including developing and monitoring security controls. This O&M must include the cost of security control monitoring in order to provide a full picture of the system’s overall cost to the organization. In some cases, the cost alone of correctly implementing a continuous monitoring program can make a system too costly to justify continued development.

The continuous monitoring program can give system managers and organizational leadership a view of the state of evolving vulnerabilities and threats, as well as changes in the system’s mission or technology as they relate to the system’s implementation of the required security controls. The information provided by the continuous monitoring program allows leadership, including the authorizing official, to remain aware of the risk posture of the information system as it impacts the risk status for the organization. Updates can be done with output from the continuous monitoring program and input from the risk executive (function).

According to NIST SP 800-37 Revision 1, Guide for Applying the Risk Management Framework to Federal Information Systems, an effective continuous monitoring program includes: “(i) configuration management and control processes; (ii) security impact analyses on proposed or actual changes to the information system and its environment of operation; (iii) assessment of selected security controls employed within and inherited by the information system (including controls in dynamic subsystems); and (iv) security status reporting to appropriate organizational officials.”

The program should define how each control in the SCTM will be monitored and the frequency of the monitoring. This frequency should be based on the security control’s volatility, or the amount of time the control can be assumed to be in place and working as planned between reviews. A security impact analysis can help organizations to determine the monitoring strategy and frequency between the control’s review. Additionally, organizational historical documentation, including documentation of past security breaches or security incidents, can assist in developing the frequency that each control will be monitored.

Many times, organizational leadership, including the agency or organizational leader, the chief information officer, the authorizing official, or the chief information security officer will identify controls that require a higher level of monitoring, such as depth of monitoring and frequency, based on organizational mission or threat.

The continuous monitoring plan also evaluates system changes implemented on the system to ensure that they do not constitute a security-relevant change that will require the information system to undergo a reauthorization, nullifying the current ATO. While this is normally monitored through the system or organization’s configuration or change management plan, the continuous monitoring program is an excellent check and balance to the organization’s configuration/change management program.

Once the continuous monitoring plan’s development is complete, the authorizing official or a designated representative reviews the plan for completeness, noting any deficiencies. If the plan is acceptable, the AO can approve the plan. If, however, there are significant deficiencies, the AO can return the plan to the information system owner or common control provider for corrections. The authorizing official also ensures that the plan does not place unnecessary or unrealistic burdens on the organization by requiring reauthorization of the information system each time a new subsystem is added or removed and has not compromised the accepted security posture of the overall system. Based on this authorization, the level of continuous monitoring and frequency for each control is defined, allowing the system developers and engineers to begin incorporating the monitoring plan into the system development and O&M plan.

Organizational leadership may determine that the required continuous monitoring plan is too costly for the organization. If this is the case, the leadership, including the AO, need to determine if the organization’s risk posture allows the system to operate without the continuous monitoring of the controls in question. If the risk posture does not allow this operation, the information system may need to be re-engineered or the development canceled.

Once the system’s continuous monitoring plan has been developed, finalized, and approved, this information is added to the security documentation, either in the SSP itself or as an attachment.

Task 4, Phase 2: Reviewing and Approving the Systems Security Plan (SSP)

The final task in phase two of the risk management framework is for the authorizing official or designated representative to approve the systems security plan (SSP). Up to this point, there has been good deal of information added to the systems security plan, including the system categorization, baseline security documentation, security control set based on control baseline, tailoring guidance, and how each control will be implemented, as well as the proposed continuous monitoring plan. The SSP is required by FISMA and should define how the security controls for the system have been, or are planning to be, implemented to provide adequate, cost-effective security for the system or control set. The SSP documents the responsibilities that all users with any level of access to the system will have and, along with the security assessment report (SAR) and plan of action and milestones (POA&M), forms the basis for system authorization. The SSP can be tailored by the organization but should contain the minimum sections as required by NIST SP 800-37 and SP 800-18.

The security plan should reflect the most current state of the system and indicate areas where the security controls or settings are planned but not yet in place. The document should include much of the system’s security details, but can also reference a number of supporting documents, including the security assessment report (SAR), the risk assessment report (RAR), the plan of action and milestones (POA&M), the contingency plan, any interconnection agreements (ICA), privacy impact assessments (PIA), the configuration management plan, the continuous monitoring plan, security checklists, user and administrator guides, user rules of behavior, and the approval to operate (ATO). The SSP should also have sections that detail the plan to implement each of the security controls that are required, based on completing the control’s baseline determination, tailoring or scoping, compensating control guidance, and parameterization.

Appendix G contains templates and examples of many of these documents, including the SSP, and the plan of action and milestones. The accompanying disk for this book, available at www.cyber-recon.com, contain more templates and examples of documents used throughout the RMF process. In many cases, it is effective to standardize the format and required content for each of these documents at the organizational level while providing a degree of flexibility for minor changes and additions at the business or system level. For example, the controls contained in the user rules of behavior should cover, at a minimum, delineation of user responsibility, interconnection limitations, service provisions and restoration priorities, consequences if the user fails to follow the rules of behavior requirements, and rules covering many of the normal user actions, such as working from a remote location, use and storage of copyrighted works, password usage system physical protection, rules governing the use of government equipment, and more.

The authorizing official reviews the systems security plan with input from the risk executive (function), the chief information officer, the chief information security officer, and others as needed to ensure that the plan is complete, constant, and meets the security requirements for the system. The plan should detail the impact to the system, the organization, and the nation should the system be allowed to operate in the production environment, based on implementation of the selected security controls. The authorizing official or designated representative may find the plan unacceptable and return it to the system owner for further modification or improvement to meet the official’s requirements. Once the plan is deemed acceptable, the AO will formally approve the plan. This approval signifies that the AO or designated representative agrees that the selected security control set is appropriate to protect the system and organization and that the system’s developers’ plan to implement the controls is acceptable. The completion date and the approval date of the SSP should be added to the document itself. The completion date should be updated whenever the plan is updated or reviewed, versioning numbers added after the first review, and updated on each subsequent change. If the organization has mapped the RMF to the SDLC, an approved SSP will be a required document for system to advance from phase 1 of the SDLC to phase 2. This helps to ensure that the security requirements for the system are included as early as possible, increasing their effectiveness and reducing cost to the organization or program.

The security plan must be continually updated as needed but no less than once each year. There are a number of factors that require the plan to be updated that may also require the system to reapply for authorization. These include: changes to the information system owner, the information security representative, or changes in the system architecture; system status; system scope; the authorizing official; and the authorization status. Additions or deletions of system connections, the discovery of new system vulnerabilities, or changes in the system’s information types and reactions must also be documented in the SSP and may also prompt reauthorization.

Chapter 10 Lab Exercises: Selecting Security Controls

The lab exercises in this chapter use NIST SP 800-53, which is available on the book’s accompanying disk, downloadable at http://www.cyber-recon.com or at the NIST website, http://csrc.nist.gov/publications/PubsSPs.html.

1. After determining the system’s security categorization as moderate, the next step for the DSM is to identify those controls that could be inherited from the organization’s common control providers. The information owner has worked with the senior information security officer, information architect, and information system security architect to identify the organization’s common control providers. The group determined that the physical security office, personnel security office, and training department have identified common controls that their groups will be responsible for. While each of these areas claims to have valid authorizations for their controls, only the physical and personnel security offices could provide valid ATOs. The personnel security common controls’ ATO will expire in two months and the physical security common controls’ ATO will expire in two years. Only the physical security group has been following the approved continuous monitoring plan approved by the AO.

         Identify the common control providers that should be used in developing this system.

2. The system was categorized as having a security categorization of moderate. What controls will make up the system’s control baseline? How many controls did you identify?

3. A continuous monitoring strategy is developed in this phase of the system’s design. One of the controls identified in the baseline control set is RA-5(1) Vulnerability Scanning and reads as follows:

         The organization employs vulnerability scanning tools that include the capability to readily update the list of information system vulnerabilities scanned.

         How would a continuous monitoring strategy be developed for this control?

4. Who approves the systems security plan (SSP)?