Chapter 1 — Computing systems
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 Layers an assessor must name"]
N2["1.2 Why capacity and fragility matter"]
N3["1.3 Shared and virtual infrastructure"]
N4["1.4 The asset record"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 Layers an assessor must name"]
N2["1.2 Why capacity and fragility matter"]
N3["1.3 Shared and virtual infrastructure"]
N4["1.4 The asset record"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 Layers an assessor must name]
|
v
[1.2 Why capacity and fragility matter]
|
v
[1.3 Shared and virtual infrastructure]
|
v
[1.4 The asset record]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) describe the hardware, firmware, operating system and application layers of a computer in terms an assessor needs; (2) explain why fragile or shared systems change how a test is planned; (3) write an asset record that a scoping meeting can use; (4) recognise when a system belongs to someone who has not authorized testing.
1.1 Layers an assessor must name
A computing system is a stack. At the bottom sit processor, memory, storage and network interface. Firmware such as UEFI or a baseboard management controller starts the machine and often keeps running beside it. The operating system schedules processes, enforces file permissions and exposes services. Applications sit on top and hold the data the business cares about. When a test report says "the host", a reader cannot tell which layer was examined; a technologist names the layer, because the owner, the patch route and the risk are different for each.
1.2 Why capacity and fragility matter
Assessment traffic consumes resources. A service that answers fifty requests a minute in normal use may degrade when an inventory tool sends thousands. NIST SP 800-115 warns that testing can disrupt operations and asks planners to weigh that risk before choosing techniques. Old embedded controllers, single-threaded legacy daemons and storage arrays near their limits are the usual casualties. The answer is not to skip them silently but to record the constraint and agree a gentler method, such as configuration review, with the owner.
Priya's first ENG-712 diagram separates passenger internet paths from staff VPN paths before any prefix list is built. Trust assumptions differ on each path, so a single flat inventory would hide where authorization must change.
1.3 Shared and virtual infrastructure
Many systems run on hardware owned by someone else: a hosting provider, a managed-service partner, a cloud platform. The client may own the virtual machine but not the hypervisor or the storage fabric beneath it. Authorization from the client therefore covers only what the client controls. Provider terms, which sometimes require notice and sometimes forbid certain test types, must be read before planning.
Shared hosting means TRT may not see the underlying hypervisor. Priya's ENG-712 scope therefore names virtual machines and URLs TRT controls, not the provider's management plane. When a finding touches shared infrastructure she escalates to the cloud owner rather than probing sideways. Northpoint's ROE repeats that boundary so testers do not invent permission.
1.4 The asset record
A useful record holds: identifier, business function, owner, location (physical or logical), operating system and version, criticality, known fragility, and the authorization status for testing. Every later chapter leans on these fields: scope checks read the address, risk ratings read criticality, reports read the owner.
Priya's asset row for the staff portal carries owner, criticality and the fragile note "change freeze Fridays". Without that record lab_scope decisions look arbitrary. She updates the row when DNS moves, because a stale identifier is how OUT-OF-SCOPE hosts get tested by mistake.
Worked example
Priya inventories the TRT timetable server. Hardware: a three-year-old rack server. Firmware: vendor BMC with its own network port. OS: a supported Linux release. Application: the timetable API. She records the BMC as a separate asset, because its network port lives on a management VLAN that Northpoint's scope does not mention. The scope meeting will need to decide whether it is in or out.
Synthetic case. Tidewater Regional Transit and its timetable server are invented for this chapter.
Errors and limits
Treating "the server" as one thing hides firmware and management interfaces. Assuming cloud tenancy grants permission over the provider's layers is a common and serious mistake. This chapter describes architecture only; it does not explain how to attack any layer.
Exercises
- EX001 — Hidden interface. Why should a baseboard management controller with its own network port appear as its own asset record? Rubric: 3 = separate interface, separate owner/patch route, scope must decide explicitly; 2 = separate interface only; 1 = "it is part of the server"; 0 = none.
- EX002 — Fragile daemon. A legacy route-planning daemon crashes under heavy load. Propose how the plan should treat it. Rubric: 3 = record fragility, agree lower-impact method (config review or throttled check) with owner, document in ROE; 2 = exclude without discussion; 1 = test normally; 0 = none.
- EX003 — Hosting boundary. TRT rents virtual machines from a hosting company. Which layers can TRT authorize, and what must be checked for the rest? Rubric: 3 = TRT authorizes its VMs/apps; hypervisor and fabric need provider terms/notice; 2 = partly; 1 = TRT authorizes everything; 0 = none.
Synthesis
Name the layer, record the owner and the fragility, and never let tenancy masquerade as authority over someone else's hardware.