Deciding before you know

An executable lands on a laptop at nine in the morning. It arrived in a mail attachment, a download or a memory stick, nobody in the organisation has seen it before, and it is about to start. The agent on that machine has no history to work from and milliseconds to act in, and doing nothing is also an act. Every endpoint product answers that one question, and each family of answer sends a different bill.

The two ways to be wrong

The decision has two error directions, and only one of them has a complainant. Allow the file wrongly and ransomware encrypts under the account of the person who opened it. Block the file wrongly and a build script or a payroll utility stops working, and a named user opens a ticket within the hour. The wrong block announces itself and the wrong allow does not, so tuning drifts towards permitting.

Refusing everything unrecognised removes the wrong allow and maximises the wrong block. That is why default deny appears in more written policies than in running configurations. The three families of answer are three ways of arranging when the decision gets made. Detection decides at the moment of execution. Allow-listing decides in advance, in a list somebody maintains. Containment declines to decide at that moment and arranges for the answer not to matter yet.

Something underneath this has shifted. When a binary nobody had seen before was an unusual event, treating the unrecognised as an exception was a sound design, and an engine could be tuned on the assumption that familiar code was the normal case. Machines that write, rewrite and repack code have made an unfamiliar binary cheap to produce, and cheap production erodes that assumption. This does not make detection wrong. It moves the arithmetic, because the penalty for guessing is paid more often as the share of unfamiliar code rises, and a design that runs the unknown where it can reach nothing gains ground without having changed.

The same machinery works for the defender. It reads the alert queue, groups scattered events into one incident and drafts the triage note an analyst used to write line by line. Both directions moved. The moment in the opening paragraph did not, because it arrives before anybody knows anything.

What a test score asserts, and what it does not

Buyers compare products on independent lab results, because a lab assembles sample sets no buyer can build. The headline number is narrower than it reads.

AV-Comparatives writes in its Real-World Protection Test methodology that a perfect result "only demonstrates that it has protected against all the particular samples in this individual test/section". The same document defines protection as a state rather than an action, meaning the system is not compromised and there are no system changes. A product that lets a file execute and then reverses what it did is scored on the same line as one that never let it start.

The rest of the score measures the other error direction. AV-Comparatives runs its false alarm test in two parts, browsing around a thousand popular domains and installing around a hundred applications from download portals, and products with above-average false alarms have their award downgraded. AV-TEST splits its result into three categories, and its Usability category exists to measure "whether and to what extent the use of tested products adversely affects the usability through false alarms".

Ask for the false alarm figure from the same run as the protection figure.

Allow-listing moves the work rather than removing it

Permit what is on the list, refuse everything else.

NIST SP 800-167, the Guide to Application Whitelisting, is candid about what the list costs to keep. If the list is built on cryptographic hashes, a patched binary carries a different hash, so patch day converts approved software into unknown software. NIST writes that this "may cause problematic delays for organizations that apply patches quickly" and that "patched software may be seen as unknown software and prohibited from running."

The same publication asks organisations to expect dedicated staff maintaining the list, on the same footing as running enterprise antivirus. For ordinary managed estates it asks for a risk assessment weighing the security benefit against the possible negative impact on operations, which is why default deny tends to stay inside the policy document.

NIST also names the category the argument turns on. A graylist holds entities that have "not yet been established as benign or malicious", and one documented way of handling it is to prompt the user to accept or reject each execution. That hands the judgement to a person who has neither the information nor the time to make it.

Containment answers by not answering yet

The third family lets the unrecognised file execute inside a container whose writes do not reach the real disk, the real registry or the user's data. The file behaves exactly as it intends and changes nothing outside it. The verdict arrives after the behaviour has been watched, so nothing was guessed at the moment of execution and the user is never asked.

The honest accounting has three lines. This covers code arriving as an unrecognised object, so an intruder who signs in with a stolen administrator password and drives the scripting tools already installed presents nothing to contain. That is why recording of process, file and network activity runs in the same agent, and somebody still reads it. An in-house utility that legitimately needs to write behaves differently until its verdict lands, so compatibility work moves into the container. And deferring a decision is not deleting it. The verdict pipeline has to produce verdicts, and a person owns that queue.

CrowdStrike Falcon, SentinelOne and Microsoft Defender for Endpoint decide whether a file is malicious and act on the decision, and the lab methods above measure how well they decide. Containment is answering a different question, which is what the machine looks like while nobody knows. A single protection percentage compares one of those questions.

The half of the purchase that is a rota

Endpoint security is rarely bought as software on its own. The requirement document says twenty four hour monitoring, and that line is commercial before it is technical, because it decides who can bid.

The UK National Cyber Security Centre, in its guidance on designing a SOC operating model, states that "maintaining a 24/7 SOC will require significantly more staff than a 9-5 operation with out-of-hours on-call". Coverage is a staffing problem in the clothes of a technical requirement, and no automation in the triage queue signs a shift sheet.

That clause obliges somebody to have three things.

• A rota deep enough that no shift depends on one person's leave
• A decision on who owns the verdict queue at three in the morning and what they may do
• A contract sentence saying whether the vendor, the partner or the customer staffs that rota

A buyer with no security team and a partner with no operations centre read the same clause from opposite sides, and headcount settles it either way.

The product we carry in this area

Xcitium is the endpoint product in this portfolio, and it belongs to the third family. Unrecognised code runs inside a container with no route to the disk, the registry or the data, under the name ZeroDwell Containment, while detection and response records process, file and network activity for the investigation afterwards. The monitoring can be bought alongside the platform, through managed detection and response, managed threat hunting and guided security operations, which is how a buyer answers the rota clause without hiring first. Certifications from MRG Effitas, AVLAB and AV-TEST are published, and a free and open edition, OpenEDR, can be deployed before a purchase order exists.