The purpose of Resilience Requirements Development is to identify, document, and analyze the operational resilience requirements for high-value services and related assets.
An operational resilience requirement is a constraint that the organization places on the productive capability of a high-value asset to ensure that it remains viable and can be sustained when charged into production to support a high-value service. In practice, operational resilience requirements are a derivation of the traditionally described security objectives of confidentiality, integrity, and availability. Well known as descriptive properties or quality attributes of information assets, these objectives are also extensible to other types of assets—people, technology, and facilities—with which operational resilience management is concerned.
Resilience requirements provide the foundation for protecting assets from threats and sustaining them to the extent practical and possible so that they can perform as intended in support of services. In essence, resilience requirements become a part of an asset’s DNA (just like its definition, owner, and value) that transcends departmental and organizational boundaries because the requirements stay with the asset regardless of where it is deployed or operated.
Requirements drive engineering-based processes, such as operational resilience management. In operational resilience management, the Resilience Requirements Development process area requires the organization to establish resilience requirements at the enterprise, service, and asset levels. Resilience requirements also drive or influence operational resilience management process areas. For example, resilience requirements form the basis for developing controls and strategies for protecting assets (Controls Management) and for developing service continuity plans for services and assets (Service Continuity).
The importance of requirements to the operational resilience management system cannot be overstated. Resilience requirements embody the strategic objectives, risk appetite, critical success factors, and operational constraints of the organization. They represent the alignment factor that ties practice-level activities performed in security and business continuity to what must be accomplished at the service and asset level in order to move the organization toward fulfilling its mission.
Depending on the organization, three types of operational resilience requirements may be elicited: enterprise, service, and asset.
• Enterprise— Enterprise operational resilience requirements reflect enterprise-level needs, expectations, and constraints. These requirements affect nearly all aspects of an organization’s operations. Laws and regulations are examples of this type of requirement because they broadly affect the business in which an organization operates and must be met by all organizational functions and activities. A specific example of an enterprise requirement is “all health-related information that is covered by HIPAA regulations must be kept confidential to health workers and patients.”
• Service— Service requirements establish the resilience needs of a service in pursuit of its mission. But because the capability of a service to meet its mission is directly related to the resilience of the assets that support the service, service requirements must reflect and be congruent with the operational resilience requirements of supporting assets. Service requirements tend to concentrate on the service’s availability and recoverability, but these quality attributes can be directly affected by failure to meet the confidentiality, integrity, and availability requirements of people, information, technology, and facilities.
• Asset— Asset-specific requirements are set by the owners of the asset and are intended to establish the needs for protecting and sustaining an asset with respect to its role in supporting mission assurance of a service. In practice, asset-specific resilience requirements generally reflect the security objectives of confidentiality and integrity and the continuity requirement of availability. It must be considered that assets also may have conflicting requirements, particularly when they are deployed in supporting more than one service (e.g., a network server may support more than service). This conflict must be resolved to ensure that all services that are dependent on the asset are provided the necessary level of resilience to meet their mission.
The applicability of a specific type of resilience requirement varies depending on the asset type, as shown in Table RRD.1.
Table RRD.1. Extension of Resilience Requirements to All Types of Resilience Assets
There are many ways in which an organization can elicit resilience requirements. Strategic planning efforts may establish enterprise-level requirements, as would direct interviewing of vital organizational managers. Service-level requirements may be established by owners of the service (e.g., an organizational unit or a line of business). Asset-level requirements may be established through regular security risk assessment and business impact analysis activities and through directly interviewing the owners of the assets, who understand their importance to services and are responsible for their productivity and resilience.
All resilience requirements must be analyzed for conflicts and interdependencies and must be validated against and support the accomplishment of enterprise-level organizational drivers (goals, objectives, and critical success factors). Otherwise, the protection and continuity strategies developed and implemented for assets and services will not align with what the organization needs to accomplish in order to remain viable.
The development of resilience requirements typically includes the following activities:
• identifying organizational drivers and preparing these work products so that they can be used as the foundation for setting resilience requirements
• developing and communicating enterprise-level requirements
• developing and communicating service- and asset-level requirements
• regularly analyzing the requirements to ensure alignment with current organizational drivers, to identify conflicts between enterprise- and asset-level requirements, and to satisfy operational constraints
• validating the requirements against organizational drivers and operational constraints
The Resilience Requirements Development process area has three specific goals:
The goals of the Resilience Requirements Development process area are supported and managed long term by achievement of the goals in the Resilience Requirements Management process area.
The identification of high-value assets and the assignment of resilience requirements to assets and services are performed in the Asset Definition and Management process area.
The identification of high-value services is performed in the Enterprise Focus process area.
The identification and prioritization of risks to high-value services and supporting assets is performed in the Risk Management process area.
Resilience requirements are managed in the Resilience Requirements Management process area.
The organization’s enterprise-level resilience requirements are identified and established.
Enterprise-level operational resilience requirements are derived from identified organizational needs. At a strategic level, they establish the requirements that the enterprise imposes on all functions and activities in the organization, as well as externally imposed requirements.
The resilience requirements of the enterprise are established.
Enterprise-level resilience requirements directly reflect strategic drivers and compliance obligations. They establish the requirements that the enterprise imposes on all its functions and activities. This includes any external requirements that the enterprise inherits from its core business affiliations and competitive environment. Regulatory requirements are a common example of external requirements.
Enterprise-level requirements may also be derived from the results of enterprise risk identification activities such as security risk assessments and business impact analyses.
Compliance obligations that may result in or form the basis for enterprise requirements are identified and managed in the Compliance process area.
Strategic objectives and critical success factors that may result in or form the basis for enterprise requirements are identified and managed in the Enterprise Focus process area.
Typical work products
Subpractices
The resilience requirements for services are developed and established based on the service mission and the requirements of supporting assets.
The needs of the organization are satisfied by consistent and efficient performance of services. These services depend on the contributions and support of assets to meet their missions. Thus, the resilience of these assets is paramount to mission assurance.
Owners of services are typically the best sources for developing service-level resilience requirements. However, these requirements are essentially derived from a consideration of the requirements of associated assets. Thus, the assets associated with a service must first be identified, then the contribution of the assets to achieving the service’s mission must be determined, and finally the specific requirements of the assets must be identified. The link between service requirements and the requirements of associated assets is explicit and iterative. Thus, this process requires service owners to work with asset owners (if they are different) to develop requirements that reflect the service’s needs at the asset level.
The resilience requirements of assets as they relate to the services they support are established.
The needs of the organization and the protection and continuity requirements of services are translated into asset-level resilience requirements. In practical application, this requires three distinct activities:
• identification of high-value services (High-value services are those on which the success of the organization’s mission is dependent.)
• identification and association of assets to organizationally high-value services (Mission assurance of services relies on the consistent and effective productivity of related assets—people, technology, information, and facilities. The needs of the service in meeting its mission guide the development of asset-level resilience requirements.)
• development of asset-level requirements based on the asset’s deployment in, contributions to, and support of associated services
Because of the association between services and assets, the resilience requirements of a service are essentially represented by the collective resilience requirements of associated assets.
Typical work products
Subpractices
The identification and prioritization of services that are vital for meeting the organization’s mission are performed in the Enterprise Focus process area.
The identification of assets and the association of these assets to the services that they support are performed in the Asset Definition and Management process area.
Enterprise requirements that affect services are assigned to the services.
The collective set of resilience requirements for a service is not complete until enterprise requirements have been assigned to the service and its associated assets. In some cases, this will cause conflict because an enterprise requirement may be more stringent than a requirement that has already been set for an asset based on its association with a service. For example, an information asset may have no confidentiality requirement based on how it is used in supporting a service, but because it is health-related information, it might be subject to confidentiality and privacy regulations that impose constraints. Thus, the association of enterprise requirements to service and asset requirements may alter these requirements.
Typical work products
Subpractices
The resilience requirements for services are analyzed and validated.
Requirements must be analyzed and validated to ensure that they are aimed at providing the level of resilience that assets need to fulfill their roles in support of a service. The requirements are analyzed by first establishing a baseline understanding of the necessary functionality of an asset and then by determining whether the requirements meet enterprise resilience requirements, standards, regulatory factors, contracts with external entities, etc. The requirements are also analyzed to determine whether there are additional organizational constraints that must be considered before requirements are established. Finally, asset-level requirements are given a careful examination to ensure that they adequately specify what is needed to protect and sustain an asset commensurate with the contribution of the asset to accomplishing a service mission. Conflicts that arise through analysis and validation are identified and addressed.
A definition of the required functionality of assets in the context of the services they support is established and maintained.
The expected behaviors of assets as they are associated with services are established to provide a baseline against which asset-level resilience requirements can be analyzed and validated. This provides a foundation for establishing that the requirements are properly aligned with organizational drivers and that they will provide the appropriate level of resilience when translated into protective controls and service continuity plans.
The required functionality of an asset in the context of a service may be included as part of the asset’s description as produced in the Asset Definition and Management process area.
Subpractices
Because the asset may be associated with one or more services, include in the baseline documentation all of the services with which the asset is associated and the required level of asset functionality in each instance.
The requirements of assets are analyzed to identify conflicts, interdependencies, and shared requirements.
The analysis of asset resilience requirements is performed for two basic reasons: to identify conflicts between the requirements and the required functionality of the asset based on its association with a service, and to identify conflicts that arise because the asset is vital to more than one service requiring differing levels of resilience. This often occurs with information, technology, and facility assets that are shared by more than one service, such as a vendor database, a network server, or a data center facility.
The analysis process is also intended to identify requirements that cannot be met or that are incongruent with the baseline functionality of the asset.
Typical work products
Subpractices
Because the asset may be associated with one or more services, be sure to identify conflicts that arise as a result. Resolve each conflict by revising requirements to fit the functionality of the asset for all instances in which it supports a service.
Asset-level resilience requirements are validated to ensure they adequately specify what is needed to protect and sustain an asset commensurate with its value.
Asset-level requirements are objectively validated (qualitatively) to ensure that they support the required functionality of assets and their associated services. Any risks to protecting and sustaining assets that are introduced by requirements are identified and addressed. A review of the alignment between requirements and the organization’s strategic drivers is performed and any missing or inadequate requirements are identified, reassessed, updated, and analyzed.
Typical work products
Subpractices
Refer to the Generic Goals and Practices document in Appendix A for general guidance that applies to all process areas. This section provides elaborations relative to the application of the Generic Goals and Practices to the Resilience Requirements Development process area.
The operational resilience management system supports and enables achievement of the specific goals of the Resilience Requirements Development process area by transforming identifiable input work products to produce identifiable output work products.
Perform the specific practices of the Resilience Requirements Development process area to develop work products and provide services to achieve the specific goals of the process area.
Elaboration:
Specific practices RRD:SG1.SP1 through RRD:SG3.SP3 are performed to achieve the goals of the resilience requirements development process.
Resilience requirements development is institutionalized as a managed process.
Establish and maintain governance over the planning and performance of the resilience requirements development process.
Refer to the Enterprise Focus process area for more information about providing sponsorship and oversight to the resilience requirements development process.
Subpractices
Elaboration:
Elaboration:
Establish and maintain the plan for performing the resilience requirements development process.
Elaboration:
The plan for the process of resilience requirements development should enable large-scale (either at the enterprise or organizational unit level) development of resilience requirements by owners of organizational assets (particularly information, technology, and facilities assets). The plan should also allow for the distribution of these requirements to custodians who are responsible for implementing strategies to meet the requirements for protecting and sustaining assets in their care or possession. The plan must support both internal staff involved in the process (typically asset owners) as well as external entities (which may include custodians).
Subpractices
Elaboration:
The services to which assets are associated have to be considered to provide insight into the level and extent of resilience requirements necessary. Thus, the plan should take into consideration the plan for establishing and prioritizing organizational services and associating them with assets.
Refer to the Enterprise Focus process area for information about identifying organizational services and associating them with organizational assets.
Provide adequate resources for performing the resilience requirements development process, developing the work products, and providing the services of the process.
Subpractices
Elaboration:
The diversity of asset types (people, information, technology, and facilities) requires that staff assigned to the resilience requirements development process have appropriate knowledge of all assets that need to fulfill resilience requirements and the services with which they are associated.
Refer to the Organizational Training and Awareness process area for information about training staff for resilience roles and responsibilities.
Refer to the Human Resource Management process area for information about acquiring staff to fulfill roles and responsibilities.
Refer to the Financial Resource Management process area for information about budgeting for, funding, and accounting for resilience requirements development.
Elaboration:
Assign responsibility and authority for performing the resilience requirements development process, developing the work products, and providing the services of the process.
Refer to the Human Resource Management process area for more information about establishing resilience as a job responsibility, developing resilience performance goals and objectives, and measuring and assessing performance against these goals and objectives.
Subpractices
Elaboration:
The primary staff involved in the resilience requirements development process are service owners and asset owners and custodians.
Refer to the Enterprise Focus process area for information about identifying organizational services and associating them with organizational assets.
Refer to the Asset Definition and Management process area for more information about establishing asset ownership and custodianship.
Refer to the External Dependencies Management process area for additional details about managing relationships with external entities.
Train the people performing or supporting the resilience requirements development process as needed.
Elaboration:
Expertise in developing resilience requirements requires a strong understanding of each type of resilience requirement (confidentiality, integrity, and availability) as well as the ability to understand strategies (including the internal control system) for protecting and sustaining the various types of assets. Knowledge across multiple functional domains of physical and logical security, business continuity, logistics, and crisis response may also be required.
Refer to the Organizational Training and Awareness process area for more information about training the people performing or supporting the process.
Refer to the Human Resource Management process area for more information about inventorying skill sets, establishing a skill set baseline, identifying required skill sets, and measuring and addressing skill deficiencies.
Subpractices
Resilience requirements must be developed through working knowledge of how an asset is deployed and how it contributes to ensuring the mission of organizational services. Asset owners must be skilled in analyzing the dependencies among assets, services, and organizational goals and mission and translating these dependencies into resilience requirements that ensure that the asset is protected from threats and sustained if threatened. Functional working knowledge of the types of resilience requirements and their impact on assets is essential.
Elaboration:
Information security risk assessment training can provide fundamental knowledge about resilience requirements such as confidentiality and integrity. An active knowledge of business impact analysis techniques can provide foundational knowledge about availability requirements.
Training may also be needed for staff to use requirements development tools, techniques, and methods (particularly those supported by software) to document and analyze requirements.
Place designated work products of the resilience requirements development process under appropriate levels of control.
Elaboration:
Changes in strategic objectives or assets (and the services with which they are associated) will necessitate changes in resilience requirements. Because resilience requirements are the basis for strategies to protect and sustain assets, changes to these requirements may in turn translate to changes in strategies, such as the type and extent of controls and changes to service continuity plans.
Changes to resilience requirements are managed in the Resilience Requirements Management process area.
Identify and involve the relevant stakeholders of the resilience requirements development process as planned.
Elaboration:
Monitor and control the resilience requirements development process against the plan for performing the process and take appropriate corrective action.
Refer to the Monitoring process area for more information about the collection, organization, and distribution of data that may be useful for monitoring and controlling processes.
Refer to the Measurement and Analysis process area for more information about establishing process metrics and measurement.
Refer to the Enterprise Focus process area for more information about providing process information to managers, identifying issues, and determining appropriate corrective actions.
Subpractices
Elaboration:
Elaboration:
The results of periodic reviews should be elevated to higher-level managers to ensure that strategies for protecting and sustaining assets are in alignment with the resilience requirements of these assets (i.e., able to satisfy the requirements) as well as with the organization’s enterprise resilience requirements and strategic objectives.
Objectively evaluate adherence of the resilience requirements development process against its process description, standards, and procedures, and address non-compliance.
Elaboration:
Objective evaluation of the resilience requirements development process is intended to ensure that high-quality resilience requirements are being developed, analyzed, and validated for assets. Because these requirements form the basis for an “engineering” approach to operational resilience management, the process is foundational to all other engineering activities in the model. Inconsistent adherence to the process can result in a lack of requirements or poorly developed requirements, which can cause cascading effects on managing operational resilience that will be realized in other process areas.
Review the activities, status, and results of the resilience requirements development process with higher-level managers and resolve issues.
Elaboration:
Assets that do not have resilience requirements or have poorly developed requirements should be brought to the attention of higher-level managers as a symptom of potential process inadequacies. Audits of the process should be conducted regularly for a wide range of organizational assets to ensure that the process is functioning properly across organizational units and the enterprise.
Refer to the Enterprise Focus process area for more information about providing sponsorship and oversight to the operational resilience management system.
Resilience requirements development is institutionalized as a defined process.
Establish and maintain the description of a defined resilience requirements development process.
Elaboration:
The definition, analysis, and validation of asset resilience requirements are best performed at a level commensurate with direct ownership of the asset. Thus, this process may often be carried out at the organizational unit level. However, to ensure consistency of requirements across organizational units, the process must be tailored from the organization’s enterprise process definition.
Establishing and tailoring process assets, including standard processes, are addressed in the Organizational Process Definition process area.
Establishing process needs and objectives and selecting, improving, and deploying process assets, including standard processes, are addressed in the Organizational Process Focus process area.
Subpractices
Collect resilience requirements development work products, measures, measurement results, and improvement information derived from planning and performing the process to support future use and improvement of the organization’s processes and process assets.
Elaboration:
Establishing the measurement repository and process asset library is addressed in the Organizational Process Definition process area. Updating the measurement repository and process asset library as part of process improvement and deployment is addressed in the Organizational Process Focus process area.
Subpractices