Chapter 11 — Asset inventory and business-service dependencies

Chapter 11 — Asset inventory and business-service dependencies

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["11.1 Inventory as response data"]
  N2["11.2 Sources and reconciliation"]
  N3["11.3 Dependencies and criticality"]
  N4["11.5 Keeping it current"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["11.1 Inventory as response data"]
  N2["11.2 Sources and reconciliation"]
  N3["11.3 Dependencies and criticality"]
  N4["11.5 Keeping it current"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX031"]

[Learning outcomes and connection]
    |
    v
[11.1 Inventory as response data]
    |
    v
[11.2 Sources and reconciliation]
    |
    v
[11.3 Dependencies and criticality]
    |
    v
[11.5 Keeping it current]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes and connection

You will be able to (1) build an inventory that links technical assets to business services and owners; (2) model dependencies so that response and recovery can be prioritized; and (3) keep the inventory current through automated discovery and change records. Chapter 1 mapped one service; this chapter scales that map across Fernmoor and makes it a living data source for the case system.

11.1 Inventory as response data

CSF 2.0 places asset management under Identify. For response, the inventory must answer within minutes: what is this host or account, which service does it support, who owns it, how critical is it, where are its logs, and how is it restored? An inventory that answers only "what hardware do we own" is not enough. During the storage failure, the inventory's tiers and dependencies decided the restore order: idp-proxy first because everything depended on it, then billing-db as tier 1, then the tier-2 systems in parallel.

11.2 Sources and reconciliation

Combine sources: cloud and hypervisor APIs, endpoint agent lists, identity directory, network scans of authorized ranges, the configuration management database (CMDB), and owners' attestations. Each source misses something. Reconcile by stable identifiers and flag disagreements: a host in the agent list but not the CMDB has no owner; a CMDB entry with no agent check-in may be dead or unmonitored. Fernmoor's stale CMDB entry, which named a person who had left, was the kind of disagreement that reconciliation is meant to catch.

11.3 Dependencies and criticality

A business service depends on technical services (database, identity, DNS) and suppliers. Model dependencies as edges: appointments → appt-db-1, appointments → idp, water-billing → payment-supplier-sftp. Criticality comes from the service's impact if unavailable or disclosed, set with the service owner (for example tiers 1–3 with recovery time objectives, following NIST SP 800-34 contingency-planning concepts). Shared dependencies such as identity and DNS inherit the highest criticality of anything depending on them. In the storage failure, idp-proxy was tier 1 by inheritance because every staff application depended on it, which is why it was restored first. The wiki, rated tier 3, still held the runbooks, which showed that criticality for response can differ from criticality for the business. The team recorded that finding instead of quietly raising the wiki's tier.

11.4 Worked example (synthetic): which restore first?

Fictional. After a storage failure caused by a malicious deletion, five Fernmoor systems are down: idp-proxy, appt-db-1, permit-app-1, billing-db, intranet-wiki. Inventory data:

Order: idp-proxy first (everything depends on it), then billing-db, then appt-db-1 and permit-app-1 in parallel. The wiki is tier 3, but it holds the runbooks; the team used the offline runbook copy, and recorded a finding: critical response documents must not depend on the systems they help restore.

11.5 Keeping it current

Automate discovery runs daily; create a work item for every unreconciled asset; require an inventory update as part of every change (Chapter 21); review tier assignments with owners yearly. Each step closes a gap seen at Fernmoor. Daily discovery catches hosts that appear between changes; work items make unreconciled assets someone's task; tying updates to change records keeps owners current, which would have prevented the stale CMDB entry paging a former employee; and yearly review with owners keeps tiers aligned with the services the business actually depends on.

11.6 Common errors and limits

• Inventory without owners or services.
• Forgetting identities, certificates and suppliers as assets.
• Criticality set by IT alone without business owners.
• Response documentation hosted only on systems that may be down.

The restore-order case touched two of these. The runbooks lived on the tier-3 wiki, which was down with the other systems, and the team managed only because an offline copy existed. Identity components such as idp-proxy had to be in the inventory with their dependants, or nobody would have known to restore them first. Fernmoor now keeps an offline copy of the inventory with the runbooks.

Exercises — chapter 11

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX031 — Reconcile. Steps: given four discrepancies (agent-only host, CMDB-only host, cloud VM with no tag, scan-found host in no source), say what each likely means and the action. Rubric: 3 = all four plausible with actions; 2 = three; 1 = one; 0 = none.

EX032 — Dependency graph. Steps: draw the dependency edges for the five systems in the restore-order worked example plus DNS. Rubric: 3 = all edges including DNS for all, correct direction, inherited tier noted; 2 = missing DNS; 1 = partial; 0 = none.

EX033 — Inventory query. Steps: list the six inventory fields a duty analyst needs when an alert names a hostname. Rubric: 3 = service, owner/on-call, tier, environment, log locations, restore method; 2 = four; 1 = two; 0 = none.

Chapter synthesis

Make the inventory a response tool: link assets to services, owners, tiers, logs and restore methods; reconcile sources continuously; model dependencies so shared services inherit criticality; and never let response documents depend on what they restore.

Continue studying — chapter 11 of 30

← Chapter 10 · Course chapter index · Chapter 12 →

Continue to the next authored lesson.