A Tool's Output Is Not a Validated Finding

“The tool flagged it, so it goes in the incident report as fact.”

Let me stop you before that sentence acquires a signature block.

A tool’s output is not a validated finding.

An EDR verdict is a finding.

A SIEM correlation hit is a finding.

A vulnerability scanner’s CVE match is a finding.

A keyword count from a forensic suite is a finding.

Each one is also the output of a method.

Every method has a way of being wrong that is specific to how it works.

That is not a scandal.

It is the reason the method has a name.

The problem starts when the output skips a step and lands in an incident conclusion as if the method had vanished.

Somebody gets dismissed.

A breach gets disclosed.

A regulator gets a notice.

And nobody can say which method produced the sentence everything rests on, or whether anything else agreed.

Digital forensics had this argument years ago.

It learned the answer from a wrong count put in front of a jury, and a conviction that did not stand.

The answer was not “trust better tools.”

It was: test the tool by version, reproduce the result with an independent one, and be able to state the method’s error behaviour to someone hostile.

The rest of security has mostly not been asked to meet that standard, because most of it never goes near a courtroom.

That is a statement about the audience.

Not about the reliability.

1. “But It Is a Market-Leading Tool.”

Market share is not a tested assertion.

NIST’s Computer Forensics Tool Testing program, CFTT, run from NIST’s Information Technology Laboratory with the Department of Homeland Security’s Cyber Security Division, has been testing forensic tools since 2002.

It started with dd and Safeback.

It does not certify tools as generally good.

It tests narrow, published assertions against a specification, such as the Digital Data Acquisition Tool Specification and its test-assertion plan.

Then it publishes the results, including where a tool’s actual behaviour diverges from what it claims.

Look at how the reports are addressed.

EnCase Forensic v8.05.00.182, tested August 2018.

FTK Imager v3.4.2.6, tested October 2016.

The Tableau TX1 hardware imager, April 2023.

Falcon-NEO2, February 2024.

Not “EnCase.”

Not “FTK.”

A version, a function and a date.

What that buys an examiner is the ability to say, under cross-examination, that this version of this tool was independently tested against a published method for this function.

Rather than trusted because the vendor is well known.

Now apply the same question to your stack.

Which version of your EDR agent produced the verdict?

Which function was relied on?

Has anyone outside the vendor tested that function in that version?

For most security tooling, the honest answer to the last question is no.

That doesn’t make the output wrong.

It makes its reliability an assumption, and an incident report should say so.

And the most dangerous tool in the chain is often not the market leader.

It is the in-house script someone wrote to count things.

2. “But the Vendor Publishes Its Detection Accuracy.”

Accuracy of which method?

Security tools decide something is malicious in one of a small number of ways, and each fails in its own direction.

Signature-based detection matches a byte sequence, file hash or packet pattern against a database of known-bad entries.

When it matches, it is close to unambiguous.

It cannot flag anything that does not match an existing entry.

That is not a tuning problem.

It is the method.

Behavioural or anomaly-based detection models normal activity and flags deviations.

It can catch something with no prior signature.

It also flags legitimate but unusual activity when the baseline is poorly tuned, and intrusion-detection literature puts the consequence bluntly: “the number of real attacks is often so far below the number of false alarms that the real attacks are often missed and ignored.”

ML-based detection, as vendors currently use the phrase, is usually a refinement of the behavioural category: a classifier trained on labelled samples rather than a hand-built statistical baseline.

Vendors market “AI-powered” and “behavioural” somewhat interchangeably.

Ask which one you bought.

Most production tools run signature and behavioural detection together, precisely because each covers the other’s blind spot.

Which means any single verdict came from one of them, and you need to know which.

Then ask where the accuracy number came from.

A controlled evaluation scores a product against a fixed, simulated attack chain.

Field data aggregates whatever a deployed population produced across many unrelated environments.

The two rarely agree.

Field false-positive rates run consistently worse than benchmark scores, because a real environment stacks every deployed tool’s error on top of every other tool’s.

Deployment mode moves the number too.

An unauthenticated vulnerability scan is documented as prone to a high false-positive rate and unable to confirm software versions with confidence.

A credentialed scan of the same host reads installed software directly and is materially more accurate.

Same product.

Different method.

Different finding.

“Low false-positive rate” without a named method is not a measurement. It is a mood.

3. “But We Are Not Going to Court.”

Fine.

Borrow the court’s questions anyway, because they are good questions.

In US federal courts and most US states, expert testimony, forensic testimony included, is assessed under the Daubert standard.

It comes from the Supreme Court’s 1993 decision in Daubert v. Merrell Dow Pharmaceuticals, Inc., refined by General Electric Co. v. Joiner in 1997 and Kumho Tire Co. v. Carmichael in 1999.

The illustrative factors:

Can the method be tested, and has it been?

Does it have a known error rate?

Has it been peer reviewed and published?

Is it generally accepted in the field?

The Court explicitly said these are not a definitive checklist.

Federal Rule of Evidence 702 adds that the testimony must rest on sufficient facts, reliable principles and methods, and a reliable application of those methods to the facts of the case.

A minority of states, including California, Illinois, New York and Pennsylvania, still apply the older Frye standard, which asks only whether the technique is generally accepted.

A finding built to survive Daubert will survive Frye.

Not necessarily the other way round.

Now read those factors as an internal reviewer.

Tested, error rate, independent review, reliable application to these facts.

That is exactly what a finding needs before it ends someone’s employment or starts a disclosure clock.

Daubert governs expert testimony in court, not an internal investigation.

My point is narrower.

The questions a court would ask are the questions the person on the receiving end is entitled to ask.

And the finding may well go to court later, when the dismissed employee’s lawyer arrives.

4. “But Our Logs Are Hashed and Immutable.”

Good.

That settles whether the data changed.

It does not settle whether the program reading the data counted correctly.

In the 2011 Casey Anthony trial, prosecution witness John Dennis Bradley testified, from his own custom software, that the family computer had been used to search for “chloroform” 84 times.

After the verdict, he disclosed that the figure came from a bug in his program.

The actual count was one.

Overstated by 83.

Eighty-four times the true number.

Prosecutors were reportedly preparing to correct the record when the verdict came in on 5 July 2011.

Preserve that data perfectly and hash it every hour, and the count is still 84.

The error lived in the interpreter, not the evidence.

That tool had not been through anything resembling CFTT-style testing before its output became testimony.

Integrity of the input and correctness of the analysis are different properties.

Immutable storage buys the first.

Nothing in your log pipeline buys the second by default.

The distinction courts draw on integrity helps here.

In United States v. Bonallo, the court held that “the fact that it is possible to alter data contained in a computer is plainly insufficient to establish untrustworthiness.”

The standard is a checkable process, not the theoretical impossibility of error.

That cuts both ways.

Nobody expects your detection engine to be infallible.

They are entitled to expect that its output was checked.

5. “But Running a Second Tool Doubles the Work.”

On every alert, yes.

On the handful of findings that will cost someone something, it is the cheapest insurance you will ever buy.

The accredited-practice mitigation for a single examiner with a single tool is dual-tool verification.

Run the same analysis, a keyword search, a deleted-file recovery, a hash comparison, through two independently developed tools, and confirm they agree.

It works as a stand-in for peer review where no external publication process exists for one case’s findings.

It is the check that would have caught Bradley’s count, because a second, independently written program is unlikely to share his specific bug.

Be precise about its limit.

It will not catch a defect both tools share.

Two products that parse the same artefact with the same library, or apply the same signature feed, can agree because they are wrong the same way.

Independence is the property. The second tool is only the mechanism.

Laboratories accredited under ISO/IEC 17025, administered in the US through bodies such as ANAB, are assessed on whether their processes “consistently produce valid results.”

Not on the brilliance of any single examiner.

That is the same question from the other side.

Can this result be trusted because of who ran it, or because of a process that does not depend on any one person or tool being right?

6. “But the Analyst Has Years of Experience With It.”

Experience with a tool is not knowledge of what the tool cannot see.

Take the 2007 prosecution of Connecticut substitute teacher Julie Amero, over pornographic pages on a computer.

The investigating detective relied solely on ComputerCop Professional, a consumer tool that could not determine whether a page had been visited intentionally or accidentally.

He showed the jury a red-coloured link as proof of deliberate clicking.

The colouring was ordinary HTML formatting.

The page in question had never been visited.

Nobody checked the machine for malware before concluding she had acted deliberately.

Independent examination later found spyware that had been redirecting the browser without user input since 14 October 2004, five days before the incident.

She was convicted on 5 January 2007.

The conviction was vacated on 6 June 2007, and she ultimately pleaded to a lesser charge in November 2008.

Nobody tampered with anything.

The method was incapable of answering the question it was asked, and it was applied with enough confidence that a jury convicted on it.

Every SOC has this question in a different costume.

The account did it.

The user clicked it.

The admin ran it.

A tool records that something happened under an identity.

Whether a person intended it is a separate finding, and the tool that recorded the event usually cannot make it.

Some intrusions are stealthy enough to leave nothing on disk at all, so a tool that only reads the disk will report a clean machine with complete sincerity.

Rule out malware and automated activity before you attribute intent.

7. No, This Does Not Mean Tool Output Is Worthless.

It isn’t.

Most alerts are triaged, not litigated.

Forcing every one through version checks and independent reproduction would stop a team doing anything else.

A signature hit is a legitimate reason to look.

A behavioural alert is a legitimate reason to look harder.

A CFTT report for the exact version and function you relied on is a real point in your favour.

The line is consequence.

A finding that will carry a dismissal, a disclosure or a regulator’s notice has to say which method produced it and whether an independent method agreed.

Everything below that line can keep moving at triage speed.

This is a tier, not a tax.

8. What You Should Actually Do

Mark consequential findings. Any finding that will carry legal, HR or disclosure consequences gets flagged when it is written, not when someone objects.

Record the method with the finding. Tool name.

Exact version.

The function relied on.

Detection method: signature, behavioural or ML.

Authenticated or unauthenticated, where that applies.

Reproduce it with an independently developed tool. Not a second product built on the same engine.

If you cannot reproduce it, say so in the finding.

Check for a published test report. Does this tool version have a CFTT report for this function?

If not, the report should say the tool’s behaviour was assumed, not tested.

Treat in-house scripts as untested tools. Because they are.

Rule out malware and automated activity before any finding about what a person intended.

Measure false-positive rates in your own environment. Vendor evaluations and field data rarely agree, and yours is the only field that matters to this finding.

Keep contemporaneous custody records for any evidence that may leave the team. A missing record is the one failure no amount of analytical rigour repairs.

9. The Model Is Not Complicated.

A tool emits a verdict. A finding states a method, a test and an agreement.

Signature detection sees what it has catalogued.

Behavioural detection sees deviation from a baseline someone tuned.

A forensic suite sees what its parser was written to read.

A custom script sees whatever its bug allows.

Each is useful.

None is self-validating.

Tool versions, test dates and which US states apply which admissibility rule are dated evidence.

Check them before you rely on them.

The principle does not date.

A result is as trustworthy as the tested behaviour of the tool that produced it, and the independence of whatever confirmed it.

The tool flagged it.

Good.

Now find out what that means before you write it down as fact.