TT Lab
Get started
Learn Learning paths Courses

Air-Gapped Sites — Defence and Government

An Audit Trail Is Designed Beforehand, Not Afterwards

Continue in TT Lab

In one line

Who did what and when is not something you look for after an incident but something you set up to be left before the work, and the handover document is the channel through which that design carries on to the next person.

Why this was needed

Think of the situation where, after an incident, someone asks "who changed this?" The difference between organizations that can answer and those that cannot is not investigative skill. It is a difference in what they made sure to leave before the work. What was not left will not turn up no matter how well you search.

In a controlled environment, this design consists of three things.

Approval. Every task must have an approver. An empty approval field does not mean approval was not obtained; it means we cannot prove whether it was. In an audit the two are treated the same.

Two-person control. The executor and the approver must be different. This is not because people are not trusted, but to remove the path by which one person's mistake is reflected straight into the system. Self-approval revives that path. And self-approval is often not so much a rule violation as a signal of design failure — it means the person who should have approved was not there at that time.

Work window. Work must be done within the approved time. Work outside the window is work done at a time when there was no one to watch and no one to revert it if something went wrong. Keeping to the window is not formality; it is keeping the safety net switched on.

How it works

When you check these three after the fact, you have to be careful about one thing. The sum of the three violations is not the number of violating tasks.

One task can break two of them at once. A task that someone came in alone at 3 a.m. and processed with self-approval is both "self-approved" and "outside the window." If you simply add up the counts of the three lists, this task is counted twice. If you write "11 violations" in the report, when it is really 9, you have made up 2. Reporting incidents that do not exist loses trust just as much as leaving an incident out.

So build the union by task identifier and count the number after removing duplicates. And in the report, write the three counts and the deduplicated number together. If you write only one, the reader will ask again.

승인 없음     3건 ┐
자기 승인     3건 ├─ 단순 합계 11건
작업 창 밖    5건 ┘
                    실제 위반 작업 9건  ← 두 건이 두 가지를 동시에 어겼다

What it looks like in the field

Someday the on-site assignment ends. What the next person receives that day is a few files and the absence of everything we kept only in our heads. So a handover document has to differ in three ways in an air-gapped network.

Always hand over known problems. If you do not hand over vulnerability items that have already been judged, the next person receives the same advisory and investigates from scratch. If you hand over the mitigation status and reassessment point together, those days disappear.

Give them a way to confirm that what was handed over is exactly as handed over. Attach a hash list of the outputs, and write at the very top of the document the first thing the receiving side should do. Without a means of confirmation, it is not a handover but a file delivery.

What you will do in the next lab

From 14 overnight work log entries, you find the tasks executed without approval, the tasks where the executor and the approver are the same, and the tasks executed outside the work window. Then you merge the three lists and count the actual number of violating tasks after removing duplicates — it differs from the simple sum. Finally, you complete a handover procedure written without links, with commands, and by role, and a handover package with a hash manifest attached.