Export Review — Selecting, Not Deleting

In one line

An export summary is not made by deleting from the original; it is made by starting from an empty file and copying over only the facts you need, and that difference separates incidents from no incidents.

Why this was needed

Finding the cause inside an air-gapped network does not finish the job. The result has to be delivered to the headquarters development team so a fix can be built, and a fix has to exist before the next import can happen. But to deliver it, it has to pass a review, and in the review a person judges "is this allowed to go out?"

There are two kinds of failure here.

Failing by keeping too much. You try to export the log as is and it is rejected. A log contains accounts, employee IDs, internal hostnames, internal IPs, and file paths. Each one looks trivial, but collected outside they become the organization chart and the network structure. A rejection is the better outcome. The worst case is when it passes and is discovered later.

Failing by deleting too much. If worry takes over and you smear out numbers and codes as well, the receiving side cannot judge anything. A summary that says only "this looks like a performance problem" is the same whether it goes out or not. Then you end up explaining again over the phone, and explaining over the phone ends up putting the deleted values into words. The control becomes powerless and no record remains.

How it works

The way to avoid both at the same time is to change direction.

Pick, do not delete. If you open the original and delete the sensitive parts one by one, one thing you only half-deleted is certain to remain. No matter how many times you reread, that remaining one is invisible — people cannot read a document they believe they have already processed the way they would inspect it. Instead, if you start from an empty file and copy over only the facts needed for judgment, whatever you did not copy was never there in the first place.

First count what is in it. Before picking, make a list by category. 8 accounts, 8 employee IDs, 3 hostnames, 3 internal IPs, 1 contact, 4 worker identifiers. This list becomes the basis for the self-check later. If you start without a list, you miss an entire category, and because you are not looking for the missed category, it stays invisible to the end. And the review target is not just one log file — as with a contact person's details sitting on one line of the configuration change log, another category hides in another file you were looking at together.

Verify with a list, not with your eyes. Check the summary against the list of forbidden tokens extracted mechanically from the original, and see whether the match count is 0. The check has to use fixed strings — if the list is read as a regular expression, a dot becomes any character and catches the wrong places or, conversely, misses them.

And that list itself does not go out. The forbidden token list is a file that collects nothing but sensitive values. If you leave it in the export directory, the most dangerous file of all is the one that goes out. This really happened, and that is why the rule arose that the export directory holds only what is going to be reviewed.

What it looks like in the field

The criterion for what to keep is "without this, can the receiving side not make a judgment?" Keep the error code — without it you do not know what kind of failure it was. Keep the counts — without them you do not know the scale. Keep the configuration change identifier — it is the evidence that pointed to the cause. On the other hand, which account sent that request is unrelated to the cause. The same goes for node names. The fact that "it occurred on all 3 machines" is enough for judgment, and the names of those 3 machines are not needed.

Integrity goes out too. There has to be a way to confirm that the file that was reviewed and the file that actually goes out are the same. Write the SHA-256 of the summary on the request form and place a hash file alongside it. If you changed the summary by even one character, you have to recompute the hash too — I once went through review twice for missing this one line.

The request form is also a document that goes out. It happens surprisingly often that the summary is clean but the request form has a contact person's details written in it. Run the check against every file that goes out.

What you will do in the next lab

You turn the facts obtained in the previous investigation into an exportable form. Count by category, write the summary starting from an empty file, check it against the 27 forbidden tokens extracted from the original and confirm 0 matches, and write an export request form with six sections: purpose, inclusions, exclusions, verification, integrity, and approval. Finally, you confirm that the export directory contains not a single file that is not a review target.