DLP, NAC, EDR/XDR and email security

Objective 4.5 in this course covers enterprise security capabilities. The previous lesson took firewalls, IDS/IPS and filtering; this one takes data loss prevention, network access control, EDR/XDR and email authentication from CompTIA's scope note. It is the applied lab for 4.5.

Why this matters

These four are the controls that answer the threats Domain 2 spent ten lessons describing: DLP for exfiltration, NAC for the unmanaged device, EDR for fileless malware, and SPF/DKIM/DMARC for the spoofed sender.

The email authentication trio in particular is worth learning exactly. It is three records that must agree, it is the most commonly misconfigured thing in this objective, and the exam asks about it in a way that rewards precision.

The lesson

Data loss prevention, and what it can see in each data state

DLP identifies sensitive data and controls its movement. It works by inspecting content against patterns, classifications and fingerprints — card numbers, national insurance or social security numbers, document labels applied under Domain 3's classification scheme, or exact matches against a known database.

The deployment points map onto the data states from Domain 3:

• Endpoint DLP — data in use. Watches copying to USB, printing, clipboard, screenshots and uploads from the device. The only place that sees data before it is encrypted for transit, which is why it matters more as everything moves to HTTPS.
• Network DLP — data in transit. Inspects traffic leaving the network, which requires TLS interception to see content, and otherwise sees only metadata.
• Storage / cloud DLP — data at rest. Scans file shares, databases, email stores and cloud storage for sensitive data in places it should not be, and for sharing settings that expose it.

Modes: monitor (log only), alert, block, and quarantine or encrypt. As with IPS, deploy in monitor mode first — DLP in blocking mode with untuned rules stops legitimate work within hours and gets switched off.

What DLP is bad at, which the exam does test: encrypted or compressed archives, data the user retypes or photographs, steganography, and anything outside its inspection points. It is a control against carelessness and opportunism, and a determined insider with time will get data out. That is why it is paired with behavioural monitoring and access control rather than relied on alone.

Network access control, and the device that fails the posture check

NAC decides whether a device may join the network at all, and what it may reach if it does.

The sequence: the device connects; it authenticates (usually 802.1X with RADIUS, from Domain 3); its posture is assessed — is it managed, is the OS patched, is disk encryption on, is the endpoint agent running and healthy; and then policy places it. Compliant corporate device onto the production VLAN, non-compliant onto a remediation VLAN where it can only reach patching and support, and unknown device onto guest or nowhere.

Two implementation notes the exam uses:

• Agent-based posture assessment gives detailed health but requires software on the device, so it works for managed devices. Agentless checks what can be observed from the network, which is shallower and is what covers printers, cameras and contractor laptops.
• Pre-admission control checks before access is granted; post-admission re-checks during the session, which matters because a device can become non-compliant after it joins.

NAC is the practical answer to several scenarios: an unmanaged device on the corporate network, a contractor needing limited access, enforcing patch compliance, and segmenting IoT automatically by device type. It is also the enforcement point that makes zero trust's device posture signal real.

EDR and XDR, and what 'extended' adds

EDR (endpoint detection and response) puts an agent on the host that records behaviour — process creation and parentage, command lines, network connections, file and registry changes, script execution — analyses it for malicious patterns, and allows response actions: isolate the host from the network, kill a process, quarantine a file, and retrieve artefacts for investigation.

Why it exists is the Domain 2 argument: signature antivirus looks for known bad files, and fileless and living-off-the-land attacks use no foreign file at all. EDR looks at what happened, so a signed Microsoft binary behaving anomalously is still visible.

XDR (extended detection and response) extends the same correlation beyond the endpoint — email, identity, network, cloud workloads and SaaS — so that a single detection can be built from signals in several places: a phishing email delivered, a link clicked, a process spawned, a token issued, a connection made. The extension is across telemetry sources, and that is the answer if the exam asks what "extended" means.

Distinguishing the related terms:

• Antivirus/EPP — prevention on the endpoint, largely signature and heuristic.
• EDR — detection, investigation and response on the endpoint.
• XDR — the same across endpoint, identity, email, network and cloud.
• SIEM — log aggregation and correlation across everything, including sources with no agent; the system of record for investigation and compliance.
• SOAR — the automation layer that executes the response, which is the next lesson.

The most useful EDR capability to remember for scenarios: network isolation, which cuts a host off from everything except the management channel, so it can be investigated live without the attacker being able to act.

DKIM, DMARC, SPF, gateways, and the three records that must agree

Email authentication answers "is this message really from the domain it claims?" Three DNS records, and they build on each other.

• SPF (Sender Policy Framework) — a DNS TXT record listing which servers may send mail for your domain. The receiver checks the connecting server's address against it. SPF validates the envelope sender (the return-path), which is not the From: address the user sees — and that gap is why SPF alone does not stop display-name spoofing.
• DKIM (DomainKeys Identified Mail) — the sending server signs the message with a private key; the public key is published in DNS. The receiver verifies the signature, proving the message was authorised by the domain and has not been altered in transit. DKIM survives forwarding better than SPF does.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) — ties the two together. It requires SPF or DKIM to pass and to align with the visible From: domain, which is the part that closes the gap above. It then tells receivers what to do when checks fail — its policy:
• p=none — do nothing, just report. The starting position, for gathering data.
• p=quarantine — treat as suspicious, usually deliver to junk.
• p=reject — refuse the message outright.

DMARC also requests aggregate reports (rua=), which tell you who is sending as your domain — the single most useful output when deploying it.

The deployment order that the exam rewards: publish SPF and DKIM, set DMARC to p=none, read the reports until every legitimate sender is accounted for (marketing platforms, ticketing systems, payroll, the printer), then move to quarantine and finally reject. Going straight to p=reject is how an organisation stops receiving its own invoices.

A local note from this estate's own DNS: TXT records here are capped at 255 characters, which forces a 1024-bit DKIM key rather than 2048 — a real constraint to be aware of when publishing these.

Email gateways provide the rest: anti-spam, attachment sandboxing, URL rewriting and time-of-click checking, and impersonation detection for the display-name spoofing that SPF and DKIM cannot see because the sending domain is genuinely the attacker's. Adding external sender banners and a one-click report phishing button are cheap and effective, and they connect to the awareness programme in Domain 5.

User behaviour analytics, and the baseline it is measured against

UBA / UEBA (user and entity behaviour analytics) builds a profile of normal behaviour for each user and device, and alerts on deviation.

What it watches: login times and locations, devices used, volume and type of data accessed, systems touched, privilege use, and peer-group comparison — how this person behaves relative to others doing the same job.

The signals it produces that other controls cannot:

• Impossible travel — authentications from two locations too far apart for the time between them, which is the standard indicator of stolen credentials.
• Unusual data volume — an account reading far more than it ever has, which is exfiltration by someone whose access is legitimate.
• Off-hours and off-pattern access to systems the person rarely touches.
• Privilege use by an account that holds rights but never exercises them.

This is the control for the two threats that defeat everything else in this lesson: the insider from Domain 2, whose activity is authorised, and the attacker using valid stolen credentials, whose activity is indistinguishable from the user's except in pattern.

Its dependency is the heading: it needs a baseline, which means a learning period, and it needs enough history to distinguish unusual from new. Its cost is false positives around genuine change — a promotion, a project, a return from leave — which is why its output is usually a risk score feeding triage rather than an automatic block.

What to take into the exam

• Endpoint DLP is the only one that sees data in use, before it is encrypted for transit.
• NAC checks posture and places a non-compliant device on a remediation VLAN; post-admission re-checks catch a device that degrades mid-session.
• EDR watches behaviour, so it catches fileless activity signatures miss; XDR extends the same correlation across email, identity, network and cloud.
• SPF checks the envelope sender, DKIM signs the message, DMARC enforces alignment with the visible From: and sets the policy.
• Deploy DMARC at p=none first and read the reports; p=reject first breaks legitimate mail.
• UEBA is the control for valid credentials used wrongly — impossible travel and unusual data volume are its signature findings.