This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Industry:Project Review/NIST SP 800-37r1 FPD Chapter 2
CHAPTER TWO
THE FUNDAMENTALS
BASIC CONCEPTS ASSOCIATED WITH MANAGING RISK FROM INFORMATION SYSTEMS
This chapter describes the basic concepts associated with managing information security-related risks from information systems. These concepts include: (i) incorporating risk management principles and best practices into organization-wide strategic planning considerations, core missions and business processes, and supporting organizational information systems; (ii) integrating information security requirements into system development life cycle processes; (iii) establishing practical and meaningful boundaries for organizational information systems; and (iv) allocating security controls to organizational information systems as system-specific, hybrid, or common controls.
2.1 INTEGRATED ENTERPRISE-WIDE RISK MANAGEMENT
Managing risks from information systems is a complex, multifaceted undertaking that requires the involvement of the entire organization—from the senior leaders providing the strategic vision and top-level goals and objectives for the organization, to the mid-level leaders managing projects and implementing systems, to the individuals on the front lines developing, implementing, and operating the systems supporting the organization's core missions and business processes. Risk management can be viewed as a holistic activity that is fully integrated into every aspect of the organization. Figure 2-1 illustrates a hierarchical, three-tiered approach to risk management that addresses risk-related concerns at: (i) the organization level; (ii) the mission and business process level; and (iii) the information system level.<ref>NIST Special Publication 800-39, Integrated Enterprise-Wide Risk Management: Organization, Mission, and Information System View (projected for publication in 2010), will provide guidance on the holistic approach to risk management.</ref>
Risk management at Tier 1 addresses risk from the organizational perspective with the development of a comprehensive governance structure and enterprise-wide risk management strategy that includes: (i) the techniques and methodologies the organization plans to employ to assess risk from information systems and other types of risk of concern to the organization;<ref>Other types of risk include, for example: (i) acquisition risk (cost, schedule, performance); (ii) compliance and regulatory risk; (iii) financial risk; (iv) legal risk; (v) operational (mission/business) risk; (vi) political risk; (vii) program/project risk; (viii) reputational risk; (ix) safety risk; (x) strategic planning risk; and (xi) supply chain risk.</ref> (ii) the methods and procedures the organization plans to use to evaluate the significance of the risks identified during the risk assessment; (iii) the types and extent of risk mitigation measures the organization plans to employ to address identified risks; (iv) the level of risk the organization plans to accept (i.e., risk tolerance); (v) how the organization plans to monitor risk on an ongoing basis given the inevitable changes to organizational information systems and their environments of operation; and (vi) the degree and type of oversight the organization plans to use to ensure that the risk management strategy is being effectively carried out. As part of the overall governance structure established by the organization, the risk management strategy is propagated to organizational officials and support contractors with developmental, operational, and oversight responsibilities, including for example: (i) authorizing officials (including mission and business owners); (ii) chief information officers; (iii) senior information security officers; (iv) enterprise/information security architects; (v) information system owners/program managers; (vi) information owners/stewards; (vii) information system security officers; (viii) information system security engineers; (ix) information system developers and integrators; (x) system administrators; and (xi) users.
Managing risk at Tier 2 addresses risk from a mission and business process perspective and is guided by the risk management-related decisions taken at Tier 1. Tier 2 activities are integral to enterprise architecture<ref>Federal Enterprise Architecture Reference Models and Segment and Solution Architectures are defined in the OMB Federal Enterprise Architecture (FEA) Program, FEA Consolidated Reference Model Document, Version 2.3, October 2003 and OMB Federal Segment Architecture Methodology (FSAM), January 2009, respectively.</ref> and organizational assessments of risk and include: (i) defining the core missions and business processes for the organization (including any derivative or related missions and business processes carried out by subordinate organizations); (ii) prioritizing missions and business processes with respect to the goals and objectives of the organization; (iii) defining the types of information that the organization needs to successfully execute the stated missions and business processes and the information flows both internal and external to the organization; and (iv) developing an organization-wide information protection strategy and incorporating high-level information security requirements into the core missions and business processes; (v) specifying the degree of autonomy for subordinate organizations (i.e., organizations within the parent organization) that the parent organization permits for assessing, evaluating, mitigating, accepting, and monitoring risk.
The first two activities are necessary because there may be different priorities associated with organizational missions and business processes (including derivative or related missions and business processes) that need to be factored into the weighting of risk calculations—both within specific elements of the organization as well as for the overall risk tolerance of the organization. The early incorporation of information security requirements into the organization's missions and business processes helps to ensure that risk-related considerations are effectively integrated into the organization's enterprise architecture and system development life cycle processes. The last activity reflects the diversity of mission/business needs and the availability of resources across the organization. Because subordinate organizations responsible for carrying out derivative or related missions and business processes may have already invested in their own methods of assessing, evaluating, mitigating, accepting and monitoring risk, parent organizations may allow a greater degree of autonomy within parts of the organization or across the entire organization in order to minimize costs. When a diversity of risk assessment methods is allowed, organizations employ some means of translation and/or synthesis of the risk-related information to ensure that the output of the different risk assessment activities can be correlated in a meaningful manner.
Risk management at Tier 3 addresses risk from an information system perspective and is guided by the risk management decisions taken at Tier 2. Risk management decisions taken at Tier 2 impact the ultimate selection and deployment of needed safeguards and countermeasures (i.e., security controls) at the information system level. Information security requirements are satisfied by the selection of appropriate management, operational, and technical security controls from NIST Special Publication 800-53. The security controls are subsequently allocated to the various components of the information system as system-specific, hybrid, or common controls.<ref>The allocation of security controls can take place at all three tiers in the risk management hierarchy. For example, security controls that are identified as common controls may be allocated at the organization, mission/business process, or information system level. See Section 2.4 for additional information on security control allocation.</ref> Security controls can be provided by the organization or by an external provider. Relationships with external providers are established in a variety of ways, for example, through joint ventures, business partnerships, outsourcing arrangements (i.e., through contracts, interagency agreements, lines of business arrangements), licensing agreements, and/or supply chain exchanges.<ref>Appendix I provides additional guidance regarding external service providers and the provision of security controls in external environments.</ref>
Risk management tasks begin early in the system development life cycle and are important in shaping the security capabilities of the information system. If these tasks are not adequately performed during the initiation, development, and acquisition phases of the system development life cycle, the tasks will, by necessity, be undertaken later in the life cycle and be more costly to implement. In either situation, all tasks are completed prior to placing the information system into operation or continuing its operation to ensure that: (i) information system-related security risks are being adequately addressed on an ongoing basis; and (ii) the authorizing official explicitly understands and accepts the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the implementation of a defined set of security controls and the current security state of the information system.
Tier 3 risk management assumes the integration and tight coupling of the six-step Risk Management Framework (RMF) into the system development life cycle. The framework, illustrated in Figure 2-2, provides a disciplined and structured process that operates within the system development life cycle to effectively manage information system-related security risks. The RMF steps include:
- Categorizing the information system and the information processed, stored, and transmitted by that system based on a worst-case impact analysis.<ref>FIPS 199 provides security categorization guidance for nonnational security systems. CNSS Instruction 1253 provides similar guidance for national security systems.</ref>
- Selecting an initial set of baseline security controls for the information system based on the security categorization; tailoring and supplementing the security control baseline as needed based on an organizational assessment of risk and local conditions.<ref>NIST Special Publication 800-53 provides security control selection guidance for nonnational security systems. CNSS Instruction 1253 provides similar guidance for national security systems.</ref>
- Implementing the security controls and describing how the controls are employed within the information system and its environment of operation.
- Assessing the security controls using appropriate assessment procedures to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.
- Authorizing information system operation based on a determination of the risk to organizational operations and assets, individuals, other organizations, and the Nation resulting from the operation of the information system and the decision that this risk is acceptable.
- Monitoring the security controls in the information system on an ongoing basis including assessing control effectiveness, documenting changes to the system or its environment of operation, conducting security impact analyses of the associated changes, nvironment of operation, conducting security impact analyses of the associated changes, and reporting the security state of the system to designated organizational officials.
Chapter Three provides a detailed description of each of the specific tasks necessary to carry out the six steps in the RMF.
In summary, there is a significant degree of flexibility in how organizations employ the risk management processes described above. While it is convenient to portray the risk management approach in Figure 2-1 as hierarchical, the reality of project and organization dynamics can be much more complex. The organizational management style may be at one or more points on the continuum from top-down command to consensus among peers. For risk management to succeed at all levels of the organization, the organization must have a consistent and effective approach to risk management that is applied to all risk management processes and procedures.
2.2 SYSTEM DEVELOPMENT LIFE CYCLE
All federal information systems, including operational systems, systems under development, and systems undergoing modification or upgrade, are in some phase of the system development life cycle.<ref>There are typically five phases in a generic system development life cycle including: (i) system initiation; (ii) system development/acquisition; (iii) system implementation; (iv) system operations/maintenance; and (v) system disposition.</ref> Requirements definition is a critical part of the system development process and begins very early in the life cycle, typically in the system initiation phase.<ref>Organizations may employ a variety of system development life cycle processes including, for example, waterfall, spiral, or agile development.</ref> Security requirements are a subset of the overall functional requirements levied on an information system and therefore, whenever possible, are incorporated into the system development life cycle at the earliest opportunity. Without the early infusion of security requirements, significant expense may be incurred by the organization later in the life cycle to address security considerations that could have been included in the initial design. This may also result in less than effective information security solutions. Organizations prioritize information system requirements, both functional and security-related, in accordance with the strategic objectives of the organization, its core missions and business processes, and operational considerations.
Integrating information security requirements into the system development life cycle is the most cost-effective and efficient method for an organization to ensure that its protection strategy is implemented. It also ensures that information security processes are not isolated from the other routine management processes employed by the organization to develop, implement, operate, and maintain information systems supporting ongoing missions and business functions. In addition to incorporating information security requirements into the system development life cycle, security requirements are also integrated into the program, planning, and budgeting activities within the organization to ensure that the resources are available when needed. The enterprise architecture provides a central record of this integration within an organization. As part of their ongoing management and oversight responsibilities, organizational officials ensure that adequate resources are allocated to information security. Organizational officials identify the resources necessary to complete the risk management tasks described in this publication and ensure that those resources are made available to appropriate personnel. Resource allocation includes both funding to carry out the risk management tasks and assigning the personnel needed to accomplish the tasks.<ref>Resource requirements include funding for training organizational personnel to ensure that they can effectively carry out their assigned responsibilities.</ref>
Using the well-established concept of integrated project teams,<ref>Integrated project teams are multidisciplinary entities consisting of individuals with appropriate skills and expertise to help facilitate the development of information systems that meet the requirements of the organization.</ref> security professionals are an integral part of any information system-related development activities. Making information security requirements an integral part of all types of system development life cycle processes (e.g., waterfall, spiral, agile development) helps to ensure that senior leaders consider information security risks to organizational operations and assets, individuals, other organizations, and the Nation and take appropriate actions to mitigate these risks. Such consideration is used to foster close cooperation among personnel responsible for the design, development, implementation, operation, maintenance, and disposition of information systems and the information security professionals advising the senior leadership on appropriate security controls needed to adequately mitigate risk and protect critical missions and business functions.
Finally, organizations maximize the use of security-relevant information (e.g., assessment results, information system documentation, and other artifacts) generated during the system development life cycle to satisfy requirements for similar information needed for information security-related purposes. Similar security-relevant information concerning common controls, including controls provided by external providers, is factored into the organization's risk management process. Reuse of information is an effective method to help eliminate duplication of effort, reduce documentation, and avoid unnecessary costs that may result when security activities are conducted independently of system development life cycle processes. In addition, reuse promotes greater consistency of information used in the design, development, implementation, operation, maintenance, and disposition of an information system including security-related considerations.
2.3 INFORMATION SYSTEM BOUNDARIES
One of the most challenging problems for information system owners, authorizing officials, chief information officers, senior information security officers, and information security architects is identifying appropriate boundaries for organizational information systems. Well-defined boundaries establish the scope of protection for organizational information systems (i.e., what the organization agrees to protect under its direct management control or within the scope of its responsibilities) and include the people, processes, and information technologies that are part of the systems supporting the organization's missions and business processes. Information system boundaries need to be established in coordination with the security categorization process and before the development of security plans. Information system boundaries that are too expansive (i.e., too many system components and/or unnecessary architectural complexity) make the risk management process extremely unwieldy and complex. Boundaries that are too limited increase the number of information systems that must be separately managed and as a consequence, unnecessarily inflate the total information security costs for the organization. The following sections provide general guidelines to assist organizations in establishing appropriate system boundaries to achieve cost-effective solutions for managing information security-related risks from the operation and use of information systems.
2.3.1 Establishing Information System Boundaries
The allocation of information resources<ref>Information resources consist of information and related resources including personnel, equipment, funds, and information technology.</ref> to an information system defines the boundary for that system. Organizations have significant flexibility in determining what constitutes an information system. If a set of information resources is identified as an information system, the resources are generally under the same direct management control.<ref>For information systems, direct management control involves budgetary, programmatic, or operational authority and associated responsibility and accountability.</ref> Direct management control does not necessarily imply that there is no intervening management. It is possible for multiple information systems to be validly considered as independent subsystems<ref>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.</ref> of a larger and more complex system provided all of the subsystems fall under the same management authority. This situation may arise in many organizations when smaller information systems are coalesced for purposes of risk management into a larger, more comprehensive system. In addition to consideration of direct management control, it may also be helpful for organizations to consider if the information resources being identified as an information system:
- Support the same mission/business objectives or functions and essentially the same operating characteristics and information security requirements; 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).<ref>Similarity of operating environments includes, for example, consideration of threat, policy, and management.</ref>
While the above considerations may be useful to organizations in determining information system boundaries for purposes of risk management, they are not viewed as limiting the organization's flexibility in establishing commonsense boundaries that promote effective information security within the available resources of the organization. Information system owners consult with authorizing officials, chief information officers, senior information security officers, the risk executive (function),<ref>The roles and responsibilities of the Risk Executive (Function) are described in Appendix D.</ref> and information security architects when establishing or changing system boundaries. The process of establishing boundaries for information systems and the associated risk management implications is an organization-level activity that includes careful negotiation among all key participants—taking into account mission and business requirements, technical considerations with respect to information security, and programmatic costs to the organization.
Software applications are included in the boundary of an information system hosting the applications and do not require a separate risk management process (including a separate security authorization). Rather, software applications take advantage of the security controls provided by the hosting information system to help provide a foundational level of protection for the hosted applications. Additional application-level security controls are provided by the respective software applications, as needed. Employing strong configuration management and control processes within the hosting information system and reusing assessment evidence of security control effectiveness helps to provide the necessary protection for applications. Security controls provided by the hosted software application are documented in the security plan for the hosting information system and assessed for effectiveness during the risk management process (including during the initial authorization or subsequent to the initial authorization if the applications are added after the system is authorized to operate). Organizations ensure that all security controls, including application-level controls employed in separate software applications, are managed and tracked on an ongoing basis. Information system owners ensure that hosted applications do not affect the security state of the hosting system. Information system owners obtain the necessary information from hosted applications to conduct security impact analyses, when needed.
2.3.2 Boundaries for Complex Information Systems (System of Systems)
The application of security controls within a large and complex information system (or system of systems) can present significant challenges to an organization. From a centralized development, implementation, and operations perspective, the information system owner, in collaboration with the authorizing official, senior information security officer, information security architect, and information system security engineer, examines the purpose of the information system and considers the feasibility of decomposing the complex system into more manageable components, or subsystems. From a distributed development, implementation, and operations perspective the organization recognizes that multiple entities, possibly operating under different policies, may be contributing to the development, implementation, and/or operations of the subsystems that comprise the overall information system. In such a scenario, the organization is responsible for ensuring that these separate subsystems can work together in both a secure and functional manner. Treating an information system as multiple subsystems, each with its own subsystem boundary, facilitates a more targeted application of security controls to achieve adequate security and a more cost-effective risk management process. The decomposition into subsystem components is reflected in the security plan for that complex system (or system of systems).
Information security architecture plays a key part in the security control selection and allocation process for a large and complex information system (or system of systems). This includes monitoring and controlling communications at key internal boundaries and providing system-wide common controls (see Section 2.4) that meet or exceed the requirements of the constituent subsystems inheriting those system-wide common controls. One approach to control selection and allocation is to categorize each identified subsystem (including dynamic subsystems as described in Section 2.3.3). Separately categorizing each subsystem does not change the overall categorization of the information system. Rather, it allows the constituent subsystems to receive a separate allocation of security controls from NIST Special Publication 800-53 instead of deploying higher impact controls across every subsystem. Another approach is to bundle smaller subsystems into larger subsystems within the overall complex information system, categorize each of the aggregated subsystems, and allocate security controls to the subsystems, as appropriate. While subsystems of complex information systems may sometimes exist as full systems, for complex systems, these portions of the system are not treated as independent entities because the subsystems are typically interdependent and interconnected.
In addition to protecting the external boundary of a large and complex information system (or system of systems), the organization may, as part of the information security architecture, implement boundary protection between subsystems (possibly represented by different security domains). Such internal boundary protection is part of an overall defense-in-depth architecture implemented by the organization. The policy implemented in each boundary protection device may be specific to the permitted information flows through that boundary, but is also consistent with the information security architecture for the organization as a whole.
When the results of security categorizations for the identified subsystems are different, the organization carefully examines the interfaces among subsystems and selects security controls for interconnection of the subsystems to eliminate or reduce potential vulnerabilities in this area. This helps to ensure that the information system (at large) is adequately protected.<ref>Tightly coupled subsystem components may introduce inadvertent weak links in a complex information system (system of systems). For example, if a large organizational intranet is decomposed by enterprise services into smaller subsystems (e.g., severable components such as local area network segments) and subsequently categorized individually, the specific protections at the subsystem level may allow a vector of attack against the intranet by requiring security controls commensurate with a lower impact level, than the rest of the system. To avoid this situation, organizations are encouraged to carefully examine the interfaces among subsystem components and to take appropriate actions to eliminate potential vulnerabilities in this area, thus helping to ensure that the information system is adequately protected.</ref> Security controls for interconnection of subsystems are also employed when the subsystems implement different security policies or are administered by different authorities (i.e., the subsystems belong to different security domains). Common controls provided by different organization often require such boundary protection interface controls. The extent to which the security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the complex system, can be determined by combining security control assessments at the subsystem level and adding system-level considerations addressing interface issues among subsystems. This approach facilitates a more targeted and cost-effective risk management process by scaling the level of effort in accordance with that subsystem's security categorization and allowing for reuse of assessment results at the system level. Figure 2-3 illustrates the concept of decomposition for a complex information system.
- Security plan reflects information system decomposition with security controls assigned to each subsystem component.
- Security assessment procedures tailored for the security controls in each subsystem component and for the combined system level.
- Security control assessment performed on each subsystem component and on system-level controls not covered by subsystem security control assessments.
- Security authorization conducted on the information system as a whole.
In the above example, an information system contains a system guard that monitors the flow of information between two local area networks. The information system, in this case, can be partitioned into multiple subsystem components: (i) local area network one; (ii) local area network two; (iii) the system guard separating the two networks; and (iv) several dynamic subsystems that become part of the system at various points in time (see Section 2.3.3). Each subsystem component within the information system may be categorized individually. The security categorization of the information system is determined by taking into consideration all of the individual subsystem categorizations. When all subsystems within the information system have completed the security control assessment, an additional assessment is performed on the system-level security controls not covered by the individual subsystem assessments, and the results are bundled together into the authorization package and presented as evidence to the authorizing official.
2.3.3 Dynamic Subsystems
For many information systems,, the determination of subsystems is established at system initiation and maintained throughout the life cycle of the system. However, there are some instances, most notably in net-centric architectures (e.g., cloud computing, service-oriented architectures),<ref>A net-centric architecture is a complex system of systems comprised of subsystems and services that are part of a continuously-evolving, complex community of people, devices, information and services interconnected by a network that enhances information sharing and collaboration.</ref> where the subsystems that compose the system may not be present at all stages of the life cycle. Some subsystems may not become part of an information system until sometime after system initiation, while other subsystems may leave the system sometime prior to system termination. Generally, this will not impact the external boundary of the information system if the dynamic subsystems are in the system design and the appropriate security controls are reflected in the security plan. But it does impact the subsystems that exist within the boundary at any given point in time.
Dynamic subsystems that become part of an organizational information system at various points in time may or may not be under the direct control of the organization. These subsystems may be provided by external providers (e.g., through contracts, interagency agreements, lines of business arrangements, licensing agreements, and/or supply chain exchanges). Regardless of whether the subsystem is or is not controlled by the organization, the expectations of its capabilities have to be considered. The dynamic inclusion or exclusion of the subsystems may or may not require reassessment of the information system as a whole. This is determined based on constraints and assumptions (e.g., functions the subsystems perform, connections to other subsystems and other information systems) imposed upon the subsystems at system design and incorporated in the security plan. So long as the subsystems conform to the identified constraints and assumptions, they can be dynamically added or removed from the information system without requiring reassessments of the system.
As noted above, the assumptions and constraints on the dynamic subsystems are reflected in the information system design and the security plan. The determination as to whether the subsystems conform to the assumptions and constraints is addressed during the continuous monitoring phase of the risk management process. Depending upon the nature of the subsystems (including the functions, connections, and relative trust relationships established with the subsystem providers), the determination of conformance may be performed in a manual or automated manner, and may occur prior to, or during the subsystem connecting/disconnecting to the information system.
2.4 SECURITY CONTROL ALLOCATION
There are three types of security controls for information systems that can be employed by an organization: (i) system-specific controls (i.e., controls that provide a security capability for a particular information system only); (ii) common controls (i.e., controls that provide a security capability for multiple information systems); or (iii) hybrid controls (i.e., controls that have both system-specific and common characteristics).<ref>NIST Special Publication 800-53 provides additional guidance on security controls for organizational information systems.</ref> As illustrated in Figure 2-4, security controls are allocated to organizational information systems as system-specific, hybrid, or common controls. The allocation of security controls is consistent with the organization's enterprise architecture and information security architecture. As part of the information security architecture, organizations are encouraged to identify and implement security controls that can support multiple information systems efficiently and effectively as a common capability (i.e., common controls). When these controls are used to support a specific information system, they are referenced by that specific system as inherited controls. Common controls promote more cost-effective and consistent information security across the organization and can also simplify risk management activities. By allocating security controls to an information system as system-specific controls (e.g., access controls, identification and authentication controls, system communications and protection controls, audit controls), as hybrid controls (e.g., contingency planning controls), or as common controls that are inherited (e.g., physical and environmental protection controls, awareness and training controls, personnel security controls), the organization assigns responsibility to specific organizational entities for the development, implementation, assessment, authorization, and monitoring of those controls.
Footnotes
<references />
