How antivirus and EDR protect endpoints

Imagine a smoke alarm, an incident notebook, and a trained response team. They solve related problems, but owning the alarm does not supply the notebook or the team. Endpoint security works similarly.

Antivirus can prevent or remediate malicious activity. EDR adds investigation and response capabilities around endpoint activity. Products often overlap: modern antivirus may use behavior analysis and machine learning as well as signatures. “AV only reads files; EDR only watches behavior” is too simple.

Four jobs, not one green tick

Prevention tries to stop an unwanted action. Collection records selected observations: a process start, a file change, a connection, or an identity. Detection evaluates those observations against rules or models. Response might notify an analyst, quarantine an item, or isolate a device, depending on policy.

These jobs need different checks. An installed agent might have outdated policy. A healthy sensor might send events that no rule evaluates. A useful alert might wait in an unattended queue. Ask where the chain works and where evidence is missing.

Static and behavioral clues

Static inspection examines an item without executing it: for example, its structure, reputation, or recognizable patterns. Behavioral analysis examines activity and relationships over time. Neither approach is a promise to recognize every threat.

Consider a fictional payroll laptop. A signed administration tool connects to a server. That event could belong to scheduled maintenance or an unexpected session. The tool name is the same; the user, timing, parent process, destination, and approved purpose provide context. This is why use of built-in tools is neither automatically malicious nor automatically safe.

Where AMSI fits

The Windows Antimalware Scan Interface lets participating applications and services ask an antimalware provider to inspect content, including content in memory. A script engine is one possible integration.

AMSI is an interface, not the detection engine itself. It does not replace endpoint permissions or guarantee coverage of every program. A useful inventory names which applications integrate with it, which provider is active, and how scanning outcomes affect the application.

Read an alert as a question

An alert identifies a condition worth evaluating. It does not by itself prove an incident. Conversely, no alert does not establish safety. Telemetry can be incomplete because of retention, collection settings, rate limits, unsupported activity, or missing devices.

For a fictional incident, put the device, account, timestamp, event source, and expected behavior together. Separate “the event exists” from “the rule matched” and “someone responded.” Use redacted evidence; logs can contain personal data or sensitive arguments.

Improve coverage without drowning people

Compare useful detections with false alarms and missed activity. A rule that catches everything by alerting on every process is difficult to operate. Tuning needs representative benign activity, a clearly defined unwanted condition, and an owner who can review the outcome.

A good improvement states the gap and the next check: “Three managed laptops were absent from the device inventory; enroll them, verify recent telemetry, and assign an alert owner.” That is more useful than calling the entire product ineffective.