Chapter 1 — Computing systems
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes and connection"]
N1["1.1 Why a responder starts with the system, not the"]
N2["1.2 Components of a service"]
N3["1.3 Failure domains and change ownership"]
N4["1.5 Practice activity"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["1.1 Why a responder starts with the system, not the"]
N2["1.2 Components of a service"]
N3["1.3 Failure domains and change ownership"]
N4["1.5 Practice activity"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]
[Learning outcomes and connection]
|
v
[1.1 Why a responder starts with the system, not the]
|
v
[1.2 Components of a service]
|
v
[1.3 Failure domains and change ownership]
|
v
[1.5 Practice activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes and connection
You will be able to (1) describe a business service as a set of compute, storage, network and identity components with named owners; (2) identify failure domains that would delay detection, response or recovery; and (3) record the component facts an incident responder needs before the first incident arrives. This is the opening chapter of a three-year technologist course: you will build and run a working incident response service for one fictional organization, Fernmoor City Services (synthetic), a municipal provider of appointments, permits and water billing for about 180,000 residents. Every later chapter uses the component map you begin here.
1.1 Why a responder starts with the system, not the attack
An incident is handled on real machines. A responder who does not know where an application runs, where its data lives, who may change it and what it depends on will lose the first hours of any case asking those questions. NIST SP 800-61 Rev. 3 places incident response inside cybersecurity risk management under the CSF 2.0 functions; its preparation activities assume the organization already knows its assets and their criticality. The technologist's job is to make that assumption true. At Fernmoor, the appointment-service map showed this in practice: nobody knew who could approve blocking the load balancer at 02:00.
1.2 Components of a service
A service is what a customer experiences ("book an appointment"). It is delivered by components: compute (virtual machines, containers, serverless functions), storage (databases, file shares, object stores, backups), network paths (load balancers, firewalls, DNS), identity (directory, single sign-on, service accounts) and external suppliers. For each component record: name, role, environment (production, test), location, owner team, change authority, data held, logs produced, and how it is restored. Fernmoor's appointment service shows why the restore column matters: the map listed nightly backups for appt-db-1, but nobody had timed a restore, so the team could not say how long the service would be down. The same gap in the owner column left the load balancer without anyone who could approve a block at night.
1.3 Failure domains and change ownership
A failure domain is the set of components that fail together because they share something: a host, a power feed, a cloud region, an administrator credential, a deployment pipeline. Response planning cares about two kinds: domains that an attacker can cross with one foothold (shared admin accounts), and domains that a containment action would take down together (isolating a hypervisor stops every guest). Change ownership says who may alter a component. During an incident you need that person reachable, or a pre-agreed emergency authority.
1.4 Worked example (synthetic): the appointment service
Fictional. Fernmoor's appointment service runs on three application hosts (appt-app-1..3) behind one load balancer, with one PostgreSQL primary (appt-db-1) and a read replica, nightly backups to an object store, and sign-in through the city's identity provider. All three application hosts are patched by one automation account, svc-patch, and log only to local disk with seven-day rotation.
Map findings: (a) svc-patch is a failure domain — a stolen credential reaches every host; (b) local-only logs mean evidence disappears after seven days and may be altered by an intruder on the host; (c) the database has an owner (Data Platform team) but the load balancer has none listed — nobody can approve blocking traffic at 02:00; (d) the restore of appt-db-1 has never been timed.
Response-relevant actions, each with an owner: forward application logs to central collection (Platform, 30 days); split svc-patch into per-environment accounts with restricted scope (Identity); name a load-balancer owner and an out-of-hours deputy (Network); schedule a timed restore test (Data Platform, see Chapter 18).
1.5 Practice activity
Pick one service you can legitimately describe (a home lab or the synthetic service above). Produce a one-page component table and mark each component's failure domain and restore method. A good table makes the risky entries visible at a glance. In the appointment service, one automation account patches all three application hosts, so a single stolen credential reaches every host; your table should show the same kind of shared dependency if it exists. Note the restore method as tested or untested, because an untested restore is a plan, not a capability. Ask the owner of each component to check your entries before you call the table finished.
1.6 Common errors and limits
- Mapping servers but not identities and pipelines, which are the most common shared failure domains.
- Listing a team as owner without a reachable person or rota.
- Treating the map as finished; it decays with every change unless tied to change management (Chapter 21).
- Recording "backed up" without a tested restore time.
Each of these errors appeared in Fernmoor's first map. svc-patch was missing as a component, the load balancer had no named owner, and the database restore was recorded without a time. Correcting them took a few days of conversation with owners, far less than discovering them during a case at night.
Exercises — chapter 1
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.
EX001 — Component table. Inputs: the appointment-service worked example in Chapter 1. Steps: write a table with component, role, owner, logs, restore method for the appointment service. Rubric: 3 = all eight components (three app hosts, LB, primary, replica, backup store, IdP) with gaps marked; 2 = most components; 1 = hosts only; 0 = none.
EX002 — Failure domains. Steps: name three failure domains in the appointment service and say whether each matters for intrusion spread, containment impact or recovery. Rubric: 3 = three domains each correctly classified with reason; 2 = two; 1 = one or unclassified; 0 = none.
EX003 — Owner gap. Steps: write the request you would send to obtain a load-balancer owner and deputy. Rubric: 3 = states why (incident authority at any hour), what is needed (named owner, deputy, contact route, emergency change authority) and a deadline; 2 = missing authority or deadline; 1 = vague; 0 = none.
Chapter synthesis
A response service protects systems it understands. Map each service as components with owners, logs and restore methods; mark shared failure domains; and treat every unknown owner or untested restore as a preparation task with an owner of its own.
Continue studying — chapter 01 of 30
← Course home · Course chapter index · Chapter 02 →
Continue to the next authored lesson.