Reporting

This topic’s five lessons each produced a separate number: how many items the chain broke at, how many items scope brought in, how many items order cost, how many events the drift reversed, on how many clean machines a single trace was also found. None of these is a report sentence. A report consists of claims, and each claim is an opinion, not a number, until the item it rests on is written down.

This lesson measures that mapping. A fictional twenty-claim draft is built on top of the item set from the first three lessons — the same 28 items, the same chain gaps, the same collection model. Three columns are counted separately: how many claims are directly supported by an item, how many rest on inference, and how many have no evidence at all.

• FE31. Report draft is the list of claims planned to be written at the end of the examination. The twenty claims are fictional.
• FE32. A claim is directly supported only if at least one of its basis items was collected, that item is defensible (its chain is intact, its hash matches), and it directly carries the claim.
• FE33. If a claim’s basis was collected but the item’s chain is broken, or the claim reaches the item only through inference, the claim is inference.
• FE34. If none of a claim’s basis items were collected, the claim is unsupported.
• FE35. The item set, chain gaps, and collection model are the same as the previous lessons’; since the generator seed did not change, the numbers come from exactly the same set.

Report Draft and the Mapping Rule

// forensics/report.mjs — the MODEL for mapping report claims to evidence items.
// The item set, chain failures, and collection order are the same as the model in the first
// three lessons.

const generator = (t) => { let s = t >>> 0;
  return () => (s = (s * 1664525 + 1013904223) >>> 0) / 4294967296; };
export const CLASS = {
  "network-state": [120, 45], "process-list": [240, 60], "open-handle": [300, 55],
  "session-state": [600, 70], "memory-content": [900, 420], "temp-file": [3600, 180],
  "flow-record": [86400, 240], "remote-log": [2592000, 300],
  "disk-image": [604800, 5400], "configuration": [604800, 90],
};
const D5 = ["collection", "packaging", "transit", "lab", "analysis"];
const D3 = ["collection", "transit", "analysis"], D2 = ["intake", "analysis"];
export const HOST = {
  "branch-endpoint-3": [D5, ["network-state", "process-list", "open-handle", "session-state",
    "memory-content", "temp-file", "disk-image", "configuration"]],
  "field-laptop-14": [D5, ["network-state", "process-list", "session-state", "memory-content",
    "disk-image"]],
  "collector-2": [D3, ["network-state", "process-list", "open-handle", "session-state",
    "memory-content", "disk-image", "configuration"]],
  "portal-frontend": [D3, ["network-state", "process-list", "memory-content", "configuration"]],
  "central-log": [D2, ["remote-log", "configuration"]],
  "flow-collector": [D2, ["flow-record", "configuration"]],
};
const UNPROTECTED = ["branch-endpoint-3/temp-file", "collector-2/disk-image",
  "portal-frontend/configuration"];

// The same generator sequence as the first lesson: one draw per item, one (or two) draws per
// transfer.
export function items() {
  const r = generator(20260731), list = [];
  for (const [host, [nodes, classes]] of Object.entries(HOST))
    for (const c of classes) {
      const name = `${host}/${c}`;
      r();
      let missing = 0;
      for (let i = 1; i < nodes.length; i += 1) if (r() < 0.11) { r(); missing += 1; }
      list.push({ name, host, class: c, lifetime: CLASS[c][0], duration: CLASS[c][1],
        defensible: missing === 0 && !UNPROTECTED.includes(name) });
    }
  return list;
}

// The collection from the third lesson: n people, the given order, arrival delay to remote hosts.
const REMOTE = ["branch-endpoint-3", "field-laptop-14"];
export function collect(order, n, delay) {
  const free = Array(n).fill(0), taken = new Set();
  for (const k of order) {
    const i = free.indexOf(Math.min(...free));
    const start = Math.max(free[i], REMOTE.includes(k.host) ? delay : 0);
    if (start <= k.lifetime) { taken.add(k.name); free[i] = start + k.duration; }
  }
  return taken;
}
export const ORDER = {
  "by volatility": (K) => [...K].sort((a, b) => a.lifetime - b.lifetime || a.duration - b.duration),
  "host by host": (K) => [...K],
};

