Chapter 5 — Security scope and evidence
Lesson map
Lesson 05 published. Map, example, EX017.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Scope"]
N2["5.2 Authorisation"]
N3["5.3 Evidence"]
N4["5.4 Preserving evidence"]
N5["5.5 Facts and judgements"]
N6["Evidence register"]
N7["Confidentiality"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX017"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Scope"]
N2["5.2 Authorisation"]
N3["5.3 Evidence"]
N4["5.4 Preserving evidence"]
N5["5.5 Facts and judgements"]
N6["Evidence register"]
N7["Confidentiality"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX017"]
[Learning outcomes]
|
v
[5.1 Scope]
|
v
[5.2 Authorisation]
|
v
[5.3 Evidence]
|
v
[5.4 Preserving evidence]
|
v
[5.5 Facts and judgements]
|
v
[Evidence register]
|
v
[Confidentiality]
|
v
[Worked example] --> [Exercise EX017]
Learning outcomes
You will (1) define the scope of a security review; (2) collect evidence with time and source; (3) respect authorisation.
5.1 Scope
Grace defines Tomás's scope: Fairway's storage buckets, identities and cluster settings, using read-only access and synthetic copies where possible. Partner systems are out of scope. The scope covers what Fairway controls and what the March exposure touched. Read-only access means Tomás can export settings and logs but not change anything while investigating. The partner's systems are excluded because Fairway has no authority over them; any questions about the partner's copies go through the account manager, not through Tomás testing their side.
5.2 Authorisation
The scope is written and signed by Grace and the IT manager. Tomás does not test anything outside it. Written scope protects both Tomás and Fairway if his work is questioned later. If someone later asks why he looked at a bucket, the signed scope answers. If he finds something interesting outside it, such as the partner's download server, he reports it to Grace rather than probing it. The scope document is stored with the evidence register so the two can be read together.
5.3 Evidence
Evidence includes exported audit events, settings and permission lists, each saved with collection time and source. For the March work this means the storage audit events, the bucket settings export and the permission lists for dev-sam, CI deploy and Grace's account. Each export notes the account used, the time and the provider console or command. Without that note, a reviewer could not tell whether a later setting change happened before or after the export was taken. Tomás lists each export in the evidence register before he begins any analysis on it.
5.4 Preserving evidence
Copies are stored read-only so they cannot be altered. Tomás saves each export to a folder where nobody, including himself, can edit files after saving, and records a hash of each file in the evidence register. All analysis happens on working copies made from those stored originals. If a later check shows a working copy differs from the stored original, he discards it and makes a fresh one, so the timeline always rests on unaltered records. The hash list itself is stored beside the register, so either can be checked against the other.
5.5 Facts and judgements
Tomás separates what records show from what he concludes. A fact here is 'dev-sam set the policy to public-read at 16:41 on 3 March'; a judgement is 'the reads came from the partner'. The second rests on comparing source addresses with the partner's range and may be wrong. Writing them separately lets Grace and the data protection lead see which statements they can accept directly and which depend on reasoning. Tomás marks each judgement in the timeline with the facts it rests on, so a reviewer can trace the reasoning. If later evidence changes a fact, the judgements that depend on it are easy to find and revise.
Evidence register
Tomás keeps an evidence register listing each item, its source, collection time, who collected it and where it is stored. When the timeline is written later, each statement points to a register entry. This lets Grace or an auditor trace any claim back to its record.
The register also records what was not available. For example, data access logs were enabled only on the manifests bucket, so reads of other buckets during the period cannot be checked. Recording gaps prevents later readers from assuming more coverage than existed.
Confidentiality
The manifests contain customer addresses. Tomás works with synthetic copies for analysis and does not open real manifests; the decision about customer impact is made by the data protection lead using the evidence he provides.
Keeping time
All times are recorded in one time zone, stated at the top of the register, to avoid confusion when comparing provider logs with staff notes.
Worked example
Tomás exports the storage audit events for March and saves them with a note of who exported them, when and from which account. Grace checks the note before analysis begins.
Synthetic case. Scope is synthetic.
Errors and limits
Working outside scope, even with good intentions, can break trust and rules.
Exercises
- EX017 — Out of scope. What was out of scope? Rubric: 3 = partner systems; 2 = partial; 1 = vague; 0 = none.
- EX018 — Authorisation. Who signed the scope? Rubric: 3 = Grace and IT manager; 2 = partial; 1 = vague; 0 = none.
- EX019 — Evidence note. What did Tomás record with the export? Rubric: 3 = who, when, which account; 2 = two; 1 = one; 0 = none.
- EX020 — Fact versus judgement. Why separate facts from conclusions? Rubric: 3 = others can check reasoning; 2 = partial; 1 = vague; 0 = none.
Synthesis
Work inside written scope with recorded evidence.
Continue studying — chapter 05 of 18
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →