TT Lab
Get started
Learn Learning paths Courses

Air-Gapped Sites — Defence and Government

Vulnerability Response on a Frozen Configuration, and Handover

Continue in TT Lab

Goal

In a certified configuration, determine the vulnerabilities that cannot be upgraded and leave the basis for mitigation in a document, find the audit violations in the overnight work log, and complete a handover package that the next person can read and follow without the internet.

Why it matters

The moment you apply the latest patch to a certified configuration, it is no longer the certified configuration, and recertification takes months. So here, responding to a vulnerability often ends not with an update but with a mitigation and its documentation. A mitigation leaves the version number unchanged, so from outside it is indistinguishable from having done nothing, which makes leaving a record that you made a judgment itself the work. An audit trail has the same nature — it is not something you look for after an incident but something you set up to be left before the work, and what was not left will not turn up no matter how well you search.

Steps

  1. With python3, create baseline.json (10 components), advisories.json (8 advisories), worklog.csv (14 tasks), and window.txt in /root/handover/.
  2. In /root/handover/impact.csv, determine and write whether each advisory has an impact. Split versions on the dots and compare them as numbers.
  3. In /root/handover/mitigation.md, write a table of the action classification, basis, and reassessment point for the affected items.
  4. In /root/handover/freeze.txt, write the certification number, the SHA-256 of the configuration list, the number of frozen and changeable components, and the number of frozen components that are affected.
  5. In /root/handover/audit-noapproval.csv, extract the tasks executed without an approval record, keeping the original lines as they are.
  6. In /root/handover/audit-selfapproved.csv, extract the tasks where the executor and the approver are the same.
  7. In /root/handover/audit-window.csv, extract the tasks outside the work window, and in /root/handover/audit-summary.txt, write the three counts and the actual number of violating tasks after removing duplicates.
  8. In /root/handover/runbook.md, write a seven-section handover procedure.
  9. Close the package with /root/handover/HANDOVER.sha256 and /root/handover/index.md.

Notes

Create the configuration, advisories, and work log

With python3, create baseline.json (10 components), advisories.json (8 advisories), worklog.csv (14 tasks), and window.txt in /root/handover/.

Create four files with python3: baseline.json, advisories.json, worklog.csv, and window.txt. The values have to be fixed so that you can check one another's determinations against each other, so use the generation script as is.

Compare the configuration with the advisories to determine impact

In /root/handover/impact.csv, determine and write whether each advisory has an impact. Split versions on the dots and compare them as numbers.

If you compare versions as strings, 16.2 looks larger than 16.10 and 3.12.3 looks smaller than 3.9.20. Split on the dots and compare as numbers. A component that is not installed has no impact.

Write the mitigation and basis table

In /root/handover/mitigation.md, write a table of the action classification, basis, and reassessment point for the affected items.

List only the affected items in the table. For a component tied to the certified configuration, the action classification is mitigation and the certification number is needed as the basis. A component outside the configuration gets a patch. Attach a reassessment date to every row.

Freeze the configuration list

In /root/handover/freeze.txt, write the certification number, the SHA-256 of the configuration list, the number of frozen and changeable components, and the number of frozen components that are affected.

If you record the SHA-256 of the configuration list file, you can prevent the list from being changed quietly. frozen_affected is the number of components that are affected and whose version cannot be upgraded.

Find the tasks executed without approval

In /root/handover/audit-noapproval.csv, extract the tasks executed without an approval record, keeping the original lines as they are.

These are the lines where the approver column is a hyphen or empty. Copy the original lines as they are — if you summarize, you cannot check against the original later.

Find the tasks where two-person control was broken

In /root/handover/audit-selfapproved.csv, extract the tasks where the executor and the approver are the same.

These are the lines where operator and approver are the same. Lines where the approval field is a hyphen go into the previous step, not here — if you mix the two, both lists are wrong.

Find the tasks outside the work window and count the actual violations

In /root/handover/audit-window.csv, extract the tasks outside the work window, and in /root/handover/audit-summary.txt, write the three counts and the actual number of violating tasks after removing duplicates.

The window includes the start in window.txt and excludes the end. And the sum of the three violations is not the number of violating tasks — one task can break two of them at once, so remove duplicates with seq.

Write the handover procedure

In /root/handover/runbook.md, write a seven-section handover procedure.

You need seven sections. Do not use external links in the body, do not refer to screen captures, and write roles instead of people's names. Write commands in code blocks so they can actually be typed.

Bundle the handover package

Close the package with /root/handover/HANDOVER.sha256 and /root/handover/index.md.

Create a hash list of the eight outputs, and attach a listing document that says what is what. Do not put the listing document itself in the manifest — the cover is not part of the package's contents.