CompTIA Security+ SY0-801 Mitigating Controls: Firewalls, IDS/IPS, EDR, NAC and Email Security

Segmentation limits who can reach a system, access controls decide what each permitted user or host may do once it gets there, and hardening removes the weaknesses on the system itself. They are the three oldest mitigations in the objective, and choosing between them comes down to one question: can you change the vulnerable system, or only what surrounds it?

Segmentation and access controls

Segmentation divides a network into zones (VLANs, subnets, separate cloud networks) and forces traffic between zones through a control point such as a firewall or router access control list (ACL). Its job is to shrink the set of systems that can talk to a sensitive or fragile asset and to stop an intruder moving sideways. Access controls are the rules applied at those control points and on the systems themselves: ACLs that permit specific sources, destinations and ports, file and share permissions, and least-privilege rights for accounts.

Together they are the standard answer for a system you cannot fix: an outdated medical device, an industrial controller, a printer with unpatchable firmware, or anything a vendor forbids you to modify. You leave the device untouched, place it in its own segment, and write an ACL that permits only the few peers it genuinely needs (for example one management server) with everything else denied. Watching the segment with an IDS is a useful addition, but monitoring only alerts; it does not reduce who can reach the device. Where zones sit in an architecture and how zero trust changes the picture are covered in the Security+ lesson on enterprise infrastructure; identity-based access (accounts, MFA, privileged access) belongs to the identity and access management lesson.

Hardening to a secure baseline

Hardening reduces a system's attack surface by configuring it to a documented secure baseline, often based on vendor guides, CIS Benchmarks or government checklists such as STIGs. A typical hardening checklist:

• Change or disable default accounts and passwords.
• Remove or disable services, protocols and features nothing uses (an unused print spooler on a server, default sample applications on a web server, management protocols that send credentials in clear text).
• Shut down unused switch ports and close unused listening ports.
• Patch the operating system and firmware, and keep them patched.
• Enable logging, encryption and a host firewall where the device supports them.

The distinction to hold on to: hardening fixes weaknesses on the system. A web application firewall, a separate segment or an EDR agent can reduce exposure or add detection, but an unused service, a default credential or an unnecessary feature is still there afterwards. When findings are configuration weaknesses on a host you are allowed to change, hardening is the mitigation that removes them.

Sandboxing runs untrusted code in an isolated, instrumented environment so you can watch what it does without risking production, and deception technology plants decoys that no legitimate user touches, so any interaction with them is a high-confidence alert. One studies suspicious code; the other lures and detects intruders.

Sandboxing

A sandbox (often a disposable virtual machine) lets a sample execute and records its behaviour: files and registry keys it creates, processes it spawns and domains it contacts. That makes it the tool for two jobs:

• Malware analysis: an analyst detonates an unknown executable from an incident to learn its indicators, without it touching production systems.
• Catching unknown malware before delivery: email and web gateways can open attachments and downloads in a sandbox first. A file carrying never-seen malware has no signature for antivirus to match, and if it is sent from a legitimate account that an attacker has taken over it also passes SPF, DKIM and DMARC, which authenticate the sending domain rather than the content. Its behaviour in the sandbox (for example, reaching out to fetch a second-stage payload) still gives it away, and the gateway holds the message before it reaches the mailbox.

Contrast sandboxing with its neighbours. An antivirus scan returns a verdict (matches a signature or heuristic, or not) rather than a behaviour report. A block list stops a file from running, which prevents anyone from learning what it does. A honeypot attracts live attackers; it is not an analysis environment for a sample.

Deception and disruption

Every deception tool works the same way: create something with no legitimate use, then alert on any contact with it. Because real users have no reason to touch it, false positives are rare. The tools differ in what the decoy is, and therefore which attacker activity it can catch.

Choosing one is a matter of matching the decoy to the activity you want to detect and to your constraints. A password spray tries common passwords against every enumerated username; it never opens a file or uses a planted credential, so a honeyfile or honeytoken stays silent, while a canary account in the existing directory is reached by the spray and needs no new host. A honeypot or honeynet, by contrast, means deploying additional systems. Honeytokens and honeyfiles are often confused: a honeyfile is a whole file that alerts when opened; a honeytoken is a piece of data or a credential that alerts when used.

Monitoring and alerting is what turns these mitigations into detection: a decoy that nobody watches, or an IDS whose alerts go nowhere, mitigates nothing. In this objective, think of alerting as part of each control's design (who is told, and how fast). Log aggregation, SIEM correlation and alert tuning are covered in the security alerting and monitoring lesson.

Application control decides which programs may run, mobile device management (MDM) enforces policy on phones and tablets, and Group Policy and SELinux enforce configuration and access rules on Windows and Linux. All four lock down endpoints by policy rather than by detecting attacks.

Allow lists and block lists

The deciding facts are usually stated in the scenario: a tiny fixed set of approved software plus malware that has no signature yet points to an allow list; a need to keep installing new tools without prior approval, plus a short list of known-bad programs, points to a block list. Note what application control does not do: if the browser or Word is an approved program, an allow list does not decide which websites the browser visits or what a macro inside Word does.

Mobile device management

MDM enrolls mobile devices and pushes policy to them from a central console: required PIN or biometric lock and screen-lock timeout, storage encryption, approved and blocked apps, OS update requirements, and remote actions such as locate, lock and wipe when a device is lost. On personally owned devices, MDM (or mobile application management) can separate corporate apps and data into a managed container so that only corporate data is wiped. Group Policy does not manage phones, NAC only decides network admission, and EDR focuses on detecting threats; when the requirements are mobile configuration and remote wipe, the answer is MDM.

Group Policy

Group Policy is the Windows mechanism for configuring domain-joined computers and users centrally through Group Policy Objects (GPOs) linked to Active Directory sites, domains and organizational units. One GPO can set password and lockout policy, screen-lock timeouts, removable-storage restrictions, firewall settings, software restrictions and audit policy across thousands of machines. It applies only to Windows systems that are joined to the domain.

SELinux

Security-Enhanced Linux adds mandatory access control to Linux: every process and file carries a security label (context), and a central policy decides which process types may access which file types, regardless of ordinary file permissions or even root ownership. A compromised web server process therefore cannot read files its policy does not allow, even if the Unix permissions would. SELinux runs in one of three modes, set in /etc/selinux/config (persistent) or with setenforce (switches between enforcing and permissive immediately, until reboot; it cannot turn on a disabled SELinux, which needs the config file, a reboot and usually a filesystem relabel):

Permissive mode, meant for testing a policy, logs what the policy would deny but lets it happen anyway; logged denials therefore do not mean the host is protected. Only enforcing mode blocks violations. The policy type (targeted, the default, which confines selected services; minimum; or MLS, multi-level security) is a separate setting and does not change whether denials are enforced. getenforce shows the current mode.

An intrusion detection system (IDS) watches for attacks and alerts; an intrusion prevention system (IPS) can also block them. Each comes in a network-based form that inspects traffic and a host-based form that runs on the system it protects, and a wireless form watches the radio spectrum. Two questions pick the right one: where must the sensor sit to see the attack, and must it block or only report?

Three reasoning patterns cover most scenarios:

• Must not affect production traffic: an IDS fed by a tap or SPAN port receives copies, so a crash or bad signature only means a missed or false alert. Anything inline or able to block (NIPS, HIPS, WAF) carries the risk of dropping good traffic.
• Encrypted traffic you may not decrypt: a network sensor sees only ciphertext, so inspect on the host, after the server has decrypted the request. Combined with a need to block, that means HIPS; HIDS sees the same content but only alerts.
• Threats in the air: a rogue access point never crosses the wired network sensors, so only a wireless sensor sees it. Reporting it is WIDS; also containing it is WIPS. 802.1X controls who joins your wireless network; it does not stop a laptop associating with someone else's.

Detection methods (signature-based, anomaly or behaviour-based) apply to all of these. Signatures catch known attacks reliably; anomaly detection can flag new attacks but produces more false positives.

A firewall enforces which traffic may pass between networks or into a host. The objective names five aspects: rule-based processing, the difference between Layer 4 and Layer 7 inspection, the web application firewall (WAF), rate limiting, and unified threat management (UTM).

Rule-based processing and implicit deny

A rule-based firewall (or router ACL) holds an ordered list of rules, each matching on source, destination, protocol and port with an action of permit or deny. Rules are evaluated top-down and the first match wins; later rules are never consulted for that packet. If nothing matches, the implicit deny at the end of the list drops the traffic. Three consequences follow:

• Traffic that no rule mentions is blocked. A new firewall with permit rules only for web and email will drop everything else, such as file transfers, without any explicit deny.
• A specific permit must sit above any broader deny that also matches the same traffic, or it is never reached.
• The source is whoever starts the connection. If web servers in 172.16.8.0/24 send logs to a collector at 172.16.20.5 on TCP 6514, the rule is source 172.16.8.0/24, destination 172.16.20.5, port 6514. Reversing source and destination permits connections in the wrong direction.

Layer 4 vs Layer 7

The key idea: when an attacker reuses an allowed port (SSH or a tunnel over TCP 443, SQL injection inside allowed HTTPS requests), a Layer 4 rule cannot tell the bad traffic from the good. Blocking the port would break legitimate use; blocking a different port (22) is irrelevant. Only Layer 7 inspection that identifies the protocol or content can separate them. Next-generation firewalls combine Layer 4 rules with Layer 7 application awareness.

Web application firewall

A WAF is a Layer 7 firewall placed in front of web applications to inspect inbound HTTP(S) requests and block attacks such as SQL injection and cross-site scripting in form fields, headers and URLs. It protects the application's side of the conversation; it does not filter employees' outbound browsing (that is a forward proxy or content filter) and does not replace fixing the code. A NIDS can spot the same attacks but only alerts, so the requests still arrive.

Rate limiting

Rate limiting caps how many requests a source (an IP address, an API key, a user session) may make in a time window. It slows password guessing, credential stuffing, scraping and request floods without changing the targeted accounts. Against a login API hammered from a few addresses, per-source rate limiting slows the attack while real users' occasional logins still succeed; account lockout would also stop guessing but locks out the real owners, and an attacker can exploit that to deny service. Rate limiting does not block a single low-volume connection, so it is no answer to a tunnel or a one-off exploit.

Unified threat management

A UTM appliance combines firewall, IPS, web and content filtering, gateway antivirus and often VPN in one device with one console. That suits small sites with little IT staff. The trade-off is concentration: the appliance is a single point of failure, and switching on every engine can overload it, so a fault, overload or compromise removes every inspection layer at once. UTMs do inspect above Layer 4 and need no endpoint agents.

A content filter controls what users can reach or send, by URL category, reputation, file type or content, and data loss prevention (DLP) is the content filter aimed at sensitive data leaving the organization. The objective's key distinction is where the filtering runs: on a centralized proxy that traffic must pass through, or in an agent on each device.

Traffic that never passes through a central proxy cannot be filtered by it, so devices that browse directly from wherever they are need filtering on the device itself. Two lookalikes do not filter by site: an application allow list governs which programs run (the browser is allowed), and category-based filtering needs URL and reputation awareness that a port-based firewall rule lacks, because almost every website shares the same HTTPS port.

Data loss prevention

DLP recognises sensitive data (by classification labels, patterns such as card or national ID numbers, or document fingerprints) and blocks, encrypts, quarantines or alerts on it as it moves. It comes in three placements:

• Endpoint DLP: an agent watches file operations on the device: copying to USB storage, printing, uploading through a browser, pasting into apps. It enforces policy on and off the corporate network.
• Network DLP: inspects traffic at an egress point such as the proxy or mail gateway. It sees only traffic crossing that point, and never sees a copy to a USB drive.
• Cloud DLP: applies policy to data stored in or moving through cloud services.

When data can leave through the device itself (USB) or from off-network (home users without a VPN), only endpoint DLP sees both paths. EDR and application block lists are real endpoint controls but do different jobs: EDR responds to malicious activity, block lists stop programs, and neither recognises a Confidential label. How data is classified and protected in storage (encryption, masking, tokenization) is covered in the data protection lesson.

Antivirus blocks known malicious files on an endpoint, endpoint detection and response (EDR) records detailed endpoint activity and lets responders investigate and contain a host, and extended detection and response (XDR) correlates detections across endpoints, email, identity, network and cloud into single incidents. Each adds scope to the one before.

Choose on the gap the scenario describes. Script-based attacks that live only in memory may leave no file on disk for a signature scan, and even where antivirus inspects scripts in memory (for example through AMSI) it gives a verdict, not the investigation story. When the need is to reconstruct what a process spawned and to cut a host off the network remotely, the requirement is EDR (a HIDS can alert on host activity but lacks the investigation and isolation tooling). When related alerts from different layers (email, endpoints, identity, cloud) sit in separate tools and nobody stitches them into one incident, the problem is correlation across layers: EDR would still see only the endpoint stage, so the answer is XDR.

Network access control (NAC) decides whether a device may join the network and on what terms, before it gets access. The objective names three mechanisms, and each answers a different question: a captive portal asks the person to complete a web page, 802.1X authenticates the device or user at the port, and endpoint posture checks whether the device is healthy enough.

The mechanisms combine. 802.1X alone proves a laptop is corporate but would admit one that is missing patches; posture alone does not prove the device belongs to the company. When a scenario needs both the device's identity and its health enforced at the point of connection, the answer is 802.1X with posture checks. Posture can be assessed by a persistent agent, a dissolvable agent that runs once and removes itself (common for guests), or agentless scanning. WIPS, by contrast, protects the radio spectrum and does not authenticate anyone.

Five controls in the objective protect software and its source: secrets scanning keeps credentials out of repositories, input validation and secure cookies protect a running web application, static code analysis finds flaws in source before release, and code signing proves who published software and that it has not changed.

Secrets scanning

Secrets scanning matches repository content against patterns for API keys, cloud access keys, tokens, passwords and private keys. Run with push protection, it blocks a commit or push that contains a secret before it lands; run across history, it finds secrets already committed. When it finds one, the order of response matters:

1. Revoke or rotate the credential first. Once a secret has been pushed, especially to a public repository, assume it is compromised: clones, forks, caches and scrapers may already hold it. Only revocation makes those copies useless.
2. Review the credential's usage logs for misuse.
3. Then clean up: purge it from history if needed, and enable push protection so it does not happen again.

Rewriting history or making the repository private hides the secret from future readers but leaves the key valid for anyone who already copied it.

Input validation

Input validation checks that data entering an application has the expected type, length, format and range before it is used, preferably by allowing known-good patterns rather than trying to list bad characters. It must happen on the server. Browser-side JavaScript checks run on the user's machine and are skipped by anyone who edits requests in an intercepting proxy; they improve usability, not security. Server-side validation, together with safe handling such as parameterized queries and output encoding, applies to every request however it was sent.

Secure cookies

Static code analysis

Static code analysis (static application security testing, SAST) examines source code without running it and flags insecure patterns: unsanitized database queries, unsafe functions, hard-coded values, missing error handling. Because it needs no running application, it fits a pull-request or build check. It looks for flaws in code logic; it is not the tool built for committed credentials (that is secrets scanning), and it differs from dynamic testing, which exercises a running application.

Code signing

Code signing applies the publisher's digital signature, made with its private key over a hash of the file, so that the operating system or user can verify the publisher's certificate and confirm the file has not been altered since signing. It answers "who published this, and is it unchanged?" for software packages, updates, scripts and drivers. It does not prove the code is safe or free of flaws: signed software can still be vulnerable or malicious if the signer was careless or compromised. Static analysis, secrets scanning and sandboxing each answer different questions.

Four DNS-published mechanisms protect email from spoofing: SPF lists which servers may send for a domain, DKIM lets receivers verify a message's digital signature, DMARC ties those checks to the visible From domain and tells receivers what to do on failure, and BIMI displays the brand's logo for mail that passes an enforced DMARC policy. All four live in DNS records, so the clue is always what the record contains.

DMARC alignment

DMARC passes when at least one of SPF or DKIM both passes and is aligned, meaning its domain matches the domain in the From header that the reader sees. This is where third-party senders fail. A hosted service (ticketing, payroll, HR surveys) that sends as example.com but uses its own domain as the envelope sender will pass SPF for its domain, yet SPF is not aligned with example.com, and adding the platform to example.com's SPF record does not change that because SPF is not evaluated against example.com here. The reliable fix is to have the platform DKIM-sign with d=example.com: that signature passes and aligns, so DMARC passes while an enforcing policy stays in place. Relaxing the policy only changes what happens to failing mail (spam folder instead of rejection); it does not fix alignment.

DMARC policy and BIMI

p=none is monitoring only: receivers send reports but take no action, which is the usual starting point while you discover all legitimate senders. p=quarantine sends failing mail to spam, and p=reject refuses it. BIMI is honoured only when the domain enforces DMARC, meaning p=quarantine or p=reject applied to all mail (not a reduced percentage); a valid BIMI record and certificate with p=none still shows no logo. BIMI never makes failing mail pass; it is a reward for mail that already passes.

Remember the limit of all four: they prove a message came from a domain's authorized infrastructure, not that the content is safe. Mail from a genuine but compromised partner mailbox passes SPF, DKIM and DMARC, so malicious attachments in it must be caught by other controls such as gateway sandboxing.