Chapter 15 — Security fundamentals | Engineering Authorized offensive security and red team

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 15 — Security fundamentals

Lesson map

Lesson 15 published. Map, example, EX043.

flowchart TD
  N0["Learning outcomes"]
  N1["15.1 CIA as questions"]
  N2["15.2 Vulnerability, exposure, risk"]
  N3["15.3 Empty scores"]
  N4["15.3b Mapping to tickets"]
  N5["15.1b From property to test"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX043"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["15.1 CIA as questions"]
  N2["15.2 Vulnerability, exposure, risk"]
  N3["15.3 Empty scores"]
  N4["15.3b Mapping to tickets"]
  N5["15.1b From property to test"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX043"]

[Learning outcomes]
    |
    v
[15.1 CIA as questions]
    |
    v
[15.2 Vulnerability, exposure, risk]
    |
    v
[15.3 Empty scores]
    |
    v
[15.3b Mapping to tickets]
    |
    v
[15.1b From property to test]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX043]

Learning outcomes

You will (1) map CIA and authentication/authorization to assessment questions; (2) distinguish vulnerability, exposure and risk; (3) refuse risk scores without a model.

15.1 CIA as questions

Confidentiality: who can read this? Integrity: who can change this? Availability: what stops this working? Each finding should say which property is affected and for which asset. "Security issue" without that map is not actionable.

Mapping each finding to confidentiality, integrity or availability tells the fixer what kind of harm to prevent. An asset without a property leaves the client guessing whether to encrypt, validate or add capacity. Sam rejects draft tickets that still say only 'security issue' and sends them back with the three questions listed.

15.2 Vulnerability, exposure, risk

A default password is a vulnerability. On a staging host reachable from the corporate network it is an exposure. Risk adds likelihood and impact for the organization — which needs their context, not a universal CVSS-only story. FindingsDesk stores impact and exposure fields separately; risk acceptance stays with the client.

Separating the three stops a default password on an isolated lab host being scored like one on the public portal. Exposure fields capture reachability; impact fields capture harm; acceptance of residual risk stays a client decision. CVSS alone cannot know Riverstone Transit's ridership or depot layout. Sam fills exposure and impact and leaves the acceptance box for the client owner.

15.3 Empty scores

Albrecht and Jensen (arXiv:2010.06377) criticize methodology scores that do not predict outcomes. Prefer concrete measures: out-of-scope probe count, time-to-fix, precision at the client's base rate. If you show a score, show the model and the inputs.

Synthetic case — Riverstone Transit. Sam stopped putting a single "risk = 42" on slides. The deck now shows two critical findings, three SLA breaches and 71% technique coverage of the planned set.

A methodology score that does not predict outcomes flatters the assessor and misleads the buyer. Counts of out-of-scope probes and time-to-stop are ugly and useful. When a score must appear, the model and inputs sit beside it so another engineer can recompute. Sam's dashboards lead with those concrete measures.

15.4 Errors and limits

Fundamentals are shared vocabulary; they are not a complete threat model. Continue into Chapter 23 for structured failure analysis.

Shared vocabulary gets teams talking; it does not list every failure mode. Structured analysis later in the course builds on these terms rather than replacing them. Sam treats a CIA label as the start of a finding, not the end of the threat model. He expects the structured analysis chapters to add failure modes these terms alone cannot name. Until then, the vocabulary still prevents vague tickets.

15.3b Mapping to tickets

Every finding should cite which property (C, I, or A) is primarily affected and whether the issue is vulnerability, exposure, or a risk judgment left to the client. FindingsDesk can require the fields so reports stay consistent across authors and semesters.

Required fields stop authors inventing private shorthand for the same ideas. Consistency across semesters means a re-test engineer can read last year's ticket without a translation guide. Clients comparing two firms see the same shape of claim. Sam's template blocks submit until property and issue-kind are set.

15.1b From property to test

If a finding claims confidentiality impact, the validation plan must include a confidentiality check (who can still read). If it claims availability impact, validation includes a canary or synthetic probe — not a new attack. Align property, finding and re-test method in one paragraph of the ticket.

Availability claims need a gentle canary, not a fresh flood. One paragraph that ties property, finding and re-test keeps the ticket coherent after handoff. Sam pastes that paragraph into the validation plan field before the finding leaves draft.

Exercises

EX043 — CIA map. Map SYN-001 (default admin on staging) to C/I/A with one sentence each. Rubric: 3 = all three scoped; 2 = two; 1 = one; 0 = none.
EX044 — Terms. In one sentence each, distinguish vulnerability, exposure and risk for SYN-005. Rubric: 3 = clear split; 2 = two clear; 1 = muddled; 0 = none.
EX045 — Score refusal. A stakeholder wants a single 0–100 "hackability" score. Write a refusal with an alternative. Rubric: 3 = refuses empty score, offers concrete measures; 2 = refuses only; 1 = vague; 0 = invents score.

Synthesis

Name the property, separate exposure from risk, and prefer measures you can recompute.

Continue studying — chapter 15 of 50

← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →