◇ OpenCyber Academy
Rapid course · Chapter 3 · English

Chapter 3 — Findings, evidence and responsible reporting

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 3 — Findings, evidence and responsible reporting

Lesson map

Lesson 03 published. Map, example, EX027.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 What a finding is"]
  N2["3.2 Evidence without harm"]
  N3["3.3 Naming techniques"]
  N4["3.4 Honest severity"]
  N5["3.5 Who reads the report"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX027"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 What a finding is"]
  N2["3.2 Evidence without harm"]
  N3["3.3 Naming techniques"]
  N4["3.4 Honest severity"]
  N5["3.5 Who reads the report"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX027"]

[Learning outcomes]
    |
    v
[3.1 What a finding is]
    |
    v
[3.2 Evidence without harm]
    |
    v
[3.3 Naming techniques]
    |
    v
[3.4 Honest severity]
    |
    v
[3.5 Who reads the report]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX027]

Learning outcomes

You will (1) describe what makes a useful finding; (2) keep simple evidence without attacking systems; (3) map a finding to an ATT&CK technique name; and (4) write a short, audience-aware report.

3.1 What a finding is

A finding is a specific, evidenced weakness or gap that matters to the organisation. It states what was observed, where, when, why it matters, how to reproduce the observation within the rules, and a suggested fix. Vague statements such as "security is weak" are not findings.

For example, Maya's finding F3 states that the grading system uses one shared admin account, so logs cannot show which staff member changed a mark. It names the system, gives the evidence, explains the harm to student records and suggests named accounts as the fix. An owner can check it and act on it.

3.2 Evidence without harm

Evidence can be configuration screenshots, log lines, policy excerpts or the output of authorized tools. You keep only what the agreement allows, mark it with time and source, and never share it beyond the agreed audience. This course's labs never touch live targets.

If evidence contains personal data, such as student names in a screenshot, redact them or replace the screenshot with a synthetic sample that still shows the issue. Store evidence where only the agreed people can read it, and delete or return it when the agreement says.

3.3 Naming techniques

Linking a finding to MITRE ATT&CK helps defenders search for related detections. For example, a shared password reused across systems relates to T1078 Valid Accounts. The name describes the behaviour; it does not prove who the attacker would be.

Use the technique name as a pointer, not a conclusion. Maya's F3 maps to T1078 because shared credentials let anyone holding them act as a legitimate user without leaving their own name in the logs. Defenders can then check whether their monitoring would notice that behaviour on the grading system. Map a finding only when the behaviour clearly matches.

3.4 Honest severity

Severity combines how easy the issue is to use and how much harm it could cause. Industry scores such as CVSS exist, but many organisations also use a simple likelihood × impact scale agreed with the client. Overstating severity destroys trust; understating it leaves risk unaddressed.

Maya's scale multiplies likelihood and impact, each from 1 to 3. F3 scores 2 × 3 = 6: the shared admin account is not trivial to misuse, but altered grades with no accountability would harm students and the college's trust. Use CVSS only if the organisation already does and the scores follow its method.

3.5 Who reads the report

Executives need short risk language and decisions; system owners need reproduction steps and fixes; defenders need technique names and detection ideas. One report often has a summary for leaders and detail for engineers.

For F3, Maya writes one paragraph telling the IT director why shared admin access threatens grade integrity, and a fix list telling the application owner to replace the shared login with named accounts and record user identity in the audit log. Detailed evidence sits in an attachment for engineers. Check that every version tells the same facts.

Worked example (synthetic RCC)

After a synthetic classroom review of RCC policies (no live scan), Maya drafts finding F3: "The grading system uses one shared admin account; logs cannot show which staff member changed a mark." She links it to ATT&CK T1078 Valid Accounts, rates likelihood 2 and impact 3, and writes a one-paragraph summary for the IT director plus a detailed fix list for the application owner.

Synthetic case — RCC. The finding and ratings are invented for the classroom.

Errors and limits

ATT&CK mappings are aids, not proof of an intrusion. Severity without an agreed scale confuses readers.

Exercises

Synthesis

Findings are specific, evidenced and mapped to shared technique names; reports tell each audience what to do.

Continue studying — chapter 03 of 04

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