Articles

Service criticality and dependencies: what fails when this stops

Criticality is a property of the service, not the box: name what it depends on.

Reading: 5 minCybersecurity Governance

Article cover: Service criticality and dependencies: what fails when this stops

A service is critical when the mission behind it cannot continue without it, so criticality is a relationship, not a property a component owns. NIST’s categorisation guidance calls it “a measure of the degree to which an organization depends on the information or information system for the success of a mission or of a business function” (SP 800-60 Rev. 1 Vol. I, line 1879). SP 800-53 Rev. 5 turns that into a control: RA-9, criticality analysis, requires critical components and functions to be identified by a functional decomposition.

Criticality is measured against a mission, not a component

RA-9 states the test plainly: “Component and function criticality are assessed in terms of the impact of a component or function failure on the organizational missions that are supported by the system that contains the components and functions” (line 16362). Nothing is critical on its own: the same database is critical in one service and routine in another, because what changes is what the mission loses. Equally, more is not better — “Not all system components, functions, or services necessarily require significant protections” (line 16346).

The decomposition: mission, functions, components

The method is a one-directional descent from the mission:

organisational mission
        |  supported by
   service / system
        |  decomposed into
function  ->  function  ->  function
        |  traceable to
hardware, software and firmware components
   (shared by many components within and external to the system)
        |  and, for each critical asset,
procedures  .  personnel            operational aspects (CP-2(8))

Read downwards it is a design; read upwards it is a failure path. RA-9 asks for the “identification of organizational missions supported by the system”, their decomposition into functions, and “traceability to the hardware, software, and firmware components that implement those functions” (lines 16352–16355). Shared is the load-bearing word: a function used by several services is one failure with several consequences (interpretation).

What criticality covers: technical and operational aspects

CP-2(8), IDENTIFY CRITICAL ASSETS, keeps the list wide: technical aspects are “system components, information technology services, information technology products, and mechanisms”; operational aspects are “procedures (i.e., manually executed operations) and personnel” (lines 8468–8472). A service also fails when the person performing a manual step is unavailable, or a procedure is applied wrongly — dependencies no component diagram shows. They are named so that “additional controls can be employed (beyond the controls routinely implemented)” (lines 8463–8465).

What sits outside the boundary

RA-9 counts the environment: criticality can be affected by “the connections to and dependencies on cyber-physical systems, devices, system-of-systems, and outsourced IT services” (lines 16358–16360). It also supplies a rule for any dependency diagram — components that “allow unmediated access to critical system components or functions are considered critical due to the inherent vulnerabilities that such components create” (lines 16360–16362). CP-2(8) points outward too, to CP-2(7), where critical assets are “resident within or supported by external service providers” (lines 8473–8474).

A shared component carries aggregate criticality

When one component serves several services, its criticality is not the criticality it has in any single one of them. SP 800-137 makes the point for common controls: inherited by many systems, their “aggregate criticality … may require more frequent assessments than would similar controls responsible for protecting a single system” (lines 1645–1647). SP 800-39 adds the consequence of leaving a single point of failure in place: it “can result in severe or catastrophic effects” (lines 1432–1438).

The business impact analysis carries it into practice

The recurring exercise that records criticality is the business impact analysis. In SP 800-34 Rev. 1 it is the second step of contingency planning and “helps identify and prioritize information systems and components critical to supporting the organization’s mission/business processes” (lines 415–417). NISTIR 8286r1 gives that analysis a place in enterprise risk management, where the BIA register records “the criticality and sensitivity of enterprise assets” (lines 1192–1193). How much downtime is tolerable, and the recovery plan built on it, is continuity work at L3.

When it is done, and what it changes

Timing is part of the control. RA-9 is performed “when an architecture or design is being developed, modified, or upgraded”, and done early it lets the organisation reduce the critical nature of a component “such as by adding redundancy or alternate paths into the system design” (lines 16366–16369); done late, it can only shape the protection measures required of development contractors (line 16370). CSF 2.0 keeps the output in view: assets are “prioritized based on classification, criticality, resources, and impact on the mission” (ID.AM-05, lines 877–878). And a decomposition assembled from documentation records intended dependencies only: SP 800-53 CP-2(5) notes that disruptions simulated in testing “can reveal unexpected functional dependencies” (lines 8643–8645).

What to remember

  • Criticality is a relationship to a mission, not a property of a component.
  • RA-9 outputs a functional decomposition: mission, functions, then the components that implement them, shared and external components included.
  • Procedures and personnel are critical assets too.
  • Dependencies cross the boundary; unmediated access to a critical function makes a component critical.
  • A shared component carries aggregate criticality, so the analysis is cheapest before the design is frozen.

Level and prerequisites

L2 — operational: run a criticality analysis for one service, name its dependencies, and state what each failure would take with it. Prerequisites are the L1 sheets on assets, processes, data and dependencies, and on threat, vulnerability, likelihood and impact. Inventory records, supplier requirements, classification and registers are sibling sheets; RTO/RPO is L3.

Where to go next

References