Chapter 20 — Security architecture and engineering: troubleshooting
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 A method"]
N2["20.2 Control failure or attack"]
N3["20.3 Fixing safely"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 A method"]
N2["20.2 Control failure or attack"]
N3["20.3 Fixing safely"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 A method]
|
v
[20.2 Control failure or attack]
|
v
[20.3 Fixing safely]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) troubleshoot security controls methodically; (2) distinguish control failures from attacks; (3) fix without weakening security.
20.1 A method
When drivers at the north depot report that handhelds cannot sync routes, Tomás follows a method: describe the symptom precisely, check what changed recently, test one layer at a time from the network up, and form one hypothesis at a time. The symptom started that morning on all north depot handhelds but not elsewhere. The recent change was a firewall update the previous evening. A methodical approach avoids random changes that make problems harder to diagnose and can quietly remove protections.
20.2 Control failure or attack
Tomás checks whether the cause is an attack or a misconfiguration. Logs show the handhelds reaching the firewall and being denied on the tracking service's new address, which the provider had announced the week before. The firewall rule allowed the old address only. There are no signs of malicious activity. Ruth stresses that many apparent incidents are control failures, and many control failures look like attacks. Checking logs before assuming either avoids both panic and complacency. He records which log lines ruled out an attack in the incident note.
20.3 Fixing safely
The quick fix suggested by a supervisor is to allow all outbound traffic from the handheld zone. Tomás instead updates the rule to allow the provider's published address range for the service and adds a note to subscribe to the provider's change announcements. Syncing resumes within an hour. He records the incident, the cause and the fix in the change log. Troubleshooting under pressure tempts people to remove controls; a good technologist restores service while keeping the design intact. Sam adds the provider's announcements to his weekly reading.
Worked example
Tomás troubleshoots a sync failure layer by layer, rules out an attack from logs and fixes the firewall rule without opening all traffic.
Synthetic case. The incident is synthetic.
Errors and limits
Providers do not always announce changes. Quick fixes become permanent if unrecorded.
Exercises
- EX058 — Recent change. What recent change pointed to the cause? Rubric: 3 = a firewall update the previous evening;; 2 = firewall;; 1 = vague;; 0 = none.
- EX059 — Real cause. What was the actual cause? Rubric: 3 = the tracking service moved to a new address not allowed by the rule;; 2 = new address;; 1 = attack;; 0 = none.
- EX060 — Rejected fix. Why reject allowing all outbound traffic? Rubric: 3 = it removes a control to restore service;; 2 = weakens;; 1 = slow;; 0 = none.
Synthesis
Methodical troubleshooting restores service while keeping security controls intact.
Continue studying — chapter 20 of 30
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →