Criticality Analysis Procedure Definition The organization either develops procedures that would guide the criticality analysis, or, if such procedures exist, finds them and, if needed, tailors them to the specific needs of the program. None Documented Criticality Analysis Procedures Project Manager in charge of the criticality analysis Program Manager can delegate the execution of this process to a Business Analyst or other suitable individual. Individuals who understand the organizations’ operational environment; individuals with project management, process management, or criticality analysis experience; individuals who developed the criticality analysis model being tailored. Individuals responsible for conducting any part of the criticality analysis. [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.3.1) Project Planning Process [NIST SP 800-161] – (2.2.1) Frame Define/Tailor Criticality Analysis Procedures Develop procedures for conducting a criticality analysis by adapting this Model to the organization’s structure, environment, and existing processes. If a criticality analysis procedure has already been adapted by an organization, tailor or refine that procedure to the needs and environment of the specific criticality analysis being conducted. The criticality analysis procedure: • defines the scope, • describes any assumptions to be made, • identifies responsible parties, and • details the procedures to be used in conducting the analysis. It may be tailored to, for example, existing procedures which supersede or align closely with procedures in the model, define how specific sub_processes are to be completed, or rearrange the sub_processes to better fit organizational processes. Because the criticality analysis will likely be performed by multiple groups and individuals, ensure that the proceedure definition includes requirements as to how the groups and individuals are to communicate. Include requirements for any documents that may be transferred between individuals; ensure those individuals have appropriate permissions to review the information in those documents. Include in the procedure what events or conditions (i.e., triggers) result in the need for a criticality analysis. Some organizations may also define the events or conditions (i.e., triggers) that will launch each stage(s) of the analysis. Describe what events or conditions (i.e., triggers) necessitate a full or partial review/update of existing criticality analysis, and how those events or conditions will be monitored for and reported. For example, a review/update may be needed if a new vulnerability is discovered, the environment of operation changes, or a modification to a portion of the system is proposed. Some organizations may choose to regularly review their criticality analyses. Carefully review the scope and purpose of the review. When defining roles and responsibilities, include individuals responsible for, accountable for, consulted on, or informed about each process and sub_process in this Model. Define how and when these individuals will communicate. This is especially important in cases where different organizational units or third parties will be conducting portions of the analysis. Consider any relevant contractual requirements. Relevant Laws, Regulations, Directives, etc. Strategic Plan(s) Risk Management Strategy Budgets Documented Criticality Analysis Procedures Project Planning; Document Review [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.3.1) Project Planning Process [NIST SP 800-161] – (2.2.1) Frame Conduct Program-Level Criticality Analysis Define, review, and analyze the program to identify key activities that are vital to reaching the objectives of the program and for reaching the overall goals of the organization. This process ensures that that the criticality determinations for systems/subsystems and components/subcomponents can be directly traced back to the objectives of the program and the goals of the organization. Documented Criticality Analysis Procedures (from Process A) Relevant Laws, Regulations, Directives, etc. Strategic Plan(s) Risk Management Strategy Past Audit Reports/Recommendations Budget Project Plan(s) Contingency Plan Process Description and/or Diagram Baseline Criticality Levels of Activity(ies) and/or Workflow Path(s) Program Manager responsible for the performance of this process. Business Analyst and Lead Security Engineer may serve as a co-lead for sub_processes B.4, Define Operating States, and B5, Assign Baseline Criticality Levels to Workflow Path(s). Program Manager can delegate the execution of this process to a Business Analyst or other suitable individual. Individuals who have detailed knowledge of the activities identified by this process contribute to the identification of such activities. These individuals may include system architects and designers, system engineers, security or privacy engineers, other security or privacy professionals, acquisition/procurement professionals, business leaders, legal experts/general council, and others, as appropriate. Invite representatives of each relevant group to participate in this process. Individuals responsible for conducting any part of the criticality analysis. [ISO 21500] [ISO/IEC 22301] [ISO/IEC 27001] [NIST SP 800-34] [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.1) Business or Mission Analysis Process [NIST SP 800-160] – (3.4.2) Stakeholder Needs and Requirements Definition Process [NIST SP 800-161] – (2.2.1) Frame Define or Obtain Program-Level Needs, Goals, Objectives, Assumptions and Constraints This process helps define the program being analyzed. It lays the foundation for the criticality analysis, establishes context, and provides a common perspective on the assumptions, constraints, risk tolerances, and priorities/trade-offs used for making investment and operational decisions. Define how the success or failure of the program will be measured. Identify a high-level objective or set of related objectives. It is best if there is only one objective or if the set of objectives are closely related to focus the analysis. Measurable goals for the objective(s) are described and include any high-level organizational goals that apply. Consider security, safety, privacy, and other related goals. If there are several objectives and goals, consider their priorities and documenting these priorities. Requirements or constraints are clearly identified and may include applicable legal regulations, organizational policy, risk tolerance, budgets, and any other constraints that may impact the flexibility of the organization’s activities. Finally, any assumptions that may impact the analysis are defined. These may include environmental, legal, budgetary, or other variables that may have some degree of uncertainty. An example of an assumption could be “assuming no change in budget,” or “assuming an operating environment consistent with typical local weather.” Goals, objectives, assumptions, and constraints may be available from current documentation or may need to be developed. Documented Criticality Analysis Procedures (or project plan) from Process A Relevant Laws, Regulations, Directives (including organizational policies), and other high-level guiding documents that may have the right information Strategic Plan(s); any documentation that describes organizational mission/vision needs, goals, objectives, and projects Risk Management Strategy (including risk tolerance) Budgets and Project Plan(s) Documentation of goals, objectives, assumptions, and constraints Project Plan Document Review Brainstorming Process Flow Diagram Responsible/Accountable/Consulted/Informed (RACI) Charts [CSF] – (ID.BE-3, 4) Business Environment [CSF] – (ID.GV-1, 2, 3) Governance [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.1) Business or Mission Analysis Process [NIST SP 800-160] – (3.4.2) Stakeholder Needs and Requirements Definition Process [NIST SP 800-161] – (2.2.1) Frame Design, Document, or Obtain High-level Processes and Identify Interactions, Intersections, Connections, and Dependencies Between Processes This sub_process develops a map, diagram, or other representation of the activities or processes used to accomplish the goals and objectives defined in B.1. Loosely describe the main activities or processes that will be conducted to reach the goals and objectives defined in B.1. Include any activities that will be conducted in a regular course of events to measure the performance of the program, and activities that will be conducted in case of an adverse event (i.e., contingency plans). If possible, identify at a high level all activities regularly conducted by the organization(s) responsible for the completion of the program, including those responsible for performing the identified activities. This may include things such as inspections, maintenance, payroll processing, recruitment/training, or any other activity that may have an impact on the successful completion of the project. Consider identifying triggers that cause an activity to begin and end. Consider defining which activities directly relate to the success of the objective(s), mission(s) or goal(s), and which activities support, but do not directly impact those objective(s), mission(s) or goal(s). Consider identifying conditions or triggers which would cause an activity to be more or less vital or impactful, especially if including activities conducted as part of a contingency plan. Examine interactions between activities or processes and determine which processes rely on the outputs of other processes. Create a map, diagram, or other representation of the processes. Ensure that this representation describes connections between the activities or processes, including what processes must be completed before another can begin (e.g., a document created by one process is used in the completion of another). Consider identifying what information or types of information are used by a process or activity. Trace how that information is obtained and how it is used. Documentation of goals, objectives, assumptions, and constraints from B.1. Description of workflow paths, boundaries, and roles and responsibilities to pass to B.3. (This can be done in a document, spreadsheet, or draft process diagram.) Graphs with Results and Actions Inter-related (GRAI) Integrated Methodology (GIM) Project Plan Document Review Brainstorming Process Visualization RACI Charts Interviews Observation Sequence Diagrams Scenario/Use-Case [CSF] – (ID.AM-3, 6) Asset Management [NIST SP 800-34] [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.1) Business or Mission Analysis Process [NIST SP 800-160] – (3.4.2) Stakeholder Needs and Requirements Definition Process [NIST SP 800-161] – (2.2.1) Frame Define Detailed Workflow Paths, Boundaries, and Organizational Responsibilities This sub_process helps define workflow paths and identify connection points within the program that may be stressed in an adverse situation. Review the representation developed in B.2 and identify closely connected sets of activities to define a workflow. Workflows have an identifiable beginning and end. Consider including in the representation any outputs or products that will be created and transferred between activities. If the high-level program workflow path is complex or the activities within the workflow are complex, separate the workflow into different processes or workflow paths (also known as “mission threads”). Each workflow path has an identifiable beginning and end. The more detail that is put into this representation, the more specific and tailored the overall criticality analysis can be. However, very detailed diagrams are also less flexible to changes and can be time-consuming to create; it is important to define what level of detail is necessary for the criticality analysis. Once the activities are identified and represented in a workflow or set of workflow paths, boundaries of those activities are defined and described, and individuals or entities who will be performing those activities identified. Boundaries may be defined in terms of time, triggers, functionalities, systems, organizational units, or any system that makes sense to the user. The boundaries and responsible individuals are documented in sufficient detail to provide enough information to identify which points in the process may be critical to the organization as analyzed in sub_processes B.4 and B.5, and Process E. Examine the workflow paths and determine where they intersect and/or depend on each other. Highlight or otherwise clearly identify any activity or output that multiple workflows depend upon. Consider the boundaries defined in B.2 and identify situations where one activity is dependent on an output or activity located in a different boundary, is outside of the defined workflow path(s), or is outside the scope of the criticality analysis. Consider identifying the amount of control the organization has over certain dependencies (e.g., weather). Also, consider the individuals/responsibilities defined in B.2 and identify where multiple activities are conducted by a single individual or organizational unit. If appropriate, create or update the process diagram or other representation depicting the workflow paths to include interactions, intersections, connections, and dependencies. Description of workflow paths, boundaries, and roles and responsibilities from B.2. Process Description and/or Diagram listing of interactions, intersections, connections, and dependencies to pass to B.4. Document Review Process Flow Analysis GRAI-GIM Interdependency Analysis Activity Network Diagram Gantt Chart Scenario/Use Case Mission Thread Analysis Sensitivity/Uncertainty Analysis [CSF] – (ID.BE-4) Business Environment [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.1) Business or Mission Analysis Process [NIST SP 800-160] – (3.4.2) Stakeholder Needs and Requirements Definition Process [NIST SP 800-161] – (2.2.1) Frame Define Operating States This sub_process describes regular operation of the program and what might happen if the activities or workflow paths defined in B.2 are compromised. For each activity defined in B.2 and B.3, describe the condition of the activity (i.e., what the activity could look like) and the impact on the workflow if the activity is forced into different conditions, including but not limited to: • Non-operational (i.e., the activity does not occur); • Impaired (i.e., the activity operates at a reduced pace or in an unsafe/insecure/privacy-invasive manner); • Normal operation (i.e., how the activity operates under typical or ideal circumstances); • Increased operations (i.e., the activity performs quicker or with more output than normal); or • Unintended operations (i.e., the activity performs but with additional outputs or actions that are not part of the expected routine). Determine the severity of the operating states other than normal (adverse operating states) on the workflow. This could be a ranking (e.g., low, moderate, high) or measure (e.g., time lost; cost in time/resources). Consider defining what types of scenarios would lead to such situations. Examples of scenarios to consider include reduced performance (e.g., lower bandwidth), security breach, privacy problems, physical accident, or any other similar event (often described as an “adverse event” in security and privacy risk assessment models). Consider the time frame of an operating state– often long-term adverse operating states have greater impact than short-term states. Consider how long an adverse operating state must last before it becomes severe. Consider security, safety, and privacy ramifications. Examples of potential ramifications include (but are not limited to): determination of what information is made vulnerable if the activity is performed more slowly than expected, potential physical damages if an activity is performed too quickly, and privacy implications for personally identifiable information if unintended operations are performed. Also consider any contractual, statutory, or other obligations which may be impacted by the operating state. Then, using the Process Description and/or Diagram created in B.3, identify specific interactions, intersections, connections, and dependencies in the workflow paths that would be impacted by each adverse operating state. The purpose is to identify how the adverse operating states of the activity impact other activities in the process and in turn, which interactions or dependencies have the most influence on normal operation of the program and thus are more critical. Process Description and/or Diagram listing of interactions, intersections, connections, and dependencies from B3. Description of Operating States Document Review Brainstorming Interviews Group Decision Making [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.1) Business or Mission Analysis Process [NIST SP 800-160] – (3.4.2) Stakeholder Needs and Requirements Definition Process [NIST SP 800-161] – (2.2.1) Frame Assign Baseline Criticality Levels to Workflow Path(s) This sub_process determines criticality levels of workflow paths defined in B.3 against operating states defined in B5. Using the Process Description and/or Diagram created in B.2 and B.3, consider how the program would be affected by each of the operating states defined in B.4. Rank the activities, workflow paths, and/or bounded areas according to how vital they are to the success of the objectives/goals defined in B.1 and how strongly an adverse operating state will affect the program objectives and goals. The user creates a way to measure or rank the workflow paths according to how important they are to the success of the program. This could be a ranking (e.g., low, moderate, high), or measure (e.g., time lost; cost in time/resources; probability of being able to complete activity). The user could also use ranges and thresholds to define such rankings. Consider the life cycle of the activities and workflow paths in relation to the project. Considerations may include end dates of activities or workflow paths, and conditions that influence the criticality of activities. Process Description and/or Diagram from B.3 Listing of interactions, intersections, connections, and dependencies from B.3 Listing of operating states from B.4 Contingency Plan Baseline Criticality for each analyzed workflow path. Document Review Group Decision Making [FIPS 199] [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.1) Business or Mission Analysis Process [NIST SP 800-160] – (3.4.2) Stakeholder Needs and Requirements Definition Process [NIST SP 800-161] – (2.2.1) Frame Conduct System/Subsystem-Level Criticality Analysis This process reviews and analyzes the system or subsystem from the point of view of its criticality to the overall organizational goals. Documented Criticality Analysis Procedures (Process A) DFinal Criticality Levels of Activity(ies) and/or Workflow Path(s) of Program (Process B) DRisk Management Strategy DContingency Plan DFederal Information Processing Standard (FIPS) 199 Impact Level DHigh Value Asset (HVA) designations DExisting Infrastructure and Processes Baseline Criticality for Each Analyzed System/Subsystem Lead System Architect or a similar role is responsible for the performance of this sub_process. Lead Security Engineer serves as a co-lead for sub_processes C.4, Define Operating States, and C.5, Assign Baseline Criticality Levels to System(s)/Subsystem(s). Lead System Architect can delegate the execution of this process to another suitable individual, e.g., Business Analyst or systems analyst. Individuals who have detailed knowledge of the activities identified by this process contributes to the identification of critical activities. These individuals may include system architects and designers, system engineers, security or privacy engineers, and other security or privacy professionals, acquisition/procurement professionals, business leaders, legal experts/general counsel, third-party supplier representatives, and others, as appropriate. Invite representatives of each relevant group to participate in this process. Individuals responsible for conducting any part of the criticality analysis. [ISO/IEC/IEEE 15288] [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.1) Business or Mission Analysis Process [NIST SP 800-160] – (3.4.2) Stakeholder Needs and Requirements Definition Process [NIST SP 800-161] – (2.2.1) Frame Scope/Frame Analysis to Critical Workflow Path This sub_process involves identifying which critical process path will be examined further and is necessary for performing a criticality analysis for systems/subsystems. Ideally, it is performed once Baseline Criticality Levels of Activity(ies) and/or Workflow Path(s) have been determined. If criticality levels have not been determined, strongly consider returning to Process B, Conduct Program-Level Criticality Analysis. Use the documentation and Criticality Levels developed in Process B, along with any other relevant laws, policies, directives, etc., to identify which critical activities or workflows are to be further analyzed. If more than one workflow path or set of related activities are determined to be critical in Process B, analyze them separately in Process C unless they are very similar. If there are many activities in one workflow, identify similar types of activities or activities grouped by the boundaries defined in Process B. Ensure that the scope of process C is limited to a set of closely related activities. If Process B was not completed, if the organization wishes to focus on a certain type of system, or if the organization wishes to focus on a particular function, documents such as the Risk Management Strategy, Contingency Plans, FIPS 199 Impact Level, and High Value Asset (HVA) designations, it may be useful to help identify systems that may be further analyzed to scope the analysis. Ensure that the scope has definitive boundaries. Define any assumptions or constraints that will help limit the analysis. Criticality Levels of Activity(ies) and/or Workflow Path(s) from Process B. Risk Management Strategy Contingency Plan FIPS 199 Impact Level HVA designations Scope of analysis to pass to C.2. Document Review Context Diagram Decision Analysis [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-60] [NIST SP 800-160] – (3.4.1) Business or Mission Analysis Process [NIST SP 800-160] – (3.4.2) Stakeholder Needs and Requirements Definition Process [NIST SP 800-161] – (2.2.1) Frame Identify Functionalities and Capabilities Needed and What System(s)/Subsystem(s) Will be Used This sub_process defines those functionalities and capabilities that are critical for successful operation of the system/subsystem. Review the activities identified in C.1; list the functionalities and capabilities that are needed to support that activity. Consider what information or type of information is needed for the activity: how it will be processed and secured (covering the full data life cycle ). Consider how the activity or related activities are currently conducted and identify any capabilities or tools that are used. Specifically identify functionalities and capabilities that are required by law, regulation, or policy. Also, identify any functionalities that directly support any security, safety, privacy, or similar goals. Consider identifying the frequency of use of functions and capabilities and describing end-of-life conditions such as when the functions/capabilities are expected to no longer be needed, in respect to the workflow or project. Determine whether there is available existing infrastructure sufficient to support the functions and capabilities described in C.2. Identify any functions or capabilities that are not supported by existing infrastructure. Determine what (if any) functions or capabilities will be supported by new systems/subsystems. Consider selecting a range of systems/subsystems that meet the functions and capabilities needed for the program, and rank them according to systems/subsystems that best provide the functions and capabilities noted as necessary. Scope from C.1 Existing Infrastructure and Processes Existing Contractual Obligations List of functionalities and capabilities to pass to C.3. Document Analysis Brainstorming Requirements Definition Architecture Definition Data Modeling Data Flow Diagrams Survey/Questionnaire. [CSF] – (ID.AM-1, 2, 4) Asset Management [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.3) System Requirements Definition Process [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-161] – (2.2.1) Frame Identify Interactions, Intersections, Connections, and Dependencies Within the Critical Workflow Path This sub_process identifies the interactions, intersections, connections, and dependencies between functions and between systems/subsystems. Identify interactions, intersections, connections, and dependencies between functionalities and between system(s)/subsystem(s). Consider assigning initial values to each of the functionalities and capabilities to determine their relationship to a critical workflow path. Identify whether they directly perform tasks to complete an activity on a critical workflow path, perform tasks which support but do not directly complete an activity, or if they are useful to the activity but not vital. Consider under what conditions the functionality or capability would become more or less impactful or valuable. Identify any constraints within the existing infrastructure. Consider identifying the amount of control the organization has over certain dependencies and constraints (e.g., weather). Document this information in a matrix, system diagram, or other representation. Consider grouping or connecting similar or related functions. List of functionalities and capabilities from C.2 Existing Infrastructure and Processes List of interactions, intersections, connections, and dependencies to pass to C.4. Document Review Brainstorming Questionnaire Observation Sensitivity/Uncertainty Analysis [CSF] – (ID.AM-3) Asset Management [NIST SP 800-47] [NIST SP 800-160] – (3.4.3) System Requirements Definition Process [NIST SP 800-160] – (3.4.4) Architecture Definition Process Define Operating States This sub_process defines scenarios for how the system/subsystem would operate normally and what would constitute abnormal operations of the system/subsystem. Review the functions and capabilities defined in C.2. Describe the condition of the functions and capabilities (i.e., how will it operate). Determine the impact on both the system and the activity the system is intended to support (defined in C.2 and C.3) in each of the following conditions: • Non-operational; • Impaired (i.e., the function or capability operates at a reduced pace or in an unsafe/insecure/privacy-invasive manner); • Normal operation; • Increased operations (i.e., the function or capability performs quicker or with more output than normal); and • Unintended operations (i.e., the function or capability performs but with additional outputs or actions that are not part of the expected routine). Consider defining what types of scenarios would lead to such situations. Examples of scenarios to consider include reduced performance (e.g., lower bandwidth), security breach, privacy problems, physical accident, or any other similar event. Consider the security, safety, and privacy ramifications of these situations. Considerations could include, for example, determining what information would become vulnerable if the function/capability performs slower than normal, what unintended actions could create privacy problems for individuals, could there be physical damages or injury by a function performing too quickly, or how inaccurate or incomplete output caused by software or hardware defects could affect downstream activities. Also consider any contractual, statutory, or other obligations which may be impacted by the operating state. Process Description and/or Diagram listing of interactions, intersections, connections, and dependencies from C3. Description of operating states to pass to C.5. Document Review Brainstorming Interviews Group Decision Making Scenario/Use Case [NIST SP 800-39] – (3.1) Assessing Risk [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-161] – (2.2.2) Assess Assign Baseline Criticality Levels to System(s)/Subsystem(s) This sub_process determines criticality levels of system(s) and subsystems identified in C.3 against adverse states defined in C.4. Determine the severity of the operating states on the activity that the function/capability is intended to support. Consider: • which systems/subsystems perform vital functions and capabilities and would be most impacted by an adverse state, • the potential long- or short-term impact(s) of those adverse operating states, • the life cycle of the system related to the workflow (e.g. planned end of life or expected end of use for the project), and • whether the system is continuously in operation or only when certain conditions are met The user may rank systems and subsystems that are on the critical workflow path. This could be a ranking (e.g., low, moderate, high) or measure (e.g., time lost; cost in time/resources; probability of being able to complete activity). The user could also use ranges and thresholds to define such rankings. Listing of interactions, intersections, connections, and dependencies from C.3 Listing of adverse states from C.4. Baseline Criticality for each analyzed system/subsystem. Document Review Group Decision Making Root Cause Analysis Scenario/Use Case [FIPS 199] [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-55] [NIST SP 800-60] [NIST SP 800-160] – (3.4.1) Business or Mission Analysis Process [NIST SP 800-160] – (3.4.2) Stakeholder Needs and Requirements Definition Process [NIST SP 800-161] – (2.2.1) Frame Conduct Component/Subcomponent-Level Criticality Analysis This process reviews and analyzes a specific system to identify critical components and/or subcomponents. Criticality Levels of System(s)/Subsystem(s) Relevant Laws, Regulations, Directives, etc. Existing Documentation System Design Process Architecture Diagrams Function Diagram with Workflow Pathways Baseline Criticality Levels of Component(s)/Subcomponent(s) Lead System Engineer or a similar role is responsible for the performance of this sub_process. Lead Security Engineer serves as a co-lead for sub_processes D.4, Define Operating States, and D.5, Assign Baseline Criticality Levels to Components/Subcomponents. Lead System Engineer or a similar role can delegate the execution of this process to another suitable individual, e.g., system analyst. Individuals who have detailed knowledge of the activities identified by this process participates in this process to contribute to the identification critical activities. These individuals may include system architects and designers, system engineers, security or privacy engineers, other security or privacy professionals, acquisition/procurement professionals, business leaders, legal experts/general counsel, third-party supplier representatives, and others, as appropriate. Invite representatives of each relevant group to participate in this process. Individuals responsible for conducting any part of the criticality analysis. [ISO/IEC 12207] [ISO/IEC/IEEE 15288] [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-39] – (3.2) Assessing Risk [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.1) Frame [NIST SP 800-161] – (2.2.2) Assess Scope/Frame Analysis to a System/Subsystem This sub_process narrows the scope of the analysis to a specific system or subsystem. Ideally, it is performed once Baseline Criticality Levels of systems/subsystems have been determined. If criticality levels have not been determined, strongly consider returning to Process C, Conduct System/Subsystem-Level Criticality Analysis. In the case of COTS products, the process will likely be performed out of sequence. Using the documentation and criticality levels developed in Process C along with any other relevant laws, regulations, directives, etc., identify which critical system/subsystem are to be further analyzed. For this portion of the criticality analysis, the system/subsystem is an IT/OT product, device, or solution, although the Model will support the analysis of any well-defined system. Separate analyses are conducted for all critical systems identified in Process C, if possible. This is because the components composing systems are often varied even if the systems seem identical. Ensure that the scope has definitive boundaries. Define any assumptions or constraints, which will help limit the analysis. Components and subcomponents are sometimes guided by specific legal and regulatory requirements, such as sourcing requirements (where those can/cannot come from); take those into account. If the analysis is conducted by a third party, such as in the case of COTS, work with the COTS provider(s) to define what information is available which may serve to inform a Baseline Criticality determination, including system documentation, risk analyses performed, operating constraints, and assumptions. If a system does not exist, but is being designed or is under development, bear in mind that the system design may change frequently. It may be best to perform this analysis from a theoretical viewpoint and use the result to inform the design and development process. Then repeat the process as changes to the design occur and when the system development has been completed. Criticality Levels of Systems/Subsystems from Process C Relevant Laws, Regulations, Directives, and other documents that may contain requirements that describe anything to do with the components that are being used in this system Determination of the system/subsystem to focus analysis Document Review Survey Interviews [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.1) Frame Identify System Functions and Capabilities Workflow Needed and What Components/Subcomponents Will be Used This sub_process analyzes the system to identify the components and subcomponents required to ensure that the system functions as intended. Review the activities identified in D.1. For existing systems, list the functions and capabilities of the system being analyzed. For systems under development, list functions and capabilities needed. If the system is complex, consider scoping the analysis to only the functions and capabilities determined as critical. Consider configurations, settings, routines, performance parameters, etc. Define the processes or data actions that are activated or that the system uses to perform the identified functions and capabilities. Those processes can be extracted from existing system documentation, such as functional requirements, system diagrams, process flow diagrams, system concept of operations, or any other documentation that describes what the system does. Consider defining what information/data is needed to perform a function: how will that data be processed and how it will be secured. Finally, identify components and subcomponents that are or will be used to support required functionalities and capabilities. If possible, define all of the functions and capabilities of those components and subcomponents; identify which functions or capabilities are not needed or outside the requirements for this particular application. For example, configuration settings or functions that will not be used. Consider the frequency of use of subsystem functions and capabilities and describing end-of-life conditions, such as when the functions/capabilities are expected to no longer be needed, for the system to function. Determination of the system/subsystem from D.1 Existing documentation, system design process, architecture diagrams existing contractual obligations Listing of capabilities and pathways needed to pass to D.3. Document Review Process Analysis Systems Analysis Workflow Analysis Data Flow Diagrams Functional Decomposition Interface Analysis [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.1) Frame Identify Interactions, Intersections, Connections, and Dependencies Within the System(s)/Subsystem(s) This sub_process identifies interactions, intersections, connections, and dependencies between components/subcomponents and associated functionalities/capabilities. The way the system uses components and subcomponents to execute a specific function or capability is described as a workflow path. Defined workflow paths may be extremely detailed, including the individual processes used by subcomponents. Note that detailed workflow paths allow for a more accurate and complete criticality analysis, but may not be feasible in many instances. Identify all workflow paths required to execute each system function or, if the system is complex, each critical function. In many cases, a single component, or identical components, will be used to support multiple workflow paths. Document these components matched to workflow paths in a matrix, spreadsheet, database, function diagram, or a similar tool. Identify interactions, intersections, connections, and dependencies between the components. Identify any constraints within the existing infrastructure. Consider identifying the amount of control the organization has over certain dependencies and constraints (e.g., weather). Consider defining triggers or conditions which activate/deactivate the use of a component or which impact how a component is used. Listing of capabilities and pathways from D.2. Existing documentation, system design, lists of components, bill of materials, or other documentation that somehow describes components and subcomponents. Listing of components and subcomponents matched to workflow paths to pass to D.4 and D.5 Function Diagram with Workflow Paths Document Review Systems Analysis Brainstorming Sensitivity/Uncertainty Analysis [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.1) Frame Define Operating States This sub_process defines normal operational states, as well as the states in which the system will be operating abnormally. Review the outputs of D.3. Describe operation of the components and/or workflow paths. Then determine the impact of the various operating states of the component on the workflow path(s), and consequently on the system function/capability that path supports. Consider each of the following operating states: • Non-operational; • Impaired (i.e., the component/subcomponent operates at a reduced capability or in an unsafe/insecure/privacy-invasive manner); • Normal operation; • Increased operations (i.e., the function or capability performs quicker or with more output than normal); and • Unintended operations (i.e., the function or capability performs but with additional outputs or actions that are not part of the expected routine). Consider defining what types of scenarios would lead to such situations. Examples of scenarios to consider include reduced performance (e.g., lower bandwidth), security breach, physical accident, insertion of counterfeit part, or any other similar event. Using the Function Diagram with Workflow Paths, identify specific points within the workflow paths where the system will be particularly stressed as a result of any of these operating states. This would include any points that would exacerbate the situation. Define the severity of the impact of the operating states. This may be a ranking (e.g., low, moderate, high) or measure (e.g., processing speed; downtime; percentage of remaining functionality). Consider the security, safety, and privacy ramifications of these situations; for example, what information is made vulnerable if the components/subcomponents fail? Could the data processing create privacy problems for individuals? Also consider any contractual, statutory, or other obligations which may be impacted by the operating state. Consider the lifetime of the component/subcomponent and the duration of an adverse operating state. Often, the impact of an adverse operating state is more severe over a longer time frame. Listing of components and subcomponents matched to workflow paths from D.3 Function Diagram with Workflow Paths Description of operating states to pass to D.5. Document Review Systems Analysis Workflow Analysis Brainstorming Group Decision Making Scenario/Use Case [NIST SP 800-39] – (3.2) Assessing Risk [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.2) Assess Assign Baseline Criticality Levels to Components/Subcomponents This sub_process assigns criticality levels to components and subcomponents identified in D.3 based on the impact of the operating states defined in D.4. Rank the components and subcomponents in a way that gives the highest ranking to components and subcomponents that are on the critical workflow path, perform vital functions and capabilities, and would be most impacted by adverse operating states. The user can create a ranking schema that would, for example, rank those activities and workflow paths that are impacted by the highest number of scenarios as “High Criticality” and those that are impacted by the lowest number of scenarios as “Low Criticality.” The user could also use ranges and thresholds to define such rankings. Listing of components and subcomponents matched to workflow paths from D.3 Function Diagram with Workflow Paths Description of operating states from D.4. Baseline Criticality Levels of Component(s)/Subcomponent(s) Document Review Systems Analysis Process Flow Analysis Group Decision Making Root Cause Analysis Scenario/Use Case [FIPS 199] [NIST SP 800-39] – (3.1) Framing Risk [NIST SP 800-161] – (2.2.1) Frame Conduct Detailed Review of Criticality for Processes B, C, and D This is a bottom-up sub_process conducted after Baseline Criticality levels have been defined under Processes B, C and D. It is used to create final criticality levels for Systems/Subsystems and Components/Subcomponents. This process involves identifying interactions, intersections, connections, and dependencies across Processes B, C, and D. It considers any available risk information, including any existing mitigation strategies, to create a more precise criticality score. Baseline Criticality for B, C, and D Existing Documentation System Design Process Security Requirements Functional Requirements Root Cause Analysis Hazard Analysis Risk Assessment (esp. Threat Assessment; Vulnerability Assessment, Impact Analysis, Privacy Risk Assessment) Criticality Levels of Programs, Systems/Subsystems, and Component(s)/ Subcomponent(s) Lead System Architect or a similar role is responsible for the performance of this sub_process. Lead Security Engineer serves as a co-lead for this process. Lead System Engineer should work in partnership with Lead Security or Privacy Engineer and Program Manager to ensure appropriate communication and collaboration across Processes B, C, and D. Individuals who have detailed knowledge of the activities identified by this process should participate in this process to contribute to the identification of critical activities. These individuals may include system architects and designers, system engineers, security or privacy engineers, other security or privacy professionals, acquisition/procurement professionals, business leaders, and others, as appropriate. Identify representatives of each relevant group to participate in this process. Individuals responsible for conducting any part of the criticality analysis. [FIPS 199] [NIST SP 800-39] – (3.2) Assessing Risk [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.2) Assess (Risk Assessment, Threat Assessment; Vulnerability Assessment, Impact Analysis) Identify and Map Interactions, Intersections, Connections, and Dependencies Across Components/ Subcomponents, Systems/Subsystems, and Programs This sub_process uses the process diagrams, design documents, or other artifacts created in processes B, C, and D, to trace subcomponents through to program goals and objectives. One system component or type of system component may be used in multiple subsystems. Identify these by reviewing the system design documentation that was created in Process D for each system or subsystem that was identified in Process C. Similarly, one system may support multiple programs. Identify these by reviewing the systems identified in Process C for each workflow described in Process B. Identify identical or similar types of components used for critical functions of multiple systems. Also, identify components or subsystems that originate from a single supplier. Look for any other connection or dependency that may impact the success of the objective or goals if stretched by maintenance, supply chain, security, or other concerns. Baseline Criticality Levels of Program, System(s)/Subsystem(s), and Component(s)/ Subcomponent(s) Existing Documentation and System Design Process Identification and maps of interactions, intersections, connections, and dependencies across Program, System/Subsystem, and Component/Subcomponent to pass to E.2. Document Review Mission Thread Analysis Impact Analysis Hazard Analysis [CSF] – (ID.AM-3) Asset Management [FIPS 199] [NIST SP 800-39] – (3.2) Assess Risk [NIST SP 800-47] [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.2) Assess (Risk Assessment, Threat Assessment; Vulnerability Assessment, Impact Analysis) Identify controls protecting the system to be used. This sub_process is used to identify components, system functions, processes, or other measures that are used to ensure that the system operates within acceptable parameters. Beginning at the subcomponent level, identify all controls that ensure that the program, systems, and components operate within acceptable parameters. Identify system components that monitor or protect critical subcomponents. Then review critical components and identify any system functions that provide those same assurances. Next, identify external systems, programmatic activities, processes, procedures, and practices that serve to monitor or protect the system. Identify any programmatic activities that serve to monitor or protect the program itself. Using the interactions, intersections, connections, and dependencies identified in E.1, Identify and Map Interactions, Intersections, Connections, and Dependencies across Program, System/Subsystem, and Component/Subcomponent, identify controls that monitor and protect those interactions, intersections, connections, and dependencies. Identification and maps of interactions, intersections, connections, and dependencies across Program, System/Subsystem, and Component/Subcomponent from E.1 Security Requirements; Functional Requirements Listing of controls protecting the system to be used to pass to E.3. Document Review Security and Privacy Control Selection and Allocation (Risk Management) [CSF] – (ID.GV) Governance [CSF] – (ID.RA-6) Risk Assessment [CSF] – (ID.RM) Risk Management Strategy [FIPS 199] [ISO/IEC 22301] [ISO/IEC 27001] [NIST SP 800-34] [NIST SP 800-39] – (3.2) Assess Risk [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.2) Assess (Risk Assessment, Threat Assessment; Vulnerability Assessment, Impact Analysis) Review Impact of Operating States Beginning at the subcomponent level, trace the impact of each adverse operating state at the system level (defined in C.4) would have on the operations of the activity or workflow path it is meant to support (defined in B), and what each adverse operating state at the activity level would have on the success of the program (defined in B.4). Using the controls identified in E.2, review the likelihood of the adverse operating states and associated impact(s) occurring. For example, if there are no controls monitoring and protecting a vital component, this may need to be reflected in the criticality level of the component. Consider frequency of use of components/systems and describing end-of-life conditions such as when the components/systems are expected to no longer be needed or critical to the project. Listing of controls protecting the system to be used from E.2 Descriptions of operating states from B.4, C.4, and D.4 Results of Root Cause Analysis Results of Hazard Analysis Contingency Plans Refined list of operating states to pass to E.4. Document Analysis Scenario/Use Case Hazard Analysis [CSF] – (ID.RA-4) Risk Assessment [FIPS 199] [NISTIR 8062] [NIST SP 800-39] – (3.2) Assess Risk [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.2) Assess (Risk Assessment, Threat Assessment; Vulnerability Assessment, Impact Analysis) Validate, Apply and Trace any Available Risk Information Through Interactions, Intersections, Connections, and Dependencies If available, apply any threat, vulnerability, problematic data action, or other risk information to the interactions, intersections, connections, and dependencies mapping. Include supply chain, cybersecurity, privacy, and any other applicable risks. Apply any updated criticality information from processes B, C, and D, and increase or decrease the criticality level of the system or component as appropriate. Refined list of adverse operating states from E.3; Risk Assessment (esp. Threat Assessment; Vulnerability Assessment, Impact Analysis). Detailed review results to pass to E.5, Assign Final Criticality Levels to Systems, Subsystems, Components, and Subcomponents. Document Review Risk Analysis; Brainstorming [CSF] – (ID.RA) Risk Assessment [FIPS 199] [NIST SP 800-39] – (3.2) Assess Risk [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.2) Assess (Risk Assessment, Threat Assessment; Vulnerability Assessment, Impact Analysis) Assign Final Criticality Levels to Systems, Subsystems, Components, and Subcomponents This sub_process finalizes Baseline Criticality levels determined in processes C and D. The critical nature of components and systems may be influenced by the interactions, intersections, connections, and dependencies, connections, controls, frequency of use, and impacts identified in Process E. Review the Baseline Criticality levels defined in C.5 and D.5. Considering the outputs of Process E, refine the rankings. Consider ranking: • Components and subcomponents by their importance in keeping the system from entering adverse operating states or keeping the system operational while in adverse operating states; and • Systems and subsystems by their importance in keeping the program from entering adverse operating states or keeping the program running while in adverse operating states. Avoid reducing the criticality scores of systems and components without carefully considering legal, regulatory, safety, security, privacy, business, and other constraints and managerial decisions. A concatenated score may be used (e.g. using a scale 1 to 5, a combined score of 1.3.2 may show that a component has a “2” rating in a “3” system in a “1” project). Note that when components support multiple systems, it can be useful to track the criticality of that component to each project in addition to its finalized criticality level. A scoring system may be defined that uses the information from Process E to refine but not alter the Baseline Criticality levels. For example, Baseline Criticality levels could be given a digit identifier from 1 to 5 while results of the review conducted in Process E could add a digit 0 to 9 to that identifier, to make the final identifier a two-digit ranking from 10 to 59. Whatever method is used to score the criticality levels, ensure that the method is sufficiently detailed so that a reasonably small number of components are given a high criticality score. The process described in this publication usually will not result in a large number of components being given a high criticality score. If this occurs, it may be assumed that many of these components are either outside the scope or control of the program or do not have highest criticality. In general, a component is not given a higher criticality level than the highest criticality of the systems it supports. Neither would a system have a higher criticality level than the highest criticality of the processes/workflow paths it supports. Determine the duration for the final criticality level to be valid. Consider the life cycle of the components, systems, and projects under evaluation. As part of the risk management process related to the system/components, define means to monitor changes to the system and component criticality levels over the life cycle of the project and over the life cycle of those components and systems. Detailed Review Results from sub_process E, Conduct Detailed Review of Risk and Criticality Analysis. Finalized criticality for each analyzed component/subcomponent, system/subsystem, etc. Document Review Brainstorming Group Decision Making [CSF] – (ID.AM-5) Asset Management [FIPS 199] [NIST SP 800-39] – (3.2) Assess Risk [NIST SP 800-160] – (3.4.1) Business or Mission Analysis Process [NIST SP 800-160] – (3.4.2) Stakeholder Needs and Requirements Definition Process [NIST SP 800-160] – (3.4.4) Architecture Definition Process [NIST SP 800-160] – (3.4.5) Design Definition Process [NIST SP 800-161] – (2.2.2) Assess