A question that comes up after almost every serious incident is how the attack succeeded when antivirus was installed, licensed, current and reporting healthy. It is a fair question and it deserves a technical answer rather than a reassurance, because the answer explains a great deal about where security spending should sit.

The short version is that antivirus was designed for a problem that is no longer the main problem. It has not stopped working. The nature of what it is being asked to stop has changed.

What antivirus actually does

Traditional antivirus identifies malicious files. It maintains a database of signatures, being characteristics of known malicious software, and it examines files against that database, quarantining anything that matches. Modern products supplement this with heuristics that assess whether an unknown file resembles known malicious families.

This model works well against its intended target, which is a malicious file arriving on a system, and it continues to be worth having. Its structural limitation is contained in its premise, because everything about the approach assumes there is a file to examine.

The problem: attacks that introduce no file

A substantial proportion of current intrusions use the tools already present on the operating system rather than introducing anything new. Every Windows environment ships with legitimate administrative utilities capable of downloading content, executing code, moving data and modifying configuration, and those utilities are signed by the vendor, expected on every system, and used continuously by administrators for entirely legitimate purposes.

An attacker using them introduces nothing that could be recognised as malicious, because nothing malicious is present. The scripting environment executing a command is the same environment your own administrators use daily. There is no file to quarantine, no signature to match, and from the perspective of a file scanner nothing has occurred.

The same applies to attacks that operate entirely in memory without writing to disk, and to the largest category of all, which is an attacker using valid stolen credentials. When somebody signs in with a legitimate username and password and then performs actions that account is permitted to perform, there is nothing anomalous at file level to detect. The account is real and the permissions are correct. Only the person is wrong.

What endpoint detection and response changes

Endpoint detection takes a different approach. Rather than asking whether a file is known to be malicious, it observes what is happening on the system and asks whether the behaviour makes sense.

A document opening a scripting environment which then makes an outbound network connection is a sequence with no legitimate explanation, regardless of the fact that every component in it is a signed and expected part of the operating system. An administrative account accessing a large number of file shares it has never touched before, at three in the morning, is a pattern rather than a file. A process reading the memory of the system authentication service is behaviour that has one purpose.

Because the detection is behavioural rather than signature based, it identifies attacks that introduce nothing recognisable, which is precisely the category that antivirus cannot address by design.

The second capability is investigative. Endpoint detection retains a record of what executed, what connected where, and what was accessed, which means that after an incident it is possible to reconstruct what actually happened rather than inferring it. Businesses relying on antivirus alone frequently cannot establish how an attacker got in or what they reached, which makes both remediation and any subsequent notification obligation considerably harder.

The part that is usually missing

Here is the qualification that matters more than anything above, and it is the reason a business can deploy an excellent endpoint product and remain exposed.

Endpoint detection generates alerts, and a meaningful number of them require human judgement, because behaviour that is suspicious in one context is routine in another. An administrator running a credential tool during legitimate maintenance produces the same signal as an attacker running it during an intrusion. Distinguishing between them requires somebody who knows what your environment normally looks like.

Without that person, the product becomes an expensive log. The alerts accumulate in a console, the genuinely significant ones sit alongside the routine ones, and the intrusion proceeds while the evidence of it is recorded faithfully and read by nobody. This is the most common configuration we encounter, and it is worse than it appears, because the business believes itself to be protected on the basis of a product it has correctly purchased and correctly deployed.

The response half of the term is a human capability as much as a technical one. Isolating a compromised device within minutes requires somebody available and authorised to make that decision at the moment it needs making, which in practice means outside business hours, because that is when it will need making.

What to do with this

Three questions worth putting to whoever currently handles your endpoint security.

Is what we have signature based or behavioural, meaning would it detect an attack that introduces no file. Who examines the alerts it generates, and during what hours. And if a device were determined to be compromised at two on a Sunday morning, who isolates it, and how long would that take.

The answers will tell you whether you have bought a product or a defence.

Siyaxhuma delivers endpoint detection and response as a managed service, meaning the alerts are examined by our team and isolation is performed by us. Get in touch to discuss coverage for your environment.