◇ OpenCyber Academy
Bachelor's · Chapter 4 · English

Chapter 4 — Academic writing

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 4 — Academic writing

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Blame-free findings"]
  N2["4.2 Fact vs claim"]
  N3["4.3 Citations"]
  N4["4.4 Audience layers"]
  N5["4.5 Structure"]
  N6["4.6 Revision"]
  N7["4.7 Applied note"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Blame-free findings"]
  N2["4.2 Fact vs claim"]
  N3["4.3 Citations"]
  N4["4.4 Audience layers"]
  N5["4.5 Structure"]
  N6["4.6 Revision"]
  N7["4.7 Applied note"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 Blame-free findings]
    |
    v
[4.2 Fact vs claim]
    |
    v
[4.3 Citations]
    |
    v
[4.4 Audience layers]
    |
    v
[4.5 Structure]
    |
    v
[4.6 Revision]
    |
    v
[4.7 Applied note]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) write findings without blame; (2) separate facts from claims; (3) cite frameworks correctly.

4.1 Blame-free findings

"Shared admin account on loan system" beats "lazy admins". Boards fund fixes; insults create enemies. A finding that names a weakness, its location and its consequence gives the owner something to fix. A finding that names a group of people gives them something to defend. Sam writes the shared admin account finding with the system, the account, what the logs can and cannot attribute, and a recommended change, and leaves character judgements out entirely, because the same report will be read by the people who must do the work.

4.2 Fact vs claim

Fact: web tier opened a TCP session to ledger-db. Claim: "attackers can move money" needs more evidence or is labelled speculative. The connection itself is observed and logged; the claim about moving money depends on what ledger-db would accept from that session, which the test did not explore. Sam writes the fact in the finding and either labels the larger claim as speculative or lists the evidence that would be needed to support it. Readers can then weigh each sentence by its evidence rather than by its tone.

4.3 Citations

NIST SP 800-115, PTES, ATT&CK, OWASP WSTG, TIBER-EU and CBEST are cited with correct titles. Never invent DOIs. Each citation is checked against the publisher's page before the report goes out, and the edition or version matters: SP 800-115 is cited as NIST's technical guide to testing and assessment, not as a regulation. If Sam cannot find a source's official identifier, he cites the title and URL and says nothing more. An invented DOI would undermine every true sentence near it.

4.4 Audience layers

Executives need decisions; engineers need reproduction; both need honesty about uncertainty. For the shared admin account finding, the CISO needs the decision (fund named accounts for the loan system), the engineer needs the system name, the account and the log gap, and both need the same statement of what was not tested. Sam writes the executive summary and the technical appendix from the same finding record so they cannot drift apart. Uncertainty, such as untested hosts, goes in both parts in the same words.

4.5 Structure

Summary, scope/methods, findings, positives, limitations, appendices. The order is deliberate. A reader who stops after the summary still knows the decision asked; scope and methods tell everyone what was and was not tested before any finding is read; positives record what held up, such as SWIFT remaining unreachable; limitations stop the report being read as a guarantee. Appendices carry the hashes, ticket IDs and method cards that let an engineer reproduce each step. Sam uses this structure for every TRB report.

4.6 Revision

Peer review catches jargon and overclaim before the CISO sees the draft. Sam's reviewer reads for two things: words a non-specialist would not understand, and sentences that claim more than the evidence shows, such as 'attackers can move money' in place of the observed connection to ledger-db. Each comment is answered in the draft history, so the final report shows what changed and why before the CISO receives it. Unresolved comments block release; resolved ones stay visible. The CISO receives only the reviewed version, so overstated drafts such as 'attackers can move money' never reach the CISO.

4.7 Applied note

Citation drills require opening the live NIST or PTES page, not a blog summary. Sam failed an early draft for citing a second-hand SP 800-115 paraphrase that invented a clause. Primary sources only — the same rule as never inventing DOIs. The NIST page also shows the document's status and date. Sam now records, beside each citation in his draft, the date he opened the primary page and the section he relied on. Reviewers can then check a claim against the same page instead of trusting his memory of it.

4.8 Audience pass

Before sending, Sam reads the executive summary aloud to someone outside security. If they cannot restate the decision asked, he rewrites. Jargon surviving that pass is a defect. The listener's restatement is noted in the draft history for later comparison. For the shared admin account report, a listener from finance restated the ask as 'pay for named accounts on the loan system', which matched. An earlier draft had produced 'something about passwords', which sent it back for rewriting. The finance listener was chosen deliberately.

4.9 Passive voice audit

Findings that hide actors in passive voice are rewritten. "Passwords were reused" becomes "The loan admin account used the same password as VPN" when known. Naming the system makes the finding actionable and testable. When the actor is not known, the sentence says so plainly, for example 'logs do not show which administrator changed the setting'. That keeps the finding honest without inventing a culprit, and it points straight at the logging gap as a second issue to fix. Fixing the 'developers ignored security' draft needed only one rewritten sentence naming the system and the missing log.

4.10 Rewriting an accusatory finding

A draft finding once said "developers ignored security". Legal asked for rewrite before the board pack. Sam produced: "The loan service accepted a shared privileged password; logs cannot attribute changes to a person." Same facts, fundable tone. He keeps both versions in teaching notes to show the difference. The rewrite removes the accusation but keeps every fact: a shared privileged password and no attribution in the logs. That is why it survived legal review and still told the loan service owners exactly what to change.

Tone trophies are silly stickers on printed findings that developers praised as clear. Sam prefers stickers to metrics nobody reads. Each sticker records which finding was praised and why, so the next report can copy the clarity rather than just the sticker. Clarity that developers notice is clarity that gets fixes. Sam keeps the praised findings in a folder as examples for interns. Finding counts stay secondary in Sam's reports, because a clear finding that gets fixed matters more than a long list.

Worked example (synthetic TRB)

Sam rewrites "the web team is incompetent" to "web tier reaches ledger-db on an unapproved flow; control: enforce approved matrix".

Synthetic case — Riverstone Transit Bank (TRB). The bank, Sam Ito, TrackScope/FindingsDesk/PulseMap and all figures are invented for teaching.

Errors and limits

This book grants no authority to test real banks or payment systems. Labs use documentation-range addresses and synthetic data only; exploit code is never provided.

Exercises

Synthesis

Clear, cited, audience-aware writing is part of authorized testing craft.

Continue studying — chapter 04 of 40

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →