← All articlesMethod

A log qualifies like a rumour

Two habits that ignore each other. In open-source work, the starting assumption is that anything found online must be tested before it’s believed. In digital investigation after an incident, the assumption often runs the other way: a technical artefact — a log, a registry entry, a timestamp — tells the truth, because it comes from a machine rather than a person.

Both habits are justified in their own domain. They become a problem the moment they’re treated as two separate worlds with two different standards of proof. A technical artefact can be forged, moved, or misread — just like a claim found online. The question doesn’t change depending on the object in front of you. It’s the same question, asked twice: where does this come from, and what can I actually rely on to believe it?

We apply the same protocol to both: four questions, the CAMO method — Context, Age, Multiplicity, Origin.

Context: who produced this, and why

A post accusing a company was published by whom, under what circumstances — a competitor, an anonymous account created the day before, a dissatisfied client? Content doesn’t read independently of who produced it.

A system log follows the same logic. Was logging correctly enabled at the time of the event? Did the system actually hold the access rights it’s credited with? Could an administrator account have altered its configuration before or after the incident? A log isn’t neutral just because it’s technical — it too carries the conditions of its own production.

Age: is it still valid today

A screenshot recirculating online can be years old and presented as recent. That gap changes the entire meaning of the information.

A timestamp sets exactly the same trap, more quietly: it presents itself as a fact, when it is itself a claim to be checked. A poorly synchronised system clock, a misconfigured time zone, a deliberate manipulation of system time before an intrusion — and the most precise-looking timestamp becomes misleading.

Multiplicity: is it confirmed independently

Ten posts repeating the same accusation add nothing if they all copy a single original source. Repetition is not confirmation.

A firewall log, an endpoint log and a network capture describing the same event genuinely confirm each other — provided they come from truly distinct collection points. Three logs pulled from a single compromised machine are not three independent sources: they share the same weakness.

Origin: can it be traced back

Can the original document, the original post, the person who produced it be found — or is there only a copy of a copy, with no way to know what happened to it in between?

A digital artefact raises the same requirement under a different name: chain of custody. Can this file be linked to the system that actually produced it, through a documented collection method — or is it a copy passed through a channel no one controls, possibly altered along the way?

What this changes in practice

An engagement rarely involves only one type of object. A partner check sometimes comes with a technical review. An incident response often comes with open-source research into the likely origin of the attack. Without a shared framework, these two strands produce two levels of confidence that can’t be compared — one says “80% reliable,” the other says “the log doesn’t lie,” and no one can really arbitrate between them.

By asking the same four questions on both sides, every element of the file — whether it comes from a public post or a compromised system — receives the same verdict, on the same scale: established, probable, uncertain, or not established. A mixed file becomes a coherent one.


A partner check, an incident response, or both at once? Contact us to discuss it. The full method is published on our CAMO page.

← All articles