Chapter 11 — Critical infrastructure and sector security: assets and context

Chapter 11 — Critical infrastructure and sector security: assets and context

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["11.1 What to record and why"]
  N2["11.2 Sources and their blind spots"]
  N3["11.3 Safe discovery in operational networks"]
  N4["11.4 Reconciliation"]
  N5["11.5 Unsupported assets"]
  N6["11.7 Practical activity: three-source reconciliation"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["11.1 What to record and why"]
  N2["11.2 Sources and their blind spots"]
  N3["11.3 Safe discovery in operational networks"]
  N4["11.4 Reconciliation"]
  N5["11.5 Unsupported assets"]
  N6["11.7 Practical activity: three-source reconciliation"]
  N7["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]

[Learning outcomes and connection]
    |
    v
[11.1 What to record and why]
    |
    v
[11.2 Sources and their blind spots]
    |
    v
[11.3 Safe discovery in operational networks]
    |
    v
[11.4 Reconciliation]
    |
    v
[11.5 Unsupported assets]
    |
    v
[11.7 Practical activity: three-source reconciliation]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes and connection

After this chapter you should be able to:

• build and maintain an asset inventory for a mixed IT/OT service from several sources;
• record for each asset its owner, function, criticality, location, software or firmware version, support status and dependencies;
• use passive discovery methods that are safe for operational networks;
• reconcile disagreeing sources and treat disagreement as a finding.

Chapter 4 showed how to model an inventory. This chapter is about filling it truthfully. CISA's Cross-Sector Performance Goals include maintaining an asset inventory, including OT assets (CISA CPGs); you cannot protect, patch or monitor what you have not recorded.

11.1 What to record and why

11.2 Sources and their blind spots

No single source is complete. Purchase and contract records know what was bought but not where it went. Configuration-management or engineering records know the design but may lag reality. Network observation (switch tables, flow records, a passive sensor) sees what talks but not what is silent. Site surveys see what is physically present but are expensive and infrequent. Vendor portals know firmware versions for what they support. Combine at least two sources and record which source said what.

PS-09 shows why: only flow records knew the station had gone silent.

11.3 Safe discovery in operational networks

Active scanning — sending probes to every address — is routine in office networks and risky in control networks: some older controllers and embedded devices can misbehave or reset when probed unexpectedly. NIST's OT guide advises caution with active scanning in OT environments and favours passive methods or carefully planned, coordinated active work (NIST SP 800-82 Rev. 3). For an implementer the rule is: in the station zone, use passive sources (flow records, switch tables, the controllers' own configuration exports done by their engineers) unless an active method has been agreed with operations, tested on a spare, and scheduled.

11.4 Reconciliation

When sources disagree, the disagreement is information. An asset in purchase records but never seen on the network may be in a cupboard — or connected somewhere unexpected. An address seen in flows but absent from every record is an unknown device. A firmware version that differs between the engineering record and the vendor portal means one of them is wrong — and if it is the engineering record, a fix may have been applied, or not, without documentation. Track each discrepancy as a ticket with an owner until it is resolved.

11.5 Unsupported assets

Critical services often run equipment past vendor support, because replacement needs capital, outages and re-certification. The inventory must make this visible, with a compensating-control plan for each unsupported asset: tighter segmentation, stricter allowlists, extra monitoring, spare parts, and a replacement date owned by someone with budget.

PS-09's Kell R2 RTU, unsupported since 2025-12-31 and still criticality 1, is the Fallowmere case. Its plan would name the relay allowlist entry and the conduit as the tightened controls, Rule C as the extra monitoring, a spare RTU held by Water, and a replacement date owned by Water operations, which holds the capital budget.

11.6 Worked example: reconciling PS-09 (synthetic)

Three sources describe pumping station PS-09. The purchase record lists a Kell R2 RTU bought in 2017. The engineering record lists firmware 1.1 and owner "Water Ops". Flow records show 10.20.0.13 talking to the relay until three weeks ago, and nothing since (Chapter 2's silent station). The inventory (Chapter 4) has no owner for PS09-RTU and records vendor support ended 2025-12-31. You record four discrepancies: owner missing in the inventory but present in the engineering record (fix the record, after confirming with Water Ops); support ended (needs a compensating-control plan); station silent (operational issue, raised with Water operations the same day); and firmware not independently verified (ask Water's engineer to export the RTU configuration at the next site visit — Chapter 28).

11.7 Practical activity: three-source reconciliation

Using the Lab 4 inventory and the Lab 2 flows, list every asset or address that appears in one source but not the other, and every attribute that differs. For each, write the next action and owner. Do not probe any device to resolve a discrepancy; ask the owner.

Expect PS-09's RTU at 10.20.0.13 to appear in both sources but disagree: present in the inventory, silent in the flows.

Also expect the Lab 2 flows to show addresses the inventory lacks, such as the corporate workstation 10.40.3.7; record its owner as a question for Water engineering, not as a guess.

11.8 Common errors and limits

• Treating one source as the inventory.
• Running active scans in control networks "just to be sure".
• Recording a person as owner instead of a role.
• Recording firmware once and never re-verifying it.
• Listing unsupported assets without compensating controls or a replacement owner.
• Hiding discrepancies to make the inventory look complete.

An inventory is a model of reality, always slightly out of date. Its quality is measured by how recently each record was verified and how quickly discrepancies are closed.

PS-07's cellular modem, found only by a site visit, is the case against trusting one source.

Exercises — chapter 11

EX031 — Reconcile. Objective: find discrepancies across sources. Inputs: Lab 4 inventory and Lab 2 flows. Constraints: station, relay and corporate zones only. Steps: (1) list addresses in flows with no inventory record (assume the inventory maps PS04-PLC to 10.20.0.11, PS07-PLC to 10.20.0.12, PS09-RTU to 10.20.0.13, RLY-01 to 10.30.0.5 and HIST-01 to 10.40.8.20); (2) list inventory assets in those zones never seen in flows; (3) give an action and owner for each. Expected evidence: table. Rubric: 3 = 10.40.3.7 (corporate workstation, not in the extract) identified as unrecorded and as the source of the undeclared Modbus; SW-STN-04 not seen (expected for a switch — explain); PS09-RTU silent; actions owned; 2 = partial; 1 = list only; 0 = none.

EX032 — Compensating controls. Objective: plan for an unsupported asset. Inputs: PS09-RTU, criticality 1, vendor support ended, replacement budget available in 14 months. Constraints: controls FSTS and Water can implement without vendor fixes. Steps: list four compensating controls with evidence for each, and the replacement owner. Expected evidence: table. Rubric: 3 = conduit restricted to relay only and verified, relay-side validation and range quarantine, station-silence and implausible-value alerts, spare unit or tested manual procedure, configuration backup; replacement owned by a Water role with date; 2 = three; 1 = "monitor it"; 0 = none.

EX033 — Discovery plan. Objective: plan safe discovery. Inputs: Water operations wants a complete list of devices at all 14 stations within three months. Constraints: no active scanning without agreement; at most two site visits per week. Steps: (1) list passive sources to use first; (2) say when an active method would be justified and how you would make it safe; (3) give a schedule. Expected evidence: one-page plan. Rubric: 3 = passive sources (flows, switch tables, engineering exports, purchase records) first; active method only with operations agreement, tested on a spare, rate-limited, in a window, with someone on site; realistic schedule; 2 = plan sound but vague on safety; 1 = "scan the subnet"; 0 = none.

Chapter synthesis

An inventory records, for every asset, what it is, where it is, who owns it, what it runs, whether it is supported, what it depends on and when that was last verified. Build it from several sources, discover safely in control networks, treat disagreement between sources as findings, and give every unsupported asset compensating controls and a replacement owner.

Continue studying — chapter 11 of 30

← Chapter 10 · Course chapter index · Chapter 12 →

Continue to the next authored lesson.