Lesson map
Lesson 36 published. Map, example, EX106.
flowchart TD
N0["Learning outcomes"]
N1["36.1 Cost of controls"]
N2["36.2 Scaling logs"]
N3["36.3 Load testing"]
N4["36.4 Trade-offs at scale"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX106"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["36.1 Cost of controls"]
N2["36.2 Scaling logs"]
N3["36.3 Load testing"]
N4["36.4 Trade-offs at scale"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX106"]
[Learning outcomes]
|
v
[36.1 Cost of controls]
|
v
[36.2 Scaling logs]
|
v
[36.3 Load testing]
|
v
[36.4 Trade-offs at scale]
|
v
[Worked example] --> [Exercise EX106]
Learning outcomes
You will (1) assess the performance cost of security controls; (2) scale security processing with growth; (3) test controls under load.
36.1 Cost of controls
Security controls consume resources. Encryption uses processor time, logging uses storage and network capacity, and inspection adds latency. Lindiwe measures a synthetic test: enabling full-disk encryption on modern laptops adds a small processing overhead that users do not notice, while inspecting all encrypted web traffic at the depot firewall roughly doubles its processor load. She recommends inspecting only categories of traffic with clear risk, rather than everything. The network team adopts the selective approach and documents exactly which traffic categories are inspected.
36.2 Scaling logs
Saltmarsh plans three new depots. Lindiwe uses her first-year model to estimate the extra events per day and checks whether the log collector can handle them. At current growth, the collector reaches capacity within eighteen months. She proposes filtering low-value events at the source and adding a second collector before the limit. Prof. Hale notes that security systems that silently drop data under load are worse than those that fail loudly. The infrastructure team adds the second collector to next year's budget.
36.3 Load testing
Lindiwe tests the password-guessing measure at ten times today's log volume using synthetic data. It completes in a few seconds, well within the reporting window. She also tests the asset reconciliation with ten thousand hosts; it remains fast because it uses set operations. She records the tests so future growth can be checked against them. She learns that standard library tools scale well for moderate volumes when algorithms are chosen sensibly. The test records include data sizes and run times for each script.
36.4 Trade-offs at scale
As volumes grow, Saltmarsh must choose between keeping all detail and reducing cost. Lindiwe proposes keeping full authentication and administrative events, which are central to investigations, while summarising routine firewall allow events after thirty days. She documents which investigation questions become harder to answer after summarisation. The security lead accepts the proposal with a review after one year, recognising that the trade-off may need adjusting. She lists the affected questions in an appendix to the retention policy, so investigators know in advance what detail remains available.
Worked example
Lindiwe measures control overhead, finds the log collector reaches capacity in eighteen months, load-tests detection at ten times volume and proposes keeping full authentication events while summarising routine firewall logs.
Synthetic case. Measurements are synthetic.
Errors and limits
Security systems that silently drop data under load give false assurance.
Exercises
- EX106 — Inspection cost. What does inspecting all encrypted traffic do?
Show marking criteria
Rubric: 3 = roughly doubles firewall processor load;; 2 = partly correct;; 1 = vague;; 0 = none. - EX107 — Collector capacity. When does the collector reach capacity?
Show marking criteria
Rubric: 3 = within eighteen months;; 2 = partly correct;; 1 = wrong;; 0 = none. - EX108 — Kept events. Which events are kept in full?
Show marking criteria
Rubric: 3 = authentication and administrative events;; 2 = partly correct;; 1 = vague;; 0 = none.