◇ OpenCyber Academy
Doctoral research · Chapter 8 · English

Chapter 8 — Defense and publication plan

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 8 — Defense and publication plan

Lesson map

Lesson 08 published. Map, example, EX045.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Preparing for the hard questions"]
  N2["8.2 Answering without overclaiming"]
  N3["8.3 Choosing venues"]
  N4["8.4 Coordinated release with the partner"]
  N5["8.5 Follow-on research"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX045"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Preparing for the hard questions"]
  N2["8.2 Answering without overclaiming"]
  N3["8.3 Choosing venues"]
  N4["8.4 Coordinated release with the partner"]
  N5["8.5 Follow-on research"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX045"]
[Learning outcomes]
    |
    v
[8.1 Preparing for the hard questions]
    |
    v
[8.2 Answering without overclaiming]
    |
    v
[8.3 Choosing venues]
    |
    v
[8.4 Coordinated release with the partner]
    |
    v
[8.5 Follow-on research]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX045]

Learning outcomes

You will (1) prepare a doctoral defense around the claim's weakest points; (2) plan publication venues and coordinated release with a partner; (3) define follow-on research, including post-quantum migration.

8.1 Preparing for the hard questions

Nadia lists the ten questions she least wants to hear and prepares a short, evidence-based answer for each. Among them: why twelve clusters are enough, whether the Hawthorne effect explains the result, why severity weighting was not primary, and whether lint alone could deliver the gain. For each answer she points to a section, a table or an archive file rather than to her opinion. Prof. Brandt runs two mock defenses with colleagues who have not read the thesis, because they ask the naive questions that the real committee often asks first.

8.2 Answering without overclaiming

During the defense an examiner asks whether the study proves checklists work. Nadia answers that it shows a sizeable reduction in one organisation over one quarter, with a confidence that rests on a permutation test, blinded confirmation and a third auditor, and that durability and transfer are open. When asked why she did not test exploitability of findings, she explains that the ethics approval forbade exploit work and that confirmed codebook violations are a recognised proxy, not a measure of breaches. Precise, bounded answers earn more trust than confident generalisations.

8.3 Choosing venues

Nadia plans two papers. The trial goes to a peer-reviewed software-engineering security venue, where reviewers value randomised field evidence. A shorter practitioner article explains the checklist questions, each tied to a public source such as SP 800-38D for nonce limits, SP 800-57 for key lifecycles and RFC 9106 for password hashing. She checks each venue's open-data policy against her release list, and plans to post an accepted manuscript in an open repository so the checklist reaches teams that cannot pay for journal access.

8.4 Coordinated release with the partner

Before submission, Meridian's security lead reviews both manuscripts against the data agreement, confirming that no live weakness is described and that every example finding is an invented paraphrase. They agree on a timetable: the archive goes public on acceptance, the practitioner article after Meridian has rolled the checklist out to all teams, and any newly found issue follows Meridian's disclosure process before publication. Writing this down protects both parties and shows examiners that research outputs and partner security were planned together, not traded off at the last minute.

8.5 Follow-on research

Nadia proposes two follow-on studies. The first repeats the trial in organisations without a mature wrapper, stratified by code age, to test transfer. The second studies post-quantum migration: NIST has standardised ML-KEM in FIPS 203, ML-DSA in FIPS 204 and SLH-DSA in FIPS 205, and migrating to them will introduce new parameters, larger keys and hybrid handshakes, all fresh opportunities for misuse. She suggests extending the codebook with migration categories, such as unsupported hybrid combinations, and measuring whether checklist questions written now prevent mistakes when real migration work starts.

Worked example

Nadia's defense pack maps ten hard questions to evidence, her publication plan pairs a trial paper with a practitioner article, and her release timetable with Meridian is signed before submission.

Synthetic note. The committee, venues' decisions and Meridian timetable are invented; FIPS 203, 204 and 205 are real standards.

Errors and limits

A defense is not won by certainty; claims beyond the evidence invite failure. Publication plans must never move faster than the partner's ability to fix what research reveals.

Exercises

Synthesis

A strong defense names the claim's limits before the committee does, and a publication plan coordinated with the partner turns evidence into safer practice without exposing live systems.

Continue studying — chapter 08 of 08

← Chapter 07 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →

Worked answers

EX045. Readers new to the thesis raise the simple, basic questions that real committees tend to open with.

EX046. It shows a large reduction in one organisation over a single quarter, supported by the permutation test, blinded auditors and a third-party check, while long-term durability and transfer remain unanswered.

EX047. The ethics approval prohibited exploit testing, and confirmed violations of codebook rules are an accepted proxy rather than a count of breaches.

EX048. SP 800-38D for nonce limits, SP 800-57 Part 1 for key lifecycle and RFC 9106 for password hashing.

EX049. The archive is published on acceptance, the practitioner piece after Meridian's full rollout, and any new issue goes through Meridian's disclosure process before publication.

EX050. FIPS 203, 204 and 205 standardise ML-KEM, ML-DSA and SLH-DSA; migrating brings new parameters, bigger keys and hybrid handshakes that create fresh misuse risk.