// Report draft: claim -> [basis items, does the basis directly carry the claim]
export const CLAIM = {
  "an unauthorized session was opened at the branch endpoint": [["central-log/remote-log",
    "branch-endpoint-3/session-state"], true],
  "an outbound connection was established from the branch endpoint": [["flow-collector/flow-record",
    "branch-endpoint-3/network-state"], true],
  "a new process ran at the branch endpoint": [["branch-endpoint-3/process-list",
    "branch-endpoint-3/memory-content"], true],
  "the process wrote a file": [["branch-endpoint-3/open-handle", "branch-endpoint-3/disk-image"], true],
  "the written file was later deleted": [["branch-endpoint-3/disk-image"], true],
  "the item was set to run at startup": [["branch-endpoint-3/configuration"], true],
  "the temp files at the branch endpoint were cleared": [["branch-endpoint-3/temp-file"], true],
  "a connection was established to the collector": [["flow-collector/flow-record",
    "collector-2/network-state"], true],
  "a session was opened at the collector": [["collector-2/session-state",
    "central-log/remote-log"], true],
  "a process was started at the collector": [["collector-2/process-list",
    "collector-2/memory-content"], true],
  "subscriber data was read from the collector": [["collector-2/disk-image",
    "collector-2/open-handle"], true],
  "the collector's configuration did not change": [["collector-2/configuration"], true],
  "the same session was used on the field laptop": [["field-laptop-14/session-state",
    "field-laptop-14/memory-content"], true],
  "the field laptop accessed the collector": [["field-laptop-14/network-state",
    "flow-collector/flow-record"], true],
  "a file was modified on the field laptop": [["field-laptop-14/disk-image"], true],
  "a token was used at the portal frontend": [["portal-frontend/memory-content",
    "central-log/remote-log"], true],
  "the portal frontend's setting was changed": [["portal-frontend/configuration"], true],
  "all the accesses are from the same person": [["central-log/remote-log"], false],
  "data was transmitted to a third party": [[], false],
  "this same access never happened before the incident": [["central-log/remote-log",
    "flow-collector/flow-record"], false],
};

export function classify(claim, taken, items) {
  const [basis, direct] = CLAIM[claim];
  const held = basis.filter((d) => taken.has(d));
  if (!held.length) return "unsupported";
  if (!direct) return "inference";
  return held.some((d) => items.find((k) => k.name === d).defensible)
    ? "direct" : "inference";
}

The mapping rule has three inputs: whether the item was collected, whether the item’s chain is intact, and whether the item directly carries the claim. The first two were measured in previous lessons; the third is the examiner’s judgment, and it is filled in while the claim is written — if it is filled in afterward, the strength of the basis gets chosen to fit the claim.

The Class of the Twenty Claims

// forensics/mapping.mjs — the claim-to-evidence mapping and collection order's counterpart in the report.
import { items, collect, ORDER, CLAIM, classify } from "./report.mjs";

const y = (g, ...s) => console.log(s.map((v, i) =>
  (g[i] < 0 ? String(v).padEnd(-g[i]) : String(v).padStart(g[i]))).join("").trimEnd());
const K = items(), claims = Object.keys(CLAIM);
const main = collect(ORDER["by volatility"](K), 3, 600);      // three-person shift, 600 s travel

console.log(`model: ${K.length} evidence items, ${K.filter((k) => k.defensible).length} ` +
  `defensible; ${claims.length} claims in the report draft`);
console.log(`three-person shift, order of volatility, 600-second arrival: ${main.size} items taken`);

const A = [-65, 9, 8, 13, 11];
console.log("");
y(A, "claim", "basis", "held", "class", "reason");
for (const i of claims) {
  const [d, direct] = CLAIM[i];
  const held = d.filter((x) => main.has(x));
  const s = classify(i, main, K);
  y(A, i, d.length, held.length, s,
    s === "direct" ? "-" : s === "unsupported" ? "no item" : direct ? "chain" : "claim");
}

const count = (taken) => ["direct", "inference", "unsupported"].map((s) =>
  claims.filter((i) => classify(i, taken, K) === s).length);
const [d0, c0, k0] = count(main);
const chain = claims.filter((i) => CLAIM[i][1] && classify(i, main, K) === "inference").length;
console.log(`\ndirectly supported ${d0}, inference ${c0}, unsupported ${k0} (total ${claims.length})`);
console.log(`of the ${c0} claims counted as inference, ${chain} dropped because of chain gaps, ` +
  `${c0 - chain} were already inference`);

const B = [-22, 7, 9, 10, 10, 13];
console.log("");
y(B, "collection", "people", "taken", "direct", "inference", "unsupported");
for (const [name, people, delay] of [["by volatility", 3, 0], ["by volatility", 3, 600],
  ["by volatility", 1, 0], ["host by host", 3, 0], ["host by host", 1, 0]]) {
  const a = collect(ORDER[name](K), people, delay);
  y(B, `${name}${delay ? " +600 s" : ""}`, people, a.size, ...count(a));
}

model: 28 evidence items, 16 defensible; 20 claims in the report draft
three-person shift, order of volatility, 600-second arrival: 22 items taken

claim                                                                basis    held        class     reason
an unauthorized session was opened at the branch endpoint                2       2    inference      chain
an outbound connection was established from the branch endpoint          2       1       direct          -
a new process ran at the branch endpoint                                 2       1    inference      chain
the process wrote a file                                                 2       1       direct          -
the written file was later deleted                                       1       1       direct          -
the item was set to run at startup                                       1       1    inference      chain
the temp files at the branch endpoint were cleared                       1       1    inference      chain
a connection was established to the collector                            2       2       direct          -
a session was opened at the collector                                    2       2       direct          -
a process was started at the collector                                   2       2       direct          -
subscriber data was read from the collector                              2       2    inference      chain
the collector's configuration did not change                             1       1       direct          -
the same session was used on the field laptop                            2       2       direct          -
the field laptop accessed the collector                                  2       1       direct          -
a file was modified on the field laptop                                  1       1       direct          -
a token was used at the portal frontend                                  2       1    inference      chain
the portal frontend's setting was changed                                1       1    inference      chain
all the accesses are from the same person                                1       1    inference      claim
data was transmitted to a third party                                    0       0  unsupported    no item
this same access never happened before the incident                      2       2    inference      claim

directly supported 10, inference 9, unsupported 1 (total 20)
of the 9 claims counted as inference, 7 dropped because of chain gaps, 2 were already inference

collection             people    taken    direct inference  unsupported
by volatility               3       28        11         8            1
by volatility +600 s        3       22        10         9            1
by volatility               1       21         8        10            2
host by host                3       19         9        10            1
host by host                1       16         7        10            3

The result sits in two lines: of the twenty claims, ten are directly supported, nine are inference, and one is unsupported. The real information is in the line below. Seven of the nine claims counted as inference land there not because they are inherently inference, but because the chain of custody of the item they rest on is broken. The items are collected, they are on hand, their contents are read — they are not defensible. This is the report’s counterpart to the 2.6 percent blank-record-field rate measured in the first lesson: seven sentences that could have been directly supported drop one class down.

The reason column separates three defects, each with a different remedy. Rows marked “chain” are a record problem, and some fraction of them can be closed after the fact. The two rows marked “claim” are a logic problem: the sentence “all the accesses are from the same person” does not rise by adding any item, because an item shows a session, not an identity. The single row marked “no item” is a scope problem.

The table below gives collection decisions their report counterpart. Under the perfect condition — three people, the correct order, no delay — all 28 items are taken and the number of directly supported claims is 11. If the same team spends six hundred seconds traveling, that drops to 10; if the team shrinks to one person, to 8; if collection goes host by host and the team is down to one person, it drops to 7, and the number of unsupported claims rises from one to three. A single ordering decision costs four report sentences and two unanswered questions.

Claim, Inference, and What Goes Unwritten

How the three columns are written into the report matters as much as measuring them. If the class is not written down, the reader gives every sentence the same weight; an inference sentence sits next to a directly supported one and cannot be told apart from it. That distinction is the writer’s job, not the reader’s.

An inference sentence can go into the report; it cannot go in without stating that it is inference. An unsupported claim is not deleted — it moves under an “asked and unanswered” heading. That the question was asked, and why it could not be answered, carries decision weight: if it is not known whether the data left the network, writing down that it is not known is not the same thing as not writing it at all.

The items collected and the items that go into the report also differ: 28 items were collected, 22 remained on hand, 23 items were cited as a basis, and 18 of those were on hand. An unused item is not a defect, but the report’s length is measured not by the items collected but by the items mapped.

The methodology section is itself a list of items: hash values, chain-of-custody records, collection order, arrival delay, the schedule’s remaining drift. They are written so that the same result can be reproduced.

The last boundary concerns the legal context, and it is drawn in a single sentence: the examination states what the item shows, not how the act should be characterized. Characterization is another profession’s job; the moment a technical report takes its place, it opens even its correct technical part to dispute. This is also why the report’s scope, its written authorization, and the list of systems examined go on the first page.

Summary

• A report consists of claims, and each claim is mapped to the item it rests on; the mapping rule’s three inputs are whether the item was collected, is defensible, and directly carries the claim.
• In the twenty-claim draft, with 22 items, 10 claims are directly supported, 9 are inference, and 1 is unsupported.
• Seven of the 9 claims counted as inference dropped there because of chain-of-custody gaps; the items are on hand, they cannot be defended.
• The three defects have separate remedies: a chain gap is a record problem, remaining inference is a logic problem, and the absence of an item is a scope problem.
• Perfect collection yields 11 direct claims; host-by-host collection with a one-person team drops that to 7 and raises unsupported claims to 3.

Course Wrap-Up

The fourth column has no empty cell. Each of the twenty-two lessons wrote the cost of delay as a duration or an item count, and in none did it come out to zero. The course’s rule is read from this column: the output of a security operation is not the number of alerts, but the time between detection and containment; if that time is not measured, the pipeline is not considered built. The alert count measures workload; it does not prove a built pipeline.

The second and third columns are the rule’s two halves. A record that was never dropped in the first place cannot be recovered by any step; every extra step, in turn, is both an elimination and a delay. In none of the twenty-two lessons did both improve at once.

This pipeline rested on a single silent assumption, which the last six lessons used most plainly: that logs, images, and memory dumps sit on machines you can reach. The collector’s disk could be imaged; the branch endpoint could be visited. But part of the systems now run on hardware that is no longer yours; there, no image can be taken, and the first link in the chain of custody is in someone else’s hands. M24/K09 Cloud and Virtualization Security begins with exactly this question.