At what tier of the risk management Framework does continuous monitoring take place

The Risk Management Framework (RMF)

The risk management framework, or RMF, was developed by NIST and is defined in NIST Special Publication (SP) 800-37 Revision 1, Guide for Applying the Risk Management Framework to Federal Information Systems. This publication details the six-phase process that allows federal IT systems to be designed, developed, maintained, and decommissioned in a secure, compliant, and cost-effective manner. The framework provides cost savings by promoting reuse as well as reciprocity of information systems approvals and inheritance of organizationally authorized and approved common controls. The requirement for continuous monitoring is a significant improvement over the older four-phase certification and accreditation (C&A) process, which only looked at a system at a single point in time. The more structured and robust RMF process increases compliance and security by requiring near-real-time monitoring of the IT system over its entire lifetime. Figure 1-1 illustrates the phases of the old C&A process and the phases of the new RMF process.

NIST Risk Management Framework

The Risk Management Framework (RMF) released by NIST in 2010 as a product of the Joint Task Force Transformation Initiative represented civilian, defense, and intelligence sector perspectives and recast the certification and accreditation process as an end-to-end security life cycle providing a single common government-wide foundation for security management activities. The RMF replaced the prior NIST process with six steps instead of four, as shown in Figure 2.6, dedicating key steps in the process to security activities such as security control selection, implementation, and assessment that were previously addressed as sub-processes within C&A phases. The revised guidance in Special Publication 800-37 Revision 1 de-emphasizes the use of the terms certification and accreditation, in both the title and the body of the document, in which the words appear exactly once, and then only to refer to the previous version of the publication [64]. The document refers instead to system authorization, matching usage in Appendix III of OMB Circular A-130 and connoting a departure from the narrower focus on C&A to new areas of emphasis for the RMF. The RMF features explicit integration with the software development life cycle, identifying the relevant SDLC phase for every task described in each step. Special Publication 800-37 Revision 1 continues to apply primarily to individual information systems, but addresses the role of information security risk management at all layers of the organization and emphasizes the goals of more pervasive monitoring of operational systems and timely provision of key security information to organizational leadership with responsibility for managing risk. The six steps and subordinate tasks in the RMF are described in detail in Chapters 7, 8, and 9Chapter 7Chapter 8Chapter 9.

Abstract

The Risk Management Framework acknowledges that organizations have widely varying missions and organizational structures, so there may be differences in naming conventions for risk management–related roles and how specific responsibilities are allocated among organizational personnel. However, the basic functions remain the same. The application of the Risk Management Framework is flexible, allowing organizations to effectively accomplish the intent of the specific tasks within their respective organizational structures to best manage information system–related security risks. Many risk management roles have counterpart roles defined in the routine system development life cycle processes carried out by organizations. Whenever possible, organizations should align the risk management roles with similar (or complementary) roles defined for the system development life cycle. This chapter describes the objectives of various roles such as authorizing official, chief information officer, information system owner.

RMF Phase 1: Categorize the System

The RMF consists of six phases, as illustrated in Figure 6-2. Notice that the RMF is cyclic rather than linear in its execution, illustrating that the framework is implemented over the system’s entire life cycle. The phases of the framework and their associated tasks are briefly mentioned in this chapter and are covered in greater detail later in the book, with a chapter devoted to each phase.

The first phase is composed of three tasks that begin to define the system and develop the foundation for the system and the system’s documentation, including the system security plan (SSP). Task 1-1 is to categorize the information system and document the results of the security categorization in the security plan. Task 1-2 defines the information system, including many specific details such as the system boundary, identification of the system’s security professionals, and other administrative and technical details of the system. Task 1-3 ensures that the system is registered with the appropriate organizational or management offices; in many cases this is a portfolio management office or program management office that will track and monitor all organizational systems.

Sources of Weaknesses

The Risk Management Framework focuses almost exclusively on security control assessments—both for newly authorized systems and operational systems under continuous monitoring—as sources of weaknesses or deficiencies that result in POA&M items [6]. Specifically, information system owners address security assessment report findings of other-than-satisfied control assessment objectives in their plans of action and milestones. System owners and common control providers should also be aware of many other potential sources used to identify weaknesses, such as those described in Table 12.3, and include corrective actions taken in response to those weaknesses on the POA&M as well.

Table 12.3. Additional Sources of System Security Weakness and Deficiency Information

The NIST risk management framework (RMF)

The NIST Risk Management Framework (RMF) was designed for unclassified information. Unclassified information used to be referred to as Sensitive But Unclassified (SBU), however, that terminology has been replaced with Controlled Unclassified Information (CUI). The framework for the NIST RMF methodology is described in a publication known as NIST Special Publication 800-37, Revision 1, Guide for Applying the Risk Management Framework. A copy of it is available online at http://www.csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf.

The NIST standards and methodology are updated more frequently than any of the others. Additionally, the NIST high-level methodology document, SP 800-37 includes a vast amount of supporting documents that complement the foundational guidelines. Prior to updating their guidelines, NIST goes to a lot of trouble to solicit review and comments from both public and private industries, which greatly enhance the quality of their publications. They receive thousands of comments and painstakingly comb through each one of them—intellectual crowdsourcing at its best.

The NIST guidance is well written and easy to follow. SP 800-37, Revision 1 provides a framework—following it won’t answer all your compliance questions as it leaves some room for interpretation to allow flexibility. Agencies and bureaus embracing the NIST RMF typically use NIST Special Publication 800-37, Revision 1 as a guide to develop their own internal process and handbook customized for their own unique requirements. In essence, NIST Special Publication 800-37, Revision 1 is a call to action and provides to agencies a “to do” list for information security program plans, information security control selection and implementation, policies, procedures, training, and security business processes that need to be put into place.

The NIST RMF process takes you through all the different steps of the security life cycle and this is discussed at a more in-depth level in Chapter 4. The different deliverables that are discussed in this book are consistent with the deliverables noted in the NIST RMF. I’ll be talking more about the NIST RMF in Chapter 4.

Risk Associated with Information Systems

With enterprise risk management as a backdrop, the standards and guidance issued by NIST, OMB, DHS, and other government authorities in support of agency FISMA implementation and compliance focus on the management of risk associated with federal information systems. Achieving the goals of adequate security and consistent and effective risk management entails active engagement at all organizational levels—a theme reflected in NIST’s overarching risk management guidance in Special Publication 800-39, Managing Information Security Risk: Organization, Mission, and Information System View. As shown in Figure 3.3, the approach NIST recommends combines an integrated set of risk management processes and activities performed using the collaborative efforts of risk management stakeholders responsible for individual information systems, the mission functions and business processes those systems support, and the overall management of the organization. Chapter 13 describes in more detail the primary risk management responsibilities associated with each tier of the organization. NIST addresses all organizational levels in its risk management guidance to agencies, but it targets some of that guidance to individual risk management processes and to activities primarily performed at specific tiers of the organization. Table 3.1 identifies key sources of guidance and the risk management aspects on which they focus. The clear implications underlying federal guidance on risk management are that information security risk management is an essential component of organizational management and that managing risk effectively requires the active engagement of risk management stakeholders through the organization.

Table 3.1. Key Sources of Federal Guidance on Risk Management

Other Risk Management Frameworks Used in Government Organizations

The Government Accountability Office (GAO) developed a Risk Management Framework in 2005 that is substantially similar to the NIST life cycle described above. GAO first published its Risk Management Framework as part of a report describing the need for more effective risk assessment in support of homeland security and critical infrastructure protection [44]. In deciding to develop a new framework, GAO noted the unfulfilled responsibility assigned to the Department of Homeland Security in 2003 to establish risk management policies, guidelines, and methodologies for use throughout the homeland security sector [45]. As shown in Figure 3.4, the GAO included five processes in its risk management life cycle, each of which corresponds to a similarly defined process in Special Publication 800-39. Since its development, GAO has applied its Risk Management Framework to agencies and contexts outside the homeland security sector, and updated its guidance to incorporate aspects of the COSO Enterprise Risk Management Framework, including initial evaluation of the internal environment to establish the context for risk management and establishment of information and communication across all levels of the organization [46]. In current usage, the life cycles defined by NIST, GAO, and COSO essentially describe the same risk management processes; Table 3.2 provides a side-by-side comparison of all three models.

Figure 3.4. The Risk Management Framework Recommended by the GAO for Use in Federal Homeland Security and Critical Infrastructure Protection is Structurally Similar to the NIST Risk Management Process, Emphasizing an Iterative Cycle of Assessment, Evaluation and Response, and Monitoring in Support of Organizational Goals and Objectives

Table 3.2. Life Cycle Processes in Risk Management Frameworks

NIST [3]	GAO [46]	COSO [17]
• Frame	• Internal environment • Strategic goals, objectives, and constraints	• Internal environment • Objective setting
• Assess	• Risk assessment	• Event identification • Risk assessment
• Respond	• Alternatives evaluation • Management selection	• Risk response
• Monitor	• Implementation and monitoring	• Control activities • Monitoring
• Information and communication flows	• Information and communication	• Information and communication

The convergence of Risk Management Frameworks developed to address different types of risk in different kinds of organizations suggests that risk management guidance has matured to the point where organizations agree on the set of processes and activities that should be implemented. The commonality between risk management models does not mean that all organizations have achieved similar levels of effectiveness in their risk management practices, for risk management generally or with respect to managing information security-related risk. Subsequent chapters on risk management and risk assessment (Chapter 13), planning for and executing the steps in the Risk Management Framework (Chapters 6–9Chapter 6Chapter 7Chapter 8Chapter 9), and continuous monitoring (Chapter 14) all provide information intended to guide risk management stakeholders at all levels of the organization to understand their roles, responsibilities, and expectations in helping organizations effectively manage risk associated with information systems.

Boundary and Scope Definition

The NIST RMF and the ISO/IEC “Plan-Do-Check-Act” (PDCA) focuses on applying a structured, risk-based approach for the integration of information security. Both NIST (800-37 Revision 1—RMF Step 1) and the ISO/IEC (27001—Clause 4.2.1.a) require the identification of a boundary34 around the information system.35 However, within the ISO/IEC process, the scope (or boundary) typically includes the organization and the information system that maintains and has control over the information system. To effectively characterize the boundary and scope of protection,36 processes require the organization to define the associated policies,37 assets, technologies, locations, and personnel.

Risk Management Framework Overview

The NIST RMF20 is a flexible, risk-based approach that is driven by the organization’s information security program, and supports the management of risk21 by facilitating the sharing22 of information. The NIST RMF objectives [4] include:

Building information security capabilities into federal information systems;

Maintaining awareness of the security state of information systems through ongoing continuous monitoring; and

Providing essential information to key stakeholders to facilitate decisions regarding the acceptance of risk.

Risk management is an essential element of the NIST RMF, which requires linking risks to an organization-wide information security program. This enables the organization to have a broader view of risks, including those across all information systems within the enterprise. Since the NIST RMF is a more technical approach, organizations will need to ensure that risk-based decisions are considered from a strategic viewpoint where the impact to the organization’s goals and objectives is more visible.

For the NIST RMF to be effective, the organization needs to identify and communicate program-level security requirements that all information systems within the enterprise should meet. This also limits the duplication of risk management activities where common capabilities can be integrated or even shared by each information system within the overall organization-wide information security program. In this section, we will briefly discuss the role of the risk management when applying the NIST RMF and how closely aligning the system development life cycle (SDLC) processes enables security-related information produced during the SDLC to be reused to support the risk management process.

The Role of Risk Management

The effective application of the NIST RMF requires the integration of risk management23 activities at different levels within an organization. As illustrated in Fig. 5.1, the risk management process begins at the organizational level (Tier 1) where the governance structure and risk management strategy are developed.

Figure 5.1. Tier risk management approach.

The risk management strategy24 supports the organization’s strategic goals and objectives. To link the risk management strategy with the mission and business processes (Tier 2), risk management should be addressed as a part of the enterprise architecture.25 Finally, at the information system level (Tier 3), the appropriate safeguards and countermeasures are applied to the information and information system through the selection, implementation, and assessment of security controls that have traceability to the security requirements26 established by the organization and allocated within the information security architecture. This alignment between the NIST RMF and the SDLC is critical to ensure there is an early integration of security with the appropriate inputs from stakeholders across the organization.

The NIST RMF and the System Development Life Cycle

As previously discussed, the alignment of activities included in the NIST RMF with a traditional SDLC27 ensures risk management becomes an integrated part of the information system life cycle. At each phase of the SDLC, as illustrated in Fig. 5.2, specific security considerations are integrated, starting at the initiation phase where requirements definition begins.

Figure 5.2. Security consideration in the system development life cycle (SDLC).

Security requirements28 addressed later within the SDLC instead of including them in the original system design could unnecessarily increase costs and delay the authorization process. By defining NIST RMF activities within the context of the system development process, weaknesses, and deficiencies identified early in the SDLC could improve the effectiveness of security testing performed later in the NIST RMF (e.g., assessing and monitoring security controls). Since information systems typically exist at some phase of the SDLC and will continue to evolve throughout their life cycle, integrating the NIST RMF into the life cycle process enables risks to be mitigated or eliminated through information security and risk management-related activities. For example, the security-related information produced through development security testing may be reused later in SDLC (e.g., implementation/assessment or the operation/maintenance phases).