◇ OpenCyber Academy
Technical · Chapter 5 · English

Chapter 5 — Security scope and evidence

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 5 — Security scope and evidence

Lesson map

Lesson 05 published. Map, example, EX013.

flowchart TD
  N0["Learning outcomes"]
  N1["5.1 Scope"]
  N2["5.2 Evidence"]
  N3["5.3 Sensitive data"]
  N4["5.4 Reporting"]
  N5["5.6 Hands-on activity"]
  N6["5.8 When something goes wrong"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["5.1 Scope"]
  N2["5.2 Evidence"]
  N3["5.3 Sensitive data"]
  N4["5.4 Reporting"]
  N5["5.6 Hands-on activity"]
  N6["5.8 When something goes wrong"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]

[Learning outcomes]
    |
    v
[5.1 Scope]
    |
    v
[5.2 Evidence]
    |
    v
[5.3 Sensitive data]
    |
    v
[5.4 Reporting]
    |
    v
[5.6 Hands-on activity]
    |
    v
[5.8 When something goes wrong]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes

You will (1) work only within written scope; (2) collect evidence that others can check; (3) protect sensitive data you encounter; and (4) report findings clearly.

5.1 Scope

Before running any check — even a TLS client connection to a production server — confirm it is within your written scope: which systems, which methods, which times, and who to call if something goes wrong. Active tests that try to force downgrades or inject faults are done only in an isolated lab.

At HHG, ticket OPS-412 is an example: it names the lab jump host, the staging portal and the method. If you are unsure whether a check is covered, ask before running it, not afterwards.

5.2 Evidence

Good evidence is specific and reproducible: the command, the target, the time, the output, and the tool version. Screenshots alone are weak; saved text output with a note is better. Store evidence where your team agreed, not on your laptop.

In the OPS-412 finding, the output was saved in an evidence folder named after the ticket, with time and tool. Use the same naming each time so evidence can be found later, and keep the tool version with every output, because an old client can report the wrong result.

5.3 Sensitive data

Handshake captures, logs and configuration files can contain hostnames, client addresses and sometimes credentials. Collect only what you need (for example, the negotiated group), avoid full packet payloads, and follow retention rules.

At HHG, guest records include passport details, so packet captures from guest-facing systems could contain them. Prefer client tool output and log fields over captures. If you capture by mistake, tell your supervisor and delete the file following the retention rules. Delete what you no longer need when the task ends.

5.4 Reporting

A finding states what you observed, where, when, how, why it matters and what you recommend, plus who owns the fix. Keep facts separate from opinions.

A good finding lets the owner act without asking you questions. Write the observation first, then the evidence, then your interpretation, clearly labelled as likely rather than certain. Name the owner and a recheck step, so the finding can be closed with evidence. If your interpretation turns out wrong after the recheck, update the finding and say so.

5.5 Worked example

Finding (synthetic): "On 3 October 10:15, from the lab jump host (in scope per ticket OPS-412), openssl s_client to guest-portal.staging.hhg.example negotiated X25519 although the server configuration lists X25519MLKEM768. Output saved in evidence/OPS-412/. Likely cause: group order. Impact: hybrid protection not in use on staging. Recommendation: reorder groups; recheck. Owner: Web Operations."

Note how the finding separates fact from inference: the negotiated group and configuration are observed, while "group order" is marked as a likely cause. The finding names scope, evidence location, impact and owner, so Web Operations can act and check the result.

5.6 Hands-on activity

Write a finding in this format for a lab result from Chapter 2.

Use one of your Chapter 2 runs, for example the connection that fell back to X25519 when hybrid was not offered. Include the time, the scope reference, the command and tool version, where the output is saved, the likely cause marked as such, the impact, a recommendation and an owner. Keep facts and opinions in separate sentences. Ask a peer to check whether an owner could act on it without asking you anything.

5.7 Common errors and limits

Each error damages trust. A check outside scope, however small, can break a service and end your team's authorization. Evidence without time or tool version cannot be reproduced or compared, so the work must be redone. Full packet captures collect guest data such as passport details that nobody needed. Check each finding and evidence folder for all three before you submit it. Correct any you find.

5.8 When something goes wrong

If a check you run causes an unexpected effect — an alert, a slow service, a locked account — stop, note the time and what you ran, and call the contact named in your scope. Do not try to fix it quietly. Early, honest reporting is what keeps authorization in place for future work, and the timeline you record helps the service owner separate your test from any real incident happening at the same time.

Afterwards, add a short note to the evidence folder describing what happened and what you would do differently; the next operator using the same scope will benefit from it.

Exercises

Synthesis

Operators work inside written scope, collect checkable evidence while minimizing sensitive data, and write findings that separate facts from opinion.

Continue studying — chapter 05 of 18

← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →