ETMD EP Practitioners common mistakes
ETMD EP Practitioners · Understand the traps and how to avoid them.
Treating an alert as a confirmed infection and immediately recommending host isolation or reimaging before checking whether the triggering process is a known administrative tool (PsExec, remote WMI, backup agent) running from an expected parent and path.
Candidates pattern-match on the detection name (for example 'suspicious service creation' or 'credential dumping behaviour') and skip the first triage step of validating process lineage, signer, user context, and command line, so they escalate benign administration as a breach.
What to do instead
Before any containment recommendation, walk a fixed evidence checklist: process name and full path, parent process, digital signer and signature validity, command line, executing user and privilege level, and whether the same activity appears on peer hosts. Only escalate when at least two independent indicators conflict with the expected administrative pattern.
Writing exclusions by filename or partial folder path (for example excluding 'backup.exe' or 'C:\Apps\') to clear a noisy detection, without tying the exclusion to hash, signer, and full path.
Exclusions are the fastest way to silence an alert, and candidates optimise for the immediate noise reduction rather than for the security consequence, forgetting that a filename exclusion can be satisfied by malware that simply renames itself.
What to do instead
Apply a tiered exclusion standard: prefer certificate/signer plus publisher, then SHA-256 hash, then full canonical path with no wildcards at the leaf. Require a documented business justification, an owner, an expiry date, and a peer review for every exclusion; reject any exclusion whose scope is broader than the exact object that generated the false positive.
Configuring prevention policy in isolation and never verifying that the endpoint actually received it, so the candidate reports 'policy applied' when the agent is in a stale, unenrolled, or degraded state.
Candidates treat the management console's policy assignment as equivalent to enforcement on the host, and they do not habitually check agent health, last check-in time, policy version on the endpoint, or module status.
What to do instead
After any policy change, verify on a representative endpoint: agent service running, last communication timestamp within the expected interval, applied policy revision matching the console, and each protection module reporting enabled and updating. Include a small test population in every rollout and confirm the change through a triggered test action rather than console state alone.
Building a hunt that only searches for a single IOC such as one file hash or one IP address, then declaring the environment clean when that search returns nothing.
Candidates confuse indicator matching with hunting; they anchor on the artefact named in the scenario and never generalise to the behaviour, so a trivial attacker change (new hash, new C2 domain) defeats the entire hunt.
What to do instead
Structure every hunt as behaviour first: identify the ATT&CK technique, express it in telemetry (for example process creating a service with a binary in a user-writable directory), then add indicator enrichment as a secondary filter. State the hypothesis, the data sources queried, the time window, and the expected false-positive population before running the query.
Answering containment questions by isolating every host in the same subnet or business unit 'to be safe', rather than scoping to confirmed and probable compromise based on evidence.
Candidates fear under-containment more than over-containment and have not internalised that mass isolation is itself an availability incident with clinical or revenue impact, so they default to the broadest action.
What to do instead
Use an explicit scoping model: confirmed compromised, suspected (shared credential, shared loader, or direct network link to confirmed), and monitored. Contain confirmed and suspected hosts, place monitored hosts under enhanced logging, and document the criteria used for each tier. Justify any action beyond the suspected tier by naming the specific evidence that requires it.
Misreading a detection's severity label as its risk, treating every 'high' severity alert as urgent and every 'low' or 'informational' alert as ignorable.
Candidates conflate static detection severity with contextual risk and skip asset criticality, user privilege, exposure, and whether the technique is a precursor or a payload, so triage priority is set by label rather than by impact.
What to do instead
Rank by combined risk: detection confidence, asset criticality and data sensitivity, account privilege, whether the activity is post-exploitation versus opportunistic, and current threat intelligence. Document the ranking rationale in the ticket and escalate on that basis, not on the vendor severity field alone.
Describing ransomware or worm propagation purely as 'the malware spreads' without naming the specific propagation vector, the telemetry that would show it, and the control that would break it.
Candidates memorise the threat category label but not the mechanics, so they cannot connect a threat-landscape question to a defensible control decision or to the log source that would detect the behaviour.
What to do instead
For each major threat family, be able to state the initial access vector, the lateral movement mechanism (SMB, RDP, remote service creation, credential reuse), the primary telemetry (network connection logs, authentication events, service creation, file writes), and the mitigating control (segmentation, SMB signing, least privilege, MFA on remote access). Practise mapping each family to at least one detection and one prevention control.
Presenting compliance evidence as a screenshot of a console dashboard rather than as a reproducible control statement with scope, population, sample, and result.
Candidates equate 'the dashboard is green' with 'the control is operating', and they do not practise translating operational data into the assertion-plus-evidence form auditors and regulators expect.
What to do instead
For each control, write the assertion, the population covered, the sampling method, the measurement period, the result with exceptions listed, and the evidence location. Where a dashboard is cited, attach the underlying query and the export date so the figure can be regenerated. Report exceptions and remediation status rather than omitting them.
Designing a tuning change that reduces noise by disabling an entire detection rule or lowering its sensitivity globally, instead of narrowing the rule's conditions.
Candidates respond to alert fatigue with the simplest lever available, and they do not consider that disabling a rule removes coverage for the malicious case along with the benign one.
What to do instead
Tune by adding conditions rather than removing the rule: constrain by signer, path, parent process, user group, or command-line pattern, and where suppression is unavoidable, scope it to a specific host group or time window with an expiry. Record before-and-after alert volumes and confirm with a simulated malicious test that the rule still fires on the true positive case.
Reporting operational metrics such as total alerts closed or agents deployed without denominators, trends, or definitions, so the number cannot be interpreted or compared across periods.
Candidates report activity volume because it is easy to extract, and they do not define the metric (what counts as an alert, when the clock starts for mean time to respond) or normalise it against fleet size and alert volume.
What to do instead
For every reported metric, state the definition, the numerator and denominator, the measurement window, and the data source. Pair volume metrics with quality metrics such as true-positive rate, false-positive rate, mean time to detect, mean time to contain, and percentage of endpoints with current policy and healthy agents. Show period-over-period trend and note any change in definition that affects comparability.