OpenCyber Academy
Technologist · Chapter 27 · English
Course code: OCA-086Chapter 27: OCA-086-C027

Chapter 27 — Deployment and validation

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Deployment"]
  N2["27.2 Validation in place"]
  N3["27.3 Results"]
  N4["27.4 Evidence of validation"]
  N5["27.5 Revalidation triggers"]
  N6["27.6 Monitoring"]
  N7["27.7 Sign-off"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Deployment"]
  N2["27.2 Validation in place"]
  N3["27.3 Results"]
  N4["27.4 Evidence of validation"]
  N5["27.5 Revalidation triggers"]
  N6["27.6 Monitoring"]
  N7["27.7 Sign-off"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Deployment]
    |
    v
[27.2 Validation in place]
    |
    v
[27.3 Results]
    |
    v
[27.4 Evidence of validation]
    |
    v
[27.5 Revalidation triggers]
    |
    v
[27.6 Monitoring]
    |
    v
[27.7 Sign-off]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) deploy the triage kit in production; (2) validate it in the real environment; (3) record validation evidence; (4) set revalidation triggers.

27.1 Deployment

Kit drives are prepared from the validated master, hashed, labelled and stored in the IT office safe and at the depot. Collection tooling is pre-installed on key servers.

Preparing every drive from the validated master and recording its hash means each kit in the field can be checked against a known reference. Two locations, the IT office safe and the depot, protect against one being unavailable. Pre-installing collection tooling on key servers removes the need to plug a drive into a production server during an incident.

27.2 Validation in place

Lab validation used synthetic images; production validation checks the kit on representative real machine types — using test accounts and synthetic files planted for the purpose, not personal data. ISO/IEC 27041 frames validation as showing a method is fit for its intended use.

Lab tests prove the method works on the systems they used; production machines differ in operating system versions, security software and configuration. Using test accounts and planted synthetic files lets the team check real machine types without touching residents' or staff data. Each machine type is tested with the same steps, so results can be compared.

27.3 Results

Memory capture works on all five machine types; triage collection misses one log path on the oldest desktop model because of a different OS version. The procedure gains a note and the old model is scheduled for replacement.

Finding the missed log path in validation is the purpose of validating: it would otherwise have been found during a real incident, with evidence missing. The procedure note tells operators to collect that path manually on the old model until replacement. The result is recorded with the machine type and OS version, so it is clear which systems the limitation affects.

27.4 Evidence of validation

A validation report lists machine types, tests, results, deviations and approval.

The report lets anyone see what was tested, on which machine types, with what result and who approved it. Deviations such as the missed log path are listed rather than hidden. If the kit's results are questioned in a future case, the report shows that the method was checked in this environment and where its known limits lie. The report is stored with the kit's master manifest and referenced in every case that uses the kit.

27.5 Revalidation triggers

New OS versions, new kit tool versions, new machine models.

Each trigger is a change that could make a previously valid method fail: a new operating system version may move logs, a new tool version may change its output, a new machine model may behave differently. When a trigger occurs, the affected tests are rerun before the kit is used on that system, and the validation report is updated with the new results. Operators are told which triggers apply, so they can raise them when they notice a change.

27.6 Monitoring

Kit drive hashes are checked quarterly against the master manifest.

Quarterly checks catch drives that have been altered, reformatted or reloaded with old tools, as happened at the depot. Each check compares the drive's tool-list hash with the master manifest and records the date, the person and the result. A drive that fails is withdrawn at once and replaced from the master. The kit in the IT office safe is checked at the same time, and its seal is recorded. A missed quarterly check is reported at the monthly service meeting.

27.7 Sign-off

Renata and the IT manager approve the kit for operational use.

The sign-off records that the security analyst accepts the kit as fit for evidence collection and that the IT manager accepts its cost and operational impact. Both signatures are dated and stored with the validation report. Any later change that triggers revalidation needs a new sign-off before the changed kit is used. Neither signature can be delegated to the student team, which built the kit and so cannot approve it independently.

User feedback

After deployment, first responders comment on the kit after each use. The first real use, on a suspicious server alert, took 50 minutes; the operator suggested moving the memory step to the top of the quick card, which the team does. Feedback is logged and reviewed before each kit update so that small frictions are removed over time.

Worked example

The quarterly check finds one depot kit drive's tool list hash differs. The drive had been reformatted by mistake and reloaded with an older version. It is replaced from the master, and the depot copy is moved to a sealed envelope with the hash written on the seal.

Synthetic case. The deployment is invented.

Errors and limits

Validation on five machine types cannot cover every configuration; record what was covered.

Exercises

  • EX079 — Production validation. How does production validation avoid personal data?
    Show marking criteria
    Rubric: 3 = test accounts, planted synthetic files; 2 = partial; 1 = uses real data; 0 = none.
  • EX080 — Old desktop. What failed on the oldest desktop, and what followed?
    Show marking criteria
    Rubric: 3 = missed log path (OS version); note added, replacement scheduled; 2 = partial; 1 = vague; 0 = none.
  • EX081 — Depot drive. What did the quarterly check find, and what changed?
    Show marking criteria
    Rubric: 3 = reformatted drive with old version; replaced, sealed envelope with hash; 2 = partial; 1 = vague; 0 = none.

Synthesis

Validate in the real environment, record coverage, monitor kit integrity and revalidate on change.

Continue studying — chapter 27 of 30

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →

Worked answers

EX079. It uses test accounts and synthetic files planted for the tests, never staff or residents' data.

EX080. Triage missed one log path because the old model ran a different OS version; the procedure gained a note and the model was scheduled for replacement.

EX081. A depot drive had been reformatted and reloaded with an older version; it was replaced from the master and stored in a sealed envelope with its hash on the seal.