Chapter 28 — Field practice | Technologist Quantum and post-quantum security

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 28 — Field practice

Lesson map

Lesson 28 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["28.1 Placement tasks"]
  N2["28.2 Change control and authorization"]
  N3["28.3 Working with mentors"]
  N4["28.4 Reflection"]
  N5["28.6 Practical activity"]
  N6["28.7 Professional conduct"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["28.1 Placement tasks"]
  N2["28.2 Change control and authorization"]
  N3["28.3 Working with mentors"]
  N4["28.4 Reflection"]
  N5["28.6 Practical activity"]
  N6["28.7 Professional conduct"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]

[Learning outcomes]
    |
    v
[28.1 Placement tasks]
    |
    v
[28.2 Change control and authorization]
    |
    v
[28.3 Working with mentors]
    |
    v
[28.4 Reflection]
    |
    v
[28.6 Practical activity]
    |
    v
[28.7 Professional conduct]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) apply implementation skills in a supervised placement; (2) work within change control and authorization; (3) contribute to inventory, configuration or monitoring tasks; and (4) reflect on practice with evidence.

28.1 Placement tasks

Typical tasks: extend an inventory feed, validate a scanner, update a crypto profile in staging, build a dashboard panel, write a runbook, test a vendor appliance's hybrid support in a lab.

Each task should be small enough to finish and review in the placement, produce an artefact the host keeps, and connect to a chapter of this book. A good placement gives the student one task with production impact after review, such as the dashboard panel in the worked example, and keeps the rest in lab or staging.

28.2 Change control and authorization

Follow the host organization's change process; get written scope for any scanning or testing; never run tools against production without approval; never take data off approved systems. Report serious findings — such as exposed private keys — immediately through the organization's process.

The scope agreement is signed before any tool runs and lists systems, methods, windows, data handling and contacts. If a task drifts outside it, such as a mentor asking for a quick scan of another subnet, the student asks for the scope to be amended in writing first. Findings outside the task are reported, not investigated further.

28.3 Working with mentors

Agree goals with your mentor in week one; ask for review of every change; keep a log of what you did and learned; ask questions early.

A short weekly meeting with the mentor reviews the log and next week's tasks. Students who ask early, for example "which host list is approved for the scanner?", avoid the scope errors that end placements. Mentors also review written artefacts, because a runbook a student wrote will be used by the host's operators.

A KLS student who asked about the scanner host list in a ticket got a written answer naming the approved hosts, which later settled a disagreement about whether a staging proxy had been in scope.

28.4 Reflection

Each week: task, evidence produced, surprise, lesson, next step. Link lessons to chapters of this book.

A useful entry is specific: "Validated the scanner against three lab servers; it reported the hybrid-preferred server as classical; surprise: the bundled library was older than the scanner's release date suggested; lesson: record tool library versions, Chapter 17; next: upgrade and re-validate." Entries that only list tasks give the assessor nothing to judge.

Assessors read the entries in order, looking for lessons that change what the student does in later weeks rather than repeating the same mistake.

28.5 Worked example

A student on placement at a (synthetic) regional parcel company validates the company's TLS scanner against a lab server, finds its library predates ML-KEM support, and documents the upgrade. With approval, they add a negotiated-group field to the load-balancer logs in staging and build a dashboard panel; the mentor promotes it to production after review.

The student's two contributions follow the book's habits: validate a tool before trusting it, and add a log field rather than debug logging. The mentor's review before production is part of the result, not a formality; it is the host's change control working as intended.

28.6 Practical activity

Write your placement scope agreement and the first two weekly reflection entries.

The scope lists the systems you may touch (lab and named staging hosts), the methods and tools with versions, the time windows, the data you may store and where, what you must not do, and the contacts for questions and for reporting serious findings. Sign it with your mentor. The two reflection entries each use the headings task, evidence produced, surprise, lesson and next step, and each lesson links to a chapter of this book.

28.7 Professional conduct

Placements are also a test of conduct: respecting confidentiality agreements, not discussing the host's weaknesses outside approved channels, crediting colleagues' work, and admitting mistakes quickly. A student who reports "I ran the audit against the wrong host list; here is what happened and what I did" builds more trust than one whose error is discovered later by someone else.

Conduct also covers what leaves the placement: no screenshots of the host's dashboards in a portfolio without written permission.

KLS approved one student's write-up on the 1,530-byte ClientHello problem only after proxy-b's model and firmware version were removed, because they would have pointed attackers to an unpatched device.

28.8 Common errors and limits

Acting outside scope.
Unreviewed changes.
Logs listing tasks without lessons.

A student who scans a host because it "looked like staging" has acted outside scope, whatever the result; the agreement exists to prevent exactly that. A change merged without the mentor's review, even a log field, bypasses the host's change control. And a log reading "Monday: dashboard; Tuesday: runbook" shows activity but not learning. Each of these costs trust, which is what placements are meant to build.

At KLS a student who scanned a partner-facing SFTP host instead of the lab copy kept the placement because she reported it within the hour, and the security office recorded the incident with the scan logs she supplied.

Exercises

EX055 — Scope. Write a placement scope for validating a TLS scanner. Rubric: 3 = systems, methods, window, data, contacts.
EX056 — Reflection. Write one reflection entry for the worked example. Rubric: 3 = task, evidence, surprise, lesson, next step.

Synthesis

Field practice applies implementation skills inside real change control and authorization, with mentor review, professional conduct and evidence-based reflection.

Continue studying — chapter 28 of 30

← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →