14 Mitigating Controls and Techniques · Security+

Exam objective 4.1: Given a scenario, apply mitigating controls, techniques, and solutions to secure the environment.

This objective is the toolbox of Security Operations. It covers how to reduce attack surface and limit damage through segmentation, access controls, hardening, and sandboxing; how to mislead and detect attackers with deception technologies such as honeypots, honeyfiles, honeytokens, and canary accounts; and how to apply a long list of specific solutions: monitoring and alerting, mobile device management (MDM), application allow and block lists, intrusion detection and prevention (NIDS/NIPS, HIDS/HIPS, WIPS), firewalls (rule-based, Layer 4 and Layer 7, WAF, UTM, and rate limiting), content filtering (DLP, agent-based, and centralized proxy), endpoint security (antivirus, EDR, and XDR), network access control (802.1X, captive portals, and posture checks), secrets scanning in code repositories, application security (input validation, secure cookies, static code analysis, and code signing), email security (SPF, DKIM, DMARC, and BIMI), and operating system security (Group Policy and SELinux). This is a "given a scenario, apply" objective, which is the most demanding verb on the exam. You will not just be asked what a WAF is; you will be given a situation—a web application suffering SQL injection, a laptop that keeps failing posture checks, spoofed email reaching executives—and asked which control to apply, how to configure it, or which rule in a list is wrong. Expect performance-based questions that ask you to order firewall rules, read an email header, or choose the right control for each of several systems. As you study, practice reading configurations, not just definitions.

Thinking About Mitigation

A mitigating control reduces either the likelihood that a threat succeeds or the impact if it does. Chapter 1 introduced control categories and types; this chapter is about the specific technical and operational tools that implement them. Most of these tools are preventive or detective, and many are both: an intrusion prevention system detects an attack and then blocks it.

Three questions help you choose the right mitigation in a scenario:

Where is the threat? Network traffic, an endpoint, an application, an email message, a user identity, or a code repository each call for different controls.
What must the control do? Prevent, detect, deceive, contain, or enforce a configuration?
What constraints exist? Legacy systems that cannot run agents, guest devices you do not manage, performance limits, or availability requirements often rule out the "obvious" answer. Many 4.1 questions have two plausible answers. The winning answer usually matches the layer where the problem occurs. A SQL injection attack against a web form points to a WAF or input validation, not a Layer 4 firewall. Malware spreading between workstations points to EDR or segmentation, not an email gateway.

Segmentation

Segmentation divides a network into smaller zones and controls the traffic allowed between them. Without segmentation, a flat network lets any compromised device talk to any other device, so an attacker who phishes one workstation can scan and attack the domain controllers, database servers, and backup systems directly. Segmentation limits this lateral movement and reduces the blast radius of a compromise.

Segmentation can be implemented at several levels:

Physical segmentation uses separate switches, cabling, and routers. It is the strongest separation (an air gap is the extreme case) but the most expensive and least flexible.
Logical segmentation with VLANs divides a physical switch into separate broadcast domains. Traffic between VLANs must pass through a router or Layer 3 firewall, where access control lists can be applied.
Subnetting divides IP address space so that routing and firewall rules can target groups of hosts.
Screened subnets (formerly called DMZs) place internet-facing servers in a zone between the external and internal firewalls so that a compromised web server does not sit on the internal network.
Microsegmentation applies policy at the level of individual workloads, typically in data centers and cloud environments using software-defined networking or host-based agents. Two virtual machines on the same subnet can still be prevented from talking to each other.

Common segments include user workstations, servers, management interfaces, guest Wi-Fi, IoT and building systems, operational technology (OT/ICS), payment card systems (the PCI DSS cardholder data environment), and backups. Isolating the payment environment also shrinks the scope of PCI DSS assessments, which is a business benefit as well as a security one.

A manufacturer's smart thermostats and badge readers share a VLAN with employee laptops. A penetration tester compromises a thermostat with default credentials and uses it to reach a file server. The remediation is to move IoT and building-management devices to their own VLAN, allow them to communicate only with their management servers, and deny all traffic from that VLAN to user and server segments. The vulnerable thermostat may remain, but its ability to cause harm is contained. Segmentation is also a classic compensating control. When a legacy system cannot be patched, isolating it on a restricted segment reduces the risk without fixing the underlying vulnerability. Chapter 10 covers segmentation as an architectural principle, and Chapter 13 discusses it in the context of resilience.

Access Controls

Access controls determine which subjects can reach which resources and what they can do there. In the context of objective 4.1, think of access controls as the enforcement points you configure on systems and networks:

Access control lists (ACLs) on routers, switches, and firewalls permit or deny traffic based on addresses, ports, and protocols.
File system permissions (NTFS permissions on Windows; owner, group, and other read/write/execute bits on Linux) control who can read, modify, or execute files.
Share permissions and cloud storage bucket policies control access to network and cloud data.
Application roles control what users can do within an application.
Privileged access management (PAM) controls and records administrative access.

The governing principle is least privilege: grant only the access required. A common exam pattern is a scenario in which a misconfigured permission—such as an "Everyone: Full Control" share or a public cloud bucket—exposes data, and the correct mitigation is to tighten the access control rather than add another tool. Chapter 18 covers identity and access management models (role-based, rule-based, mandatory, discretionary, time-based, and just-in-time) in detail.

$ ls -l /srv/finance/payroll.csv
-rw-rw-rw- 1 root finance 48211 Oct 2 09:14 payroll.csv
$ chmod 640 /srv/finance/payroll.csv
$ ls -l /srv/finance/payroll.csv
-rw-r----- 1 root finance 48211 Oct 2 09:14 payroll.csv

In the example above, the payroll file was world-writable (rw-rw-rw-, or 666). Changing it to 640 gives the owner read/write, the finance group read-only, and everyone else nothing.

Hardening

Hardening is the process of reducing a system's attack surface by removing what is unnecessary and securing what remains. A default installation of almost any operating system, network device, or application favors convenience: sample files, open ports, default accounts, and permissive settings. Hardening reverses those defaults.

Core hardening techniques apply to nearly every kind of system:

Technique What it means Example

Remove unnecessary software

Uninstall applications, roles, and features not

needed

Remove a web server role from a file server

Disable unneeded services and ports

Stop and disable services; close listening ports

Disable Telnet, FTP, and SMBv1

Change default credentials Replace default usernames and passwords Change admin/admin on a switch or camera

Disable or rename default accounts

Reduce well-known targets Disable the built-in guest account

Patch and update Apply OS, firmware, and application updates Monthly patch cycle, firmware for

Bios/uefi

Apply secure configuration baselines

Use a vetted configuration standard CIS Benchmarks, DISA STIGs, vendor guides

Enable logging Ensure events are recorded and forwarded Forward logs to the SIEM Use encryption Protect data at rest and in transit Full-disk encryption, SSH instead of Telnet

Enable host firewall Restrict inbound and outbound connections Windows Defender Firewall, nftables Restrict administrative access

Limit who and where admins can log in from Management VLAN, jump servers, MFA A secure baseline is a documented, approved configuration that every system of a given type must match. Organizations often start from an industry benchmark, such as the CIS Benchmarks or the U.S. Department of Defense Security Technical Implementation Guides (STIGs), and tailor it to their needs. Baselines are then enforced and monitored with configuration management tools, Group Policy, MDM, or desired-state automation (Chapter 19), and deviations are detected as configuration drift. Hardening looks different on different targets:

Workstations and servers: patching, host firewall, EDR, disabling autorun, restricting local administrator rights, secure boot, and full-disk encryption.
Network devices: disable unused switch ports, use SSH and SNMPv3 instead of Telnet and SNMPv1/v2c, secure the management plane, and back up configurations.
Mobile devices: managed through MDM (covered later in this chapter).
Cloud infrastructure: restrict security groups, disable public access by default, enforce MFA on the root account, and monitor with cloud security posture management (Chapter 16).
Embedded, IoT, and ICS/SCADA systems: change default credentials, update firmware where possible, and rely heavily on segmentation because these devices often cannot run agents.
Wireless: use WPA3, disable WPS, and authenticate enterprise users with 802.1X.

Common trap

Hardening can break things. Disabling a protocol that a legacy application depends on causes an outage just as surely as an attack does. Apply hardening changes through change management (Chapter 2), test them in a non-production environment, and have a backout plan.

Memory aid

Hardening in four verbs: Remove what you do not need, Change what came by default, Update what remains, and Lock down access to it.

Sandboxing

A sandbox is an isolated environment in which code can run without being able to affect the host system or the wider network. If the code is malicious, the damage stays inside the sandbox, which can be discarded.

Sandboxing shows up in several forms:

Malware analysis sandboxes detonate suspicious files and URLs in an instrumented virtual machine, observing behavior such as registry changes, file encryption, and network callbacks. Email security gateways and next-generation firewalls often send unknown attachments to a cloud sandbox before delivering them.
Browser and application sandboxing confines each browser tab, PDF reader, or document viewer so that an exploit in rendered content cannot reach the operating system.
Mobile operating system sandboxing isolates each app's data and permissions from other apps.
Development and testing sandboxes let developers run untrusted or unfinished code away from production data.
Containers and virtual machines provide isolation that can be used for sandboxing, although a container shares the host kernel and is therefore a weaker boundary than a full VM.

Sophisticated malware sometimes checks whether it is running in a sandbox (looking for virtualization artifacts, short uptimes, or a lack of user activity) and stays dormant if it is. This is sandbox evasion, and it is why sandbox results are one signal among many rather than a guarantee.

If a scenario asks how to safely determine what an unknown attachment or executable does, the answer is sandboxing (detonation in an isolated environment). If it asks how to stop users from running unapproved software at all, the answer is application allow listing.

Deception and Disruption

Deception technologies create fake assets that have no legitimate business use. Because nobody should ever touch them, any interaction is a high-fidelity indicator of malicious activity. Deception produces very few false positives, wastes attackers' time, and can reveal their tools and techniques.

Honeypot

A honeypot is a decoy system designed to look like a valuable, vulnerable target—a database server, an unpatched web server, or an exposed SSH host. Honeypots are monitored closely so that defenders can detect intrusion attempts and study attacker behavior.

Low-interaction honeypots emulate services superficially (they respond to a port scan or a login prompt). They are safe and easy to deploy but reveal limited information.
High-interaction honeypots are real systems with real operating systems. They capture far more attacker behavior but carry more risk, because an attacker who fully compromises one could use it as a launch point. They must be carefully isolated.

Honeynet

A honeynet is a network of honeypots, often simulating an entire environment with servers, workstations, and network devices. Honeynets let researchers observe how attackers move laterally and interact with multiple systems. They are more realistic and more expensive to maintain.

Honeyfile

A honeyfile is a decoy file with an enticing name, such as passwords.xlsx, 2027_layoffs.docx, or VPN_admin_creds.txt, placed on a file share or endpoint. File access auditing or a deception platform alerts whenever the file is opened. Because no legitimate user needs the file, opening it suggests an insider snooping or an intruder searching for valuable data.

Honeytoken

A honeytoken is a piece of fake data planted where an attacker might find and use it: a fake API key in a code repository, fake AWS credentials in a configuration file, a fake customer record in a database, or a unique fake email address in a mailing list. When the token is used anywhere—an authentication attempt with the fake key, an email sent to the fake address, the fake record appearing on a dark web forum—defenders know which data store was compromised. Honeytokens are especially good at detecting data exfiltration and tracing a leak to its source.

Canary Account

A canary account is a fake user account (or a disabled or decoy privileged account) that no legitimate person uses. Any authentication attempt against it, or any query enumerating it, generates an alert. For example, a domain account named svc_backup_admin with an attractive description, no real function, and an alert on every logon attempt can detect an attacker performing password spraying or Kerberoasting. The name comes from the "canary in a coal mine," which warned miners of danger before they were harmed.

Deception technique

What it is What triggers detection

Honeypot Decoy system Connections, scans, logins to the system

Honeynet Network of decoy systems Activity anywhere in the decoy network Honeyfile Decoy file The file being opened, copied, or modified

Honeytoken Fake data or credential The data being used or appearing elsewhere Canary account Fake user account Logon attempts or enumeration of the account

Note

Disruption strategies go beyond detection to slow or confuse attackers: returning fake DNS answers (DNS sinkholing of known-malicious domains), feeding fake telemetry or fake data, or tarpitting connections so that scans take a very long time. These raise the attacker's cost and buy time for responders.

Common trap

Deception must be deployed legally and carefully. Honeypots should be isolated so that they cannot be used to attack others, and they should never be used to entice someone to commit a crime they would not otherwise commit. On the exam, the main point is that interaction with a decoy is a reliable indicator of compromise.

Monitoring and Alerting

Preventive controls eventually fail, so every environment needs monitoring (continuously collecting and examining logs, metrics, and events) and alerting (notifying people or systems when something requires attention). Many of the tools in this chapter—IDS/IPS, EDR, firewalls, DLP, and deception—are only as useful as the monitoring behind them. A firewall that logs every denied connection to a disk nobody reads provides little detection value.

Effective monitoring and alerting for mitigation purposes includes:

Centralized collection of logs from firewalls, endpoints, servers, applications, identity providers, and cloud services, typically into a SIEM.
Correlation of related events across sources (a failed VPN login, followed by a successful one from a new country, followed by a mass file download).
Thresholds and baselines so that alerts fire on meaningful deviations rather than on every event.
Prioritized, actionable alerts routed to the right team with enough context to act.
Tuning to reduce false positives so that analysts do not suffer alert fatigue.

Chapter 17 covers alerting and monitoring tools and activities (SIEM, SNMP, NetFlow, syslog, dashboards, and alert tuning) in depth. For objective 4.1, recognize monitoring and alerting as the detective counterpart to preventive mitigations: a hardened system that is not monitored can be compromised silently.

Mobile Device Management (MDM)

Mobile device management (MDM) is a centralized platform for enrolling, configuring, securing, and monitoring smartphones, tablets, and increasingly laptops. Modern products are often called unified endpoint management (UEM) because they manage all endpoint types from one console. MDM is the primary way organizations harden and control mobile devices they cannot physically touch. Common MDM capabilities include:

Enrollment and inventory: registering devices, recording ownership, model, OS version, and assigned user.
Configuration profiles: Wi-Fi, VPN, email, and certificate settings pushed to devices.
Security policies: required screen lock and passcode complexity, encryption, automatic lock timeout, and biometric settings.
Application management: pushing required apps, blocking prohibited apps, and managing enterprise app stores.
Containerization: separating corporate apps and data from personal apps and data on the same device, which is essential for BYOD.
Compliance checks: detecting jailbroken or rooted devices, outdated OS versions, or disabled encryption, and blocking access until resolved.
Remote lock and remote wipe: full wipe for corporate-owned devices, or selective wipe that removes only corporate data from a personal device.
Geolocation and geofencing: locating lost devices and enforcing policies (such as disabling the camera) inside certain locations.

Deployment models affect how much control MDM exercises. With corporate-owned, business only (COBO) devices, the organization controls everything. With corporate-owned, personally enabled (COPE) devices, the organization owns the device but allows personal use. With choose your own device (CYOD), employees select from an approved list. With bring your own device (BYOD), employees use personal devices, and the organization typically manages only a corporate container. Chapter 15 discusses how these models affect asset management.

Real-world scenario

A sales representative loses a personally owned phone that contains corporate email and the CRM app. The company uses MDM with a BYOD containerization profile. The administrator issues a selective wipe, which deletes the corporate container and its data while leaving the employee's personal photos and apps untouched. A full device wipe would also have protected the data, but it would have destroyed personal content the company has no right to delete.

Application Control

Application control restricts which software can execute on a system. It is one of the most effective defenses against malware and unauthorized software, because code that cannot run cannot do harm.

Allow Lists

An allow list (formerly called a whitelist) permits only explicitly approved applications to run; everything else is blocked by default. This is a default-deny approach. Applications can be identified by:

File hash: the most precise method, but every update changes the hash and requires a new entry.
Publisher or code-signing certificate: allows any software signed by a trusted vendor, which survives updates.
File path: allows anything in a protected location such as C:\Program Files\, which is easy to manage but weaker if users can write to the path.

Allow listing is extremely effective against unknown malware and ransomware, but it requires careful maintenance and works best on systems with stable software, such as servers, kiosks, point-of-sale terminals, and industrial workstations. Windows tools include AppLocker and Windows Defender Application Control (WDAC).

Block Lists

A block list (formerly called a blacklist or deny list) permits everything except explicitly prohibited applications. This is a default-allow approach. Block lists are easy to deploy and rarely break business processes, but they only stop software someone already knows is bad. New malware, or a renamed copy of a blocked tool, slips through. Traditional signature-based antivirus is essentially a very large block list.

Feature Allow list Block list

Default action Deny everything not listed Allow everything not listed

Protection against unknown malware

Strong Weak

Administrative effort High (every approved app must be listed)

Low (only known-bad apps listed)

Risk of blocking legitimate work Higher Lower

Best fit Servers, kiosks, POS, ICS, high-security endpoints

General-purpose workstations, quick response to a known threat

Exam tip

When a question asks for the most secure way to ensure only approved software runs, choose an allow list. When it describes blocking one specific known-bad application quickly with minimal disruption, a block list is the better fit.

Intrusion Detection and Prevention Systems

An intrusion detection system (IDS) monitors traffic or system activity and generates alerts when it detects suspicious behavior. An intrusion prevention system (IPS) does the same but also takes action to block the activity. The key difference is placement:

An IDS is typically out-of-band (passive). It receives a copy of traffic from a SPAN/mirror port or a network TAP. It cannot stop traffic directly, but if it fails, network traffic is unaffected.
An IPS is inline. All traffic flows through it, so it can drop malicious packets, reset connections, or block source addresses. If it fails, it can interrupt traffic unless it is configured to fail open (pass traffic) rather than fail closed (block traffic).

Figure 14.1: An IDS receives a copy of traffic out-of-band and can only alert, while an inline IPS sits in the traffic path and can block

Detection Methods

Method How it works Strength Weakness

Signature-basedMatches traffic against patterns of known attacks

Accurate, few false positives for known attacks

Misses zero-days and modified

attacks; signatures must be updated

Anomaly-based (behavioral

)

Learns a baseline of normal activity and alerts on deviations

Can detect novel attacks

More false positives; needs a clean baseline

Heuristic Uses rules and algorithms (increasingly machine learning) to judge whether behavior is likely malicious

Detects variants of known attacks

Can be tuned too loosely or too tightly

A sample signature in Snort/Suricata syntax shows how signature rules work:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"Possible SQL injection - UNION SELECT"; flow:to_server,established; content:"UNION"; nocase; content:"SELECT"; nocase; distance:0; classtype:web-application-attack; sid:1000001; rev:1;)

Changing alert to drop turns this detection into a prevention rule on an inline IPS.

Remember the outcome terminology: a false positive is an alert on benign activity, and a false negative is a missed attack. False negatives are generally more dangerous, but too many false positives cause analysts to ignore alerts.

NIDS and NIPS

A network-based IDS/IPS (NIDS/NIPS) inspects network traffic at strategic points: behind the perimeter firewall, at the boundary of the data center, or between segments. A NIDS sees traffic for many hosts at once, but it cannot inspect the contents of encrypted traffic unless TLS is decrypted upstream, and it does not know whether an attack actually succeeded on the target host.

HIDS and HIPS

A host-based IDS/IPS (HIDS/HIPS) runs as software on an individual endpoint or server. It monitors system calls, logs, file integrity, registry changes, and local network traffic. Because it runs on the host, it sees traffic after decryption and can tell whether a process actually did something malicious. File integrity monitoring (FIM) is a common HIDS function. HIDS/HIPS functionality is now usually part of an EDR agent.

Wips

A wireless intrusion prevention system (WIPS) monitors the radio spectrum for wireless threats, using sensors or the access points themselves. A WIPS detects and can respond to:

Rogue access points plugged into the wired network without authorization.
Evil twin access points that broadcast the organization's SSID to lure users.
Deauthentication and disassociation floods used to knock clients off the network.
Unauthorized ad hoc networks and clients connecting to unapproved networks.

Containment may involve sending deauthentication frames to clients associated with a rogue AP (which must be done carefully and only on your own network) and locating the rogue device by signal strength. A wireless IDS (WIDS) only detects; a WIPS also responds.

Type Monitors Sees encrypted payloads? Typical response
NIDS Copy of network traffic No (unless decrypted upstream) Alert
NIPS Inline network traffic No (unless it decrypts) Drop, reset, block
HIDS One host's activity Yes (after decryption on host) Alert

HIPS One host's activity Yes Block process or connection

WIPS Wireless spectrum Monitors 802.11 management frames and RF

Contain rogue AP, alert

A university's security team receives complaints that students are being prompted to log in to "Campus-WiFi" on an unfamiliar captive page. The WIPS detects a second access point broadcasting the same SSID with a much stronger signal near the library and a different BSSID. The team identifies it as an evil twin, uses the WIPS to locate the device, and removes it. Students are reminded to use the 802.1X-protected "Campus-Secure" network, which validates the server certificate.

Firewalls

A firewall enforces policy on traffic passing between networks or into and out of a host. Firewalls are the classic network mitigation, and the exam expects you to read and reason about rule sets.

Rule-Based Firewalls and Rule Order

A rule-based firewall evaluates each packet or connection against an ordered list of rules. Each rule specifies matching criteria—source address, destination address, protocol, destination port, and sometimes interface, direction, user, or application—and an action, usually allow (permit) or deny (block or drop).

Three principles govern rule-based firewalls:

Top-down, first match: rules are evaluated in order, and the first matching rule determines the action. Later rules are never reached for that packet.
Specific before general: place narrow rules (a single host) above broad rules (an entire subnet or "any"), or the broad rule will shadow the narrow one.
Implicit deny: anything that does not match an allow rule is denied. Many administrators add an explicit "deny any any" rule at the bottom so that denials are logged.

Most modern firewalls are stateful: they track the state of connections, so return traffic for an allowed outbound connection is automatically permitted. A stateless packet filter (such as a basic router ACL) evaluates each packet independently and needs explicit rules for return traffic.

Here is a sample inbound rule set for a perimeter firewall protecting a screened subnet: Rule Source Destination Protocol Port Action Purpose

1 203.0.113.

0/24

Any Any Any Deny Block known-hostile range from threat feed

2 Any 198.51.100.10 (web)

TCP 443 Allow HTTPS to public web server

3 Any 198.51.100.10 (web)

TCP 80 Allow HTTP (redirects to HTTPS)

Rule Source Destination Protocol Port Action Purpose

4 Any 198.51.100.25 (mail)

TCP 25 Allow Inbound SMTP to mail gateway

5 192.0.2.50

(admin VPN)

198.51.100.0/2

TCP 22 Allow SSH from admin VPN only

6 Any Any Any Any Deny Explicit deny all (logged)

Notice why rule 1 comes first: it must block the hostile range before rules 2 through 4 allow "Any" source. If rule 1 were moved below rule 2, hosts in 203.0.113.0/24 could still reach the web server on port 443.

Now consider an internal rule set between the user VLAN (10.10.20.0/24) and the server VLAN (10.10.50.0/24) that contains a mistake:

Rule Source Destination Protocol Port Action
1 10.10.20.0/24 10.10.50.0/24 Any Any Allow
2 10.10.20.0/24 10.10.50.20 (DB) TCP 1433 Deny
3 10.10.20.0/24 10.10.50.15 (file) TCP 445 Allow
4 Any Any Any Any Deny

The intent was to block users from connecting directly to the SQL Server database on TCP 1433, but rule 1 allows all traffic from the user VLAN to the entire server VLAN, so rule 2 is never reached. This is a shadowed rule. The corrected rule set follows least privilege and allows only what is needed:

Rule Source Destination Protocol Port Action
1 10.10.20.0/24 10.10.50.15 (file) TCP 445 Allow
2 10.10.20.0/24 10.10.50.30 (intranet) TCP 443 Allow
3 10.10.20.0/24 10.10.50.10 (DNS) UDP 53 Allow
4 10.10.20.0/24 10.10.50.0/24 Any Any Deny
5 Any Any Any Any Deny

Rule 4 is technically redundant with rule 5, but it documents intent and allows denied user-to-server traffic to be logged separately.

The same logic appears in host firewalls. A Linux server using iptables syntax might look like this: # Default policy: drop inbound

iptables -P INPUT DROP
# Allow return traffic for established connections (stateful)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Allow loopback
iptables -A INPUT -i lo -j ACCEPT
# Allow SSH only from the management subnet
iptables -A INPUT -p tcp -s 10.10.99.0/24 --dport 22 -j ACCEPT
# Allow HTTPS from anywhere
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Log anything else before the default drop
iptables -A INPUT -j LOG --log-prefix "INPUT-DROP: "

Exam tip

For firewall PBQs, read every rule top to bottom and ask: "What is the first rule this traffic matches?" Look for broad allow rules placed above specific denies, rules that use "Any" where a specific port belongs, insecure protocols (Telnet 23, FTP 21, unencrypted LDAP 389 where LDAPS 636 is expected), and a missing deny at the end.

Memory aid

Common ports worth knowing cold for firewall questions: FTP 20/21, SSH/SFTP/SCP 22, Telnet 23, SMTP 25 (submission 587, SMTPS 465), DNS 53, HTTP 80, Kerberos 88, POP3 110, NTP 123, IMAP 143, SNMP 161/162, LDAP 389, HTTPS 443, SMB 445, syslog 514, LDAPS 636, IMAPS 993, POP3S 995, SQL Server

1433, rdp 3389.

Layer 4 and Layer 7 Firewalls

Firewalls are often described by the highest OSI layer they understand.

A Layer 4 firewall makes decisions based on network and transport-layer information: IP addresses, protocol (TCP, UDP, ICMP), and port numbers, along with connection state. It is fast and simple, but it cannot tell what is inside the traffic. To a Layer 4 firewall, any traffic on TCP 443 is "HTTPS," whether it is a legitimate web request, a tunneled remote access tool, or malware command-and-control. A Layer 7 firewall (application-layer firewall) inspects application data. It can identify the actual application regardless of port (for example, recognizing BitTorrent running on port 443), apply policy per application and per user, inspect HTTP methods and URLs, and block specific application functions such as file uploads to a cloud storage service. This is the defining capability of a next-generation firewall (NGFW), which combines stateful Layer 4 filtering with application awareness, user identity integration, IPS, and often TLS inspection. Layer 7 inspection requires more processing power and, for encrypted traffic, usually requires TLS decryption with a trusted interception certificate deployed to clients.

Feature Layer 4 firewall Layer 7 firewall

Decision basis IPs, ports, protocol, state Application, content, user, URL, function Identifies apps on non-standard portsNo Yes

Performance Higher throughput More resource-intensive

Encrypted traffic Sees only headers Needs TLS inspection for content

Example Router ACL, basic stateful firewall NGFW, WAF, application proxy Web Application Firewall (WAF)

A web application firewall (WAF) is a Layer 7 firewall specialized for HTTP and HTTPS traffic to web applications and APIs. It sits in front of web servers (as an appliance, reverse proxy, host module, or cloud service) and inspects requests for attacks such as SQL injection, cross-site scripting (XSS), command injection, directory traversal, and malicious file uploads. WAFs use signature rule sets (such as the OWASP Core Rule Set), positive security models that define what valid requests look like, and anomaly scoring.

A WAF is particularly valuable as virtual patching: when a vulnerability is found in a web application and a code fix will take weeks, a WAF rule can block exploitation in the meantime. A WAF does not replace secure coding; it is a layer in front of it.

2026-10-03T14:22:07Z WAF action=BLOCK rule=942100 msg="SQL Injection Attack Detected via libinjection"

client=198.51.100.77 method=GET uri="/products?id=1' OR '1'='1" host=shop.example.com

Common trap

A network firewall that allows TCP 443 to a web server provides no protection against SQL injection, because the attack is a perfectly valid HTTPS request on an allowed port. Only a Layer 7 control that understands HTTP, such as a WAF, or secure code in the application itself, can stop it. Unified Threat Management (UTM)

A unified threat management (UTM) appliance combines many security functions in a single device: stateful firewall, IPS, antivirus/anti-malware gateway, URL and content filtering, spam filtering, VPN, and sometimes DLP and bandwidth management. UTMs are popular with small and midsize organizations and branch offices because they are cost-effective and simple to manage from one console. The trade-offs are performance (enabling every feature on one box can reduce throughput) and a single point of failure: if the UTM fails or is compromised, many protections disappear at once. The terms UTM and NGFW overlap considerably in modern products; for the exam, associate UTM with "all-in-one for smaller environments" and NGFW with "application-aware Layer 7 firewall."

Rate-Limiting Requests

Rate limiting restricts how many requests a client can make in a given time window. It mitigates:

Brute-force and credential-stuffing attacks against login pages and APIs.
Application-layer denial of service, where an attacker floods expensive requests (searches, report generation) rather than raw packets.
Web scraping and API abuse.
Resource exhaustion caused by misbehaving clients.

Rate limits can be applied per source IP address, per user or API key, per session, or per endpoint, and can respond by delaying requests (throttling), returning HTTP 429 "Too Many Requests," presenting a CAPTCHA, or temporarily blocking the source. WAFs, API gateways, load balancers, reverse proxies, and CDN/DDoS protection services commonly provide rate limiting.

This configuration allows each client IP five login requests per minute with a small burst allowance, and returns 429 beyond that.

Note

Per-IP rate limits are weaker against distributed attacks, such as credential stuffing from a botnet with thousands of IPs. Combine them with per-account lockout or throttling, MFA, bot detection, and compromised-credential checks.

Content Filtering

Content filtering inspects and controls the content users access and transmit, most commonly web traffic. Filters can block categories of websites (gambling, adult content, malware, newly registered domains), specific URLs, file types, and keywords. A secure web gateway (SWG) is a product category that combines URL filtering, malware scanning, application control, and DLP for web traffic, increasingly delivered from the cloud as part of security service edge (SSE) and SASE architectures (Chapter 10). Data Loss Prevention (DLP)

Data loss prevention (DLP) detects and prevents unauthorized transmission or exposure of sensitive data. DLP inspects content for patterns such as credit card numbers (validated with the Luhn algorithm), Social Security or Social Insurance numbers, health records, source code, and documents carrying classification labels, and it can fingerprint specific sensitive documents.

DLP operates in three places:

Endpoint DLP (data in use): controls copying to USB drives, printing, screen captures, clipboard use, and uploads from the device.
Network DLP (data in motion): inspects email, web, and file transfer traffic leaving the network.
Storage or cloud DLP (data at rest): scans file shares, databases, and cloud services such as SaaS storage for sensitive data in the wrong place.

DLP actions include logging, alerting, warning the user and requiring justification, encrypting the content automatically, quarantining it, or blocking the transfer. Chapter 12 discusses data classification, which DLP depends on.

Agent-Based Filtering

Agent-based content filtering installs software on each endpoint that enforces web and content policy locally. Its major advantage is that protection follows the device: a laptop on hotel Wi-Fi or a home network is filtered exactly as it would be in the office, without routing traffic back through headquarters. Agents can also inspect traffic before encryption and associate activity with a specific user and process. The disadvantages are that agents must be deployed and maintained on every device, they consume endpoint resources, and they cannot be installed on unmanaged devices.

Centralized Proxy

A centralized proxy filters content at a network chokepoint. Clients send web requests to the proxy (either through explicit browser or PAC-file configuration or transparently via network redirection), and the proxy applies policy, caches content, logs activity, and forwards permitted requests. A proxy that also performs TLS inspection can scan encrypted traffic for malware and DLP violations. Centralized proxies are easy to manage and cover any device on the network, including those that cannot run agents. However, they only filter traffic that passes through them; remote users must be forced through a VPN or a cloud-hosted proxy, and the proxy can become a bottleneck or single point of failure. A forward proxy acts on behalf of internal clients going out; a reverse proxy sits in front of servers on behalf of external clients coming in (and is the basis of many WAFs).

Feature Agent-based Centralized proxy

Location On each endpoint At network chokepoint or in the cloud

Off-network coverage Yes, follows the device Only if traffic is routed through it Feature Agent-based Centralized proxy

Covers unmanaged or agentless devices

No Yes, if on the network

Deployment effort Install on every device Configure clients or network redirection Visibility User and process context Network-level, user via authentication

Real-world scenario

A consulting firm's employees work mostly from client sites and home, but the web filter is a proxy appliance at headquarters. Logs show that most web traffic never reaches it. The firm adds an agent-based filter (or a cloud SWG whose client agent steers traffic to the provider) so that policy applies wherever the laptops connect.

Endpoint Security

Endpoints—laptops, desktops, servers, and virtual machines—are where users click links, open attachments, and run code, so they are where most attacks ultimately execute.

Antivirus

Antivirus (AV), or anti-malware, detects and removes malicious software. Traditional AV relies on signatures (hashes and byte patterns of known malware), supplemented by heuristics that look for suspicious characteristics and, in modern products, machine-learning models. AV scans files on access, on demand, and on a schedule, and quarantines or deletes detections.

AV remains a baseline control, but signature-based detection struggles with polymorphic malware, fileless attacks that run entirely in memory or abuse legitimate tools like PowerShell ("living off the land"), and novel threats.

Endpoint Detection and Response (EDR)

Endpoint detection and response (EDR) continuously records endpoint activity—process creation, parent-child process relationships, command lines, file and registry changes, network connections, and user logons—and sends that telemetry to a central platform for analysis. EDR focuses on behavior rather than file signatures, so it can detect techniques such as Microsoft Word spawning PowerShell, which then downloads and runs a script.

EDR provides response capabilities that AV does not:

Isolating (quarantining) a host from the network while keeping its connection to the EDR console.
Killing processes and deleting or quarantining files.
Rolling back changes, such as files encrypted by ransomware, on some platforms.
Threat hunting: searching historical telemetry across all endpoints for indicators of compromise.
Remote investigation: collecting files, memory, and logs from an endpoint.

Extended Detection and Response (XDR)

Extended detection and response (XDR) expands the EDR model beyond endpoints. It ingests and correlates telemetry from endpoints, network sensors, email security, identity providers, cloud workloads, and SaaS applications into one platform, so that a single incident (a phishing email, a credential theft, a malicious login, and lateral movement) appears as one correlated story rather than a dozen separate alerts. XDR also coordinates response across layers—for example, deleting the phishing email from every mailbox, disabling the compromised account, and isolating the infected host in one action.

XDR overlaps with SIEM and SOAR (Chapters 17 and 19). A simple distinction: a SIEM is a general-purpose log aggregation and correlation platform for any data source, while XDR is a detection and response product, usually from one vendor, with deep native integration across that vendor's security controls.

Capability Antivirus EDR XDR

Primary detection Signatures, heuristics

Endpoint behavior and telemetry

Correlated behavior across many layers

Scope Single endpoint All endpoints Endpoints, network, email, identity, cloud

Response Quarantine or delete file

Isolate host, kill process, roll back

Coordinated multi-layer response

Threat hunting No Yes, across endpoint data Yes, across all integrated data Fileless/living-off-the-land detectionWeak Strong Strong

Exam tip

Clue words: "signatures" and "known malware" point to antivirus. "Endpoint telemetry," "isolate the host," and "process behavior" point to EDR. "Correlate across email, identity, network, and endpoints" points to XDR.

Network Access Control (NAC)

Network access control (NAC) decides whether a device may join the network, and which part of it, based on who the user is, what the device is, and whether the device meets security requirements. NAC prevents unknown, unmanaged, or unhealthy devices from connecting to sensitive network segments. A typical NAC decision flow works like this:

1. A device connects to a wired port or wireless network.
2. The NAC system authenticates the user and/or device.
3. It assesses the device's posture (patch level, AV status, encryption, and so on).
4. Based on policy, it places the device on the appropriate VLAN or applies an ACL: full access, restricted access, a remediation network, guest internet-only access, or no access.
5. It continues to monitor and can change access if the device's status changes.

Figure 14.2: The NAC decision flow authenticates and assesses each device, then places it on a network segment that matches its identity and posture

802.1X

IEEE 802.1X is the standard for port-based network access control on wired and wireless networks. It defines three roles:

The supplicant: software on the client device requesting access.
The authenticator: the switch or wireless access point that controls the port.
The authentication server: usually a RADIUS server, which checks credentials against a directory such as Active Directory.

Until authentication succeeds, the authenticator allows only EAP (Extensible Authentication Protocol) traffic from the supplicant, carried as EAP over LAN (EAPoL) between the device and the switch or AP and inside RADIUS between the authenticator and the server. Common EAP methods include EAP-TLS (certificates on both client and server; the strongest), PEAP and EAP-TTLS (a TLS tunnel protecting an inner password-based method), and EAP-FAST. After successful authentication, the RADIUS server can tell the switch which VLAN to assign the device, enabling dynamic segmentation.

Supplicant (laptop) --EAPoL--> Authenticator (switch port) --RADIUS--> Authentication server

(before auth: only EAP allowed; after Access-Accept: port opens, VLAN 20 assigned)

Memory aid

802.1X roles: the supplicant supplies credentials, the authenticator is the doorman at the port, and the authentication server (RADIUS) makes the decision.

Devices that cannot run a supplicant, such as printers and IP phones, are often handled with MAC Authentication Bypass (MAB), which admits a device based on its MAC address. Because MAC addresses can be spoofed, MAB devices should be placed on restricted VLANs.

Captive Portals

A captive portal is a web page that a newly connected user must interact with before gaining network access. Until the user acts, the network redirects all web requests to the portal. Captive portals are common on guest and public Wi-Fi, where they may require users to accept an acceptable use policy, enter a voucher code, log in with credentials, or provide an email address. In NAC deployments, a captive portal may also be used to onboard devices or direct users to install a posture agent. Captive portals are convenient but provide weaker security than 802.1X: they typically do not encrypt the wireless connection themselves (open networks rely on Wi-Fi Enhanced Open/OWE or on application encryption), and they authenticate only once through a browser. Attackers also mimic captive portals in evil twin attacks to harvest credentials.

Endpoint Posture and Compliance

Posture assessment checks whether a device meets security requirements before and during network access. Typical checks include:

Operating system version and patch level
Antivirus or EDR installed, running, and up to date
Host firewall enabled
Disk encryption enabled
No prohibited software installed
Device is domain-joined or MDM-enrolled (managed by the organization)
Device is not jailbroken or rooted

Posture is assessed by a persistent agent (installed permanently, offering the deepest checks and continuous monitoring), a dissolvable or non-persistent agent (downloaded at connection time, run once, and removed—useful for contractors and guests), or agentless methods (querying the device remotely or using information from MDM, directory services, or network scans). Devices that fail posture can be placed in a remediation or quarantine VLAN with access only to patch servers and AV updates until they comply. This same concept of continuous device health evaluation is central to Zero Trust (Chapter 1).

Real-world scenario

A hospital requires that any laptop connecting to the clinical network have current EDR and disk encryption. A traveling physician's laptop returns after three weeks without updates. The 802.1X authentication succeeds, but the NAC posture check finds the EDR agent's definitions out of date, so the switch assigns the laptop to the remediation VLAN. The laptop updates automatically, passes reassessment, and is moved to the clinical VLAN without help-desk involvement.

Repositories: Secrets Scanning

Source code repositories (Git hosting platforms and internal version control servers) are an increasingly common source of breaches because developers accidentally commit secrets: API keys, cloud access keys, database connection strings, passwords, private keys, and tokens. Once committed, a secret remains in the repository's history even if a later commit deletes it, and public repositories are scanned by attackers within minutes of a push.

Secrets scanning automatically searches code, commit history, configuration files, and sometimes container images and CI/CD logs for patterns that look like credentials (for example, the fixed prefix of a cloud access key ID, or high-entropy strings next to words like password or token). Secrets scanning can operate:

Pre-commit, using a local hook that blocks a commit containing a secret before it ever leaves the developer's workstation.
On push, where the repository platform rejects pushes containing detected secrets (push protection).
In the CI/CD pipeline, failing the build if secrets are found.
Retrospectively, scanning the entire history of existing repositories.

$ git commit -m "Add billing integration"
[secrets-scan] BLOCKED: possible secret detected
file: config/settings.py line 42

rule: generic-api-key match: BILLING_API_KEY = "sk_live_51H...redacted"

Commit aborted. Move the value to the secrets manager and reference it by name.

When a secret is found in a repository, deleting it from the code is not enough. The correct response is to revoke and rotate the credential immediately (assume it is compromised), review logs for its use, remove it from history if appropriate, and move secrets into a secrets manager or vault that applications query at runtime. Chapter 3 discusses key management, and Chapter 19 covers security in CI/CD pipelines.

Common trap

Removing a leaked key from the latest commit does not remove it from Git history, forks, clones, or caches. The only reliable fix is to rotate the credential.

Application Security

Applications are where business logic and sensitive data meet untrusted input. Objective 4.1 lists four application security techniques.

Input Validation

Input validation ensures that data supplied to an application matches what is expected before the application processes it. It is the primary defense against injection attacks (SQL injection, command injection, LDAP injection), cross-site scripting, buffer overflows, and directory traversal (Chapter 7). Principles of effective input validation:

Validate on the server side. Client-side validation (JavaScript in the browser) improves user experience but is trivially bypassed with a proxy tool; it is never a security control on its own.
Prefer allow lists to block lists. Define what valid input looks like (a five-digit ZIP code, a date in a given format, a value from a fixed list) and reject everything else, rather than trying to enumerate every malicious character.
Check type, length, format, and range. A quantity field should accept only positive integers within a sensible range.
Canonicalize before validating so that encoded input (URL encoding, Unicode tricks) cannot sneak past checks.
Combine with output encoding and parameterized queries. Validation reduces risk, but parameterized queries (prepared statements) are the definitive defense against SQL injection, and output encoding is the definitive defense against XSS.

# Vulnerable: user input concatenated into SQL
query = "SELECT * FROM users WHERE name = '" + username + "'"
# Safer: validate, then use a parameterized query
if not re.fullmatch(r"[A-Za-z0-9_.-]{3,32}", username):
reject()
cursor.execute("SELECT * FROM users WHERE name = %s", (username,))
Secure Cookies

Web applications use cookies to store session identifiers and other state in the browser. A stolen session cookie lets an attacker hijack a logged-in session without knowing the password, so cookie protection is critical. Secure cookie practices use these attributes:

Attribute Effect Protects against

Secure Cookie sent only over HTTPS Interception over unencrypted HTTP

HttpOnly Cookie not accessible to JavaScript Theft through cross-site scripting SameSite=Strict or

Lax

Cookie not sent (or limited) on cross-site requests

Cross-site request forgery (CSRF)
Domain and Path
scoping
Limits where the cookie is sent Exposure to other subdomains or paths

Short Expires or Max-Age

Limits the cookie's lifetime Long-lived stolen sessions

Set-Cookie: SESSIONID=8f2c1e9a7b...; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=1800 Additional practices include generating long, random session IDs, regenerating the session ID after login (to prevent session fixation), invalidating sessions on logout, and never storing sensitive data such as passwords in cookies. If a cookie must hold data, it should be signed or encrypted by the server so it cannot be tampered with.

Exam tip

Match the attribute to the threat: Secure = HTTPS only; HttpOnly = no JavaScript access (XSS); SameSite = no cross-site sending (CSRF).

Static Code Analysis

Static code analysis, also called static application security testing (SAST), examines source code (or compiled bytecode) without running it, looking for insecure patterns: unsanitized input flowing into SQL queries, hard-coded credentials, use of weak cryptographic functions, buffer overflows, and insecure deserialization. Static analysis tools integrate with developer IDEs and CI/CD pipelines so that issues are found early, when they are cheapest to fix—a practice often called "shifting left."

Static analysis finds issues across the whole codebase, including code paths that are rarely executed, and points to the exact line of code. Its weaknesses are false positives (flagging code that is not actually exploitable) and blind spots for runtime and configuration issues. It is complemented by:

Dynamic analysis (DAST), which tests the running application from the outside, as an attacker would.
Manual code review, in which people examine code for logic flaws that tools miss.
Software composition analysis (SCA), which identifies vulnerable third-party libraries and dependencies.
Fuzzing, which feeds random or malformed input to find crashes.

Code Signing

Code signing uses a digital signature to prove who published software and that it has not been modified since it was signed. The developer hashes the code and signs the hash with a private key associated with a code-signing certificate issued by a trusted certificate authority. When a user or system runs or installs the software, the operating system verifies the signature with the public key in the certificate and checks the certificate chain to a trusted root.

Code signing provides integrity (any change breaks the signature), authenticity (the publisher is identified), and non-repudiation. Operating systems use code signing to warn about or block unsigned software, application allow lists can trust specific publishers, mobile app stores require signing, and secure boot verifies the signatures of boot loaders and kernels. Signed software updates prevent attackers from tampering with an update in transit.

Code signing does not prove that code is safe—only who signed it and that it was not altered. Attackers who steal a code-signing private key can sign malware that appears legitimate, which is why signing keys should be protected in hardware security modules (HSMs) and why compromised certificates must be revoked quickly. Chapter 3 covers the underlying PKI concepts.

Note

Supply chain attacks have inserted malicious code into a vendor's build process before signing, producing malware with a valid signature. Protecting build pipelines and verifying software bills of materials (SBOMs) complements code signing.

Email Security

Email is the most common initial attack vector, and the SMTP protocol was designed without authentication: anyone can send a message claiming to be from any address. Three DNS-based standards—SPF, DKIM, and DMARC—let receiving mail servers verify that a message claiming to come from a domain really was authorized by that domain. BIMI builds on them to display a brand logo. All four are published as DNS TXT records (BIMI also uses TXT), so you should be able to read them. Sender Policy Framework (SPF)

SPF lets a domain owner publish a list of the mail servers authorized to send email for that domain. A receiving server looks up the SPF record of the domain in the envelope sender (the SMTP MAIL FROM, also called the Return-Path) and checks whether the connecting server's IP address is on the list. example.com. IN TXT "v=spf1 ip4:198.51.100.25 include:_spf.mailprovider.example include:sendgrid.net -all"

Reading this record:

v=spf1 identifies an SPF record.
ip4:198.51.100.25 authorizes a specific server.
include: authorizes all servers listed in another domain's SPF record (used for cloud email and marketing providers).
-all means fail everything not listed (hard fail). Other qualifiers are ~all (soft fail: accept but mark suspicious), ?all (neutral), and +all (allow everyone, which defeats the purpose and should never be used).

SPF limitations: it checks the envelope sender, not the From: address the user sees; it breaks when mail is forwarded (because the forwarding server is not on the list); and a record may trigger at most 10 DNS lookups.

DomainKeys Identified Mail (DKIM)

DKIM lets the sending domain digitally sign outgoing messages. The sending mail server hashes selected headers and the body, signs the hash with the domain's private key, and adds a DKIM-Signature header. The receiving server retrieves the public key from DNS, at a name formed from a selector and the domain, and verifies the signature. A valid signature proves that the message was sent by a server holding the domain's key and that the signed parts were not altered in transit.

The public key record:

s2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3x...IDAQAB"

The corresponding header added to a message:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s2026; h=from:to:subject:date:message-id; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=Kx8qA0w7...signature...

Here d= is the signing domain, s= is the selector (so the receiver looks up s2026._domainkey.example.com), h= lists the signed headers, bh= is the hash of the body, and b= is the signature. Selectors allow a domain to use multiple keys (for example, one per email provider) and to rotate keys.

DKIM survives forwarding better than SPF because the signature travels with the message, but by itself it does not tell receivers what to do when a signature is missing or invalid.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

DMARC ties SPF and DKIM to the visible From: address and tells receivers what to do when checks fail. A message passes DMARC if it passes SPF or DKIM and the domain that passed is aligned with the domain in the From: header. Alignment is what stops an attacker from passing SPF for their own domain while displaying the victim's domain to the user.

Figure 14.3: A receiving server runs SPF and DKIM checks, then DMARC requires a passing domain aligned with the visible From address before applying the published policy

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; adkim=s; aspf=r" Reading this record:

p= is the policy: none (monitor only, take no action), quarantine (deliver to spam or junk), or reject (refuse the message).
pct= applies the policy to a percentage of failing messages, allowing gradual rollout.
rua= is the address for aggregate reports (daily XML summaries from receivers showing which sources sent mail as your domain and whether they passed).
ruf= is the address for failure (forensic) reports about individual failing messages.
adkim= and aspf= set strict (s, exact domain match) or relaxed (r, subdomains allowed) alignment.
sp= (not shown) can set a separate policy for subdomains.

Organizations typically deploy DMARC in stages: start at p=none to collect reports and discover every legitimate service sending mail as the domain, fix SPF and DKIM for those services, then move to p=quarantine and finally p=reject.

Brand Indicators for Message Identification (BIMI)

BIMI lets a domain display its verified brand logo next to authenticated messages in supporting email clients. It is a visual trust indicator and a marketing incentive for adopting strong DMARC. BIMI requires DMARC at enforcement (p=quarantine or p=reject), a logo in a specific SVG format, and, for most major mailbox providers, a Verified Mark Certificate (VMC) or similar mark certificate proving the organization owns the trademarked logo.

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/brand/logo.svg; a=https://example.com/brand/vmc.pem"

Here l= points to the logo and a= to the mark certificate. BIMI does not authenticate anything by itself; it rewards domains that already authenticate their mail.

Reading Authentication Results

Receiving servers record their checks in an Authentication-Results header, which is the first thing to look at when investigating a suspicious message:

Authentication-Results: mx.recipient.example;
spf=pass smtp.mailfrom=bounce.attacker-mail.example;
dkim=pass header.d=attacker-mail.example;
dmarc=fail (p=REJECT) header.from=example.com
From: "Example Payroll" <payroll@example.com>

This message passed SPF and DKIM—but for the attacker's own domain. Neither passing domain aligns with example.com in the From: header, so DMARC fails, and because example.com publishes p=reject, a compliant receiver rejects it. This is exactly the spoofing scenario DMARC was designed to stop.

Standard What it does DNS record location Checks

SPF Lists authorized sending servers

TXT at the domain Connecting IP vs. envelope sender (Return-Path) domain

DKIM Digitally signs messages TXT at selector._domainkey.do

main
Signature validity and message integrity
DMARC Requires alignment, sets policy,
enables reports

TXT at _dmarc.domain SPF or DKIM pass aligned with the From: domain

BIMI Displays verified brand logo TXT at selector._bimi.domain

Requires DMARC enforcement and usually

a VMC

SPF = Sender Permitted From these servers. DKIM = Digital signature (Keys In the Message). DMARC = Do this with failures, and Mail Aggregate Reports to me. BIMI = Brand Image.

Common trap

SPF, DKIM, and DMARC protect against spoofing of your exact domain. They do not stop look-alike domains (examp1e.com), compromised legitimate accounts, or display-name spoofing from free webmail accounts. Those threats require email gateway filtering, external sender tagging, and user awareness (Chapter 27).

Beyond these standards, an email security gateway (or cloud email security service) scans inbound and outbound messages for spam, malware, malicious links (often rewriting URLs to check them at click time), and impersonation, and can sandbox attachments. Encryption of email in transit uses STARTTLS between mail servers, and end-to-end message encryption uses S/MIME or PGP.

Operating System Security

Group Policy

Group Policy is the Windows Active Directory feature for centrally configuring and enforcing settings on domain-joined computers and users. Administrators create Group Policy Objects (GPOs) and link them to sites, domains, or organizational units (OUs). Computers and users in those containers apply the settings at startup, logon, and periodically thereafter (by default roughly every 90 minutes, with a random offset), and gpupdate /force applies them immediately.

Security uses of Group Policy include:

Password and account lockout policies (length, history, lockout threshold).
Audit policies that determine which events are logged.
User rights assignments (who can log on locally, log on through RDP, or act as part of the operating system).
Security options such as disabling SMBv1, requiring SMB signing, and restricting anonymous access.
Windows Defender Firewall rules.
AppLocker or WDAC application control policies.
Software restriction, removable media restrictions, and disabling AutoRun.
BitLocker encryption settings and recovery key escrow.
Deploying security baselines, such as the Microsoft security baselines or CIS Benchmark GPOs, across thousands of machines at once.

GPOs are processed in the order local, site, domain, OU (LSDOU), and later policies override earlier ones unless an earlier link is set to Enforced or inheritance is blocked. Cloud-managed Windows devices receive equivalent settings through MDM policies.

C:\> gpresult /r

...

Computer settings

Security-Enhanced Linux (SELinux) is a Linux kernel security module, originally developed by the U.S. National Security Agency, that implements mandatory access control (MAC). Standard Linux permissions are discretionary access control (DAC): the owner of a file decides who can access it, and the root user can do anything. SELinux adds a second layer that the owner cannot override. Every process and file has a security context (label), and a central policy defines exactly which process types may access which object types and how.

For example, the Apache web server runs in the httpd_t domain and may read files labeled httpd_sys_content_t. If an attacker exploits the web server, the compromised process still cannot read /etc/shadow or users' home directories, even if file permissions would allow it, because the policy does not permit httpd_t to access those labels. This is type enforcement, and it confines the damage from a compromised service.

SELinux has three modes:
Mode Behavior
Enforcing Policy is enforced; violations are blocked and logged

Permissive Policy is not enforced; violations are only logged (useful for troubleshooting and building policy) Disabled SELinux is turned off entirely

$ getenforce
Enforcing
$ ls -Z /var/www/html/index.html
system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html
$ sudo ausearch -m AVC -ts recent

type=AVC msg=audit(...): avc: denied { read } for pid=2114 comm="httpd" name="shadow" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file

The AVC denial shows SELinux blocking the web server process from reading the shadow password file. A common mistake when an application breaks is to set SELinux to permissive or disabled; the correct approach is to fix file labels (with restorecon or semanage fcontext) or adjust policy booleans (setsebool). AppArmor is a similar MAC system used by default on some other distributions, using path-based profiles instead of labels.

Exam tip

Group Policy = centralized Windows configuration and hardening across a domain. SELinux = mandatory access control on Linux that confines processes even when they run as root. If a question asks how to limit what a compromised Linux service can access, choose SELinux.

Putting It Together: Matching Mitigations to Scenarios

Scenario Best mitigation

Legacy server cannot be patched Segmentation/isolation as a compensating control

Need early warning of attackers inside the network Honeypots, honeyfiles, honeytokens, canary accounts

Kiosks must run only one approved application Application allow list

SQL injection against a public web app WAF (short term) and input validation with parameterized queries (long term)

Login page hit by brute-force attempts Rate limiting, account lockout, MFA Determine what a suspicious attachment does Sandbox detonation

Rogue access point near the office WIPS
Ransomware behavior on workstations EDR with host isolation
Correlate phishing, identity, and endpoint alerts XDR

Unmanaged laptops plugging into office ports NAC with 802.1X and posture checks Guest Wi-Fi terms acceptance Captive portal

Remote users bypass on-premises web filter Agent-based content filtering or cloud SWG Sensitive data uploaded to personal cloud storage DLP

API key accidentally pushed to Git Secrets scanning; rotate the key

Session hijacking via XSS HttpOnly and Secure cookies, output encoding

Users receive spoofed email from the CEO's domain SPF, DKIM, and DMARC at p=reject Enforce SMB signing on 3,000 Windows PCs Group Policy

Confine a compromised Linux web server SELinux in enforcing mode
Lost phone with corporate email MDM remote or selective wipe
Chapter Summary

Segmentation (physical, VLANs, screened subnets, microsegmentation) limits lateral movement and is a common compensating control. Access controls and least privilege restrict who can reach what. Hardening removes unnecessary services, changes defaults, patches, and applies secure baselines such as CIS Benchmarks and STIGs.
Sandboxing runs untrusted code in isolation, especially to detonate suspicious files.
Deception technologies—honeypots, honeynets, honeyfiles, honeytokens, and canary accounts— have no legitimate use, so any interaction is a high-fidelity alert.
Monitoring and alerting are the detective partner of every preventive mitigation.
MDM enforces policy, containerization, compliance, and remote or selective wipe on mobile devices.
Application allow lists (default deny) are stronger but harder to maintain than block lists (default allow).
IDS detects and alerts out-of-band; IPS sits inline and blocks. NIDS/NIPS watch networks, HIDS/HIPS watch hosts, and WIPS watches wireless for rogue and evil twin APs.
Firewalls process rules top-down with first match and implicit deny. Layer 4 firewalls filter on IPs and ports; Layer 7 firewalls understand applications. A WAF protects web apps from SQL injection and XSS; a UTM combines many functions in one appliance; rate limiting throttles brute force and application-layer DoS.
Content filtering includes DLP, agent-based filtering that follows the device, and centralized proxies at network chokepoints.
Antivirus relies on signatures; EDR records endpoint behavior and enables isolation and hunting; XDR correlates across endpoints, network, email, identity, and cloud.
NAC uses 802.1X (supplicant, authenticator, RADIUS server), captive portals, and posture checks to admit, restrict, or remediate devices.
Secrets scanning finds credentials in repositories; leaked secrets must be rotated.
Application security uses input validation (server-side, allow-list), secure cookies (Secure, HttpOnly, SameSite), static code analysis (SAST), and code signing.
SPF lists authorized senders, DKIM signs messages, DMARC requires alignment with the From: domain and sets policy (none, quarantine, reject) and reporting, and BIMI displays a verified logo.
Group Policy centrally hardens Windows domains; SELinux enforces mandatory access control on Linux.

Key Terms

Mitigating control; segmentation; lateral movement; VLAN; screened subnet; microsegmentation; access control list; hardening; secure baseline; CIS Benchmarks; STIG; configuration drift; sandbox; sandbox evasion; deception technology; honeypot; low-interaction honeypot; high-interaction honeypot; honeynet; honeyfile; honeytoken; canary account; DNS sinkhole; monitoring; alerting; mobile device management (MDM); unified endpoint management (UEM); containerization; selective wipe; COBO; COPE; CYOD; BYOD; application control; allow list; block list; AppLocker; intrusion detection system (IDS); intrusion prevention system (IPS); signature-based detection; anomaly-based detection; heuristic detection; false positive; false negative; fail open; fail closed; NIDS; NIPS; HIDS; HIPS; file integrity monitoring; WIPS; rogue access point; evil twin; rule-based firewall; implicit deny; shadowed rule; stateful firewall; stateless firewall; Layer 4 firewall; Layer 7 firewall; next-generation firewall (NGFW); web application firewall (WAF); virtual patching; unified threat management (UTM); rate limiting; content filter; secure web gateway; data loss prevention (DLP); agent-based filtering; centralized proxy; forward proxy; reverse proxy; TLS inspection; antivirus; endpoint detection and response (EDR); extended detection and response (XDR); network access control (NAC); 802.1X; supplicant; authenticator; authentication server; EAP-TLS; PEAP; MAC Authentication Bypass; captive portal; posture assessment; persistent agent; dissolvable agent; remediation VLAN; secrets scanning; secrets manager; input validation; parameterized query; secure cookie; Secure attribute; HttpOnly; SameSite; static code analysis (SAST); DAST; software composition analysis; code signing; SPF; DKIM; selector; DMARC; alignment; aggregate report; BIMI; Verified Mark Certificate; Authentication-Results header; Group Policy; Group Policy Object (GPO); LSDOU; SELinux; mandatory access control; security context; enforcing mode; permissive mode; AppArmor.

Review Questions

1. A firewall administrator reviews the following rules on the firewall between the user VLAN (10.1.10.0/24) and the server VLAN (10.1.50.0/24). Users can still connect to the database server at 10.1.50.20 on TCP 1433, which the security policy prohibits. What is the BEST fix?

Rule 1: Allow 10.1.10.0/24 to 10.1.50.0/24, any port. Rule 2: Deny 10.1.10.0/24 to 10.1.50.20, TCP 1433. Rule 3: Deny any to any.

A. Change rule 3 to an explicit allow any any
B. Move rule 2 above rule 1
C. Change rule 2 to use UDP 1433
D. Delete rule 3 because implicit deny already exists

2. A security team wants to detect attackers who have already gained access to the internal network and are searching file shares for valuable data. The solution must produce very few false positives. Which of the following is the BEST choice?

A. Signature-based NIDS at the perimeter
B. Honeyfiles placed on file shares with access alerting
C. A block list of known hacking tools
D. A captive portal on the wired network

3. A company's public web application is vulnerable to SQL injection. Developers estimate a code fix will take four weeks. Which control will MOST quickly reduce the risk of exploitation in the meantime?

A. A Layer 4 firewall rule allowing only TCP 443
B. A web application firewall rule blocking SQL injection patterns
C. A host-based antivirus scan of the web server
D. Code signing of the application binaries

4. A security administrator wants to ensure that laptops connecting to wired office ports are authenticated with certificates and assigned to a VLAN based on the user's role. Which technologies should the administrator implement? (Select TWO.)

A. 802.1X with EAP-TLS
B. Captive portal
C. RADIUS server
D. Application block list
E. UTM appliance

5. Users report receiving email that appears to come from the company's own CFO at example.com. The headers show spf=pass for an unrelated domain and dmarc=fail, but the messages are still delivered to inboxes. Which change would MOST directly cause receiving servers to refuse these messages?

A. Add ~all to the SPF record
B. Publish a BIMI record
C. Change the DMARC policy from p=none to p=reject
D. Add a second DKIM selector

6. A developer accidentally pushed a cloud access key to a public Git repository and deleted it in the next commit five minutes later. What should the security team do FIRST?

A. Rewrite the repository history to remove the key
B. Revoke and rotate the access key
C. Enable secrets scanning for future commits
D. Make the repository private

7. An organization wants point-of-sale terminals to run only the POS application and its required components, and to block any other executable, including new malware. Which control BEST meets this requirement?

A. Signature-based antivirus
B. Application block list
C. Application allow list
D. Host-based firewall

8. A security analyst needs to correlate a phishing email, a suspicious sign-in to the identity provider, and malicious PowerShell activity on an endpoint into a single incident and respond across all three layers from one console. Which solution BEST fits?

A. Antivirus
B. HIDS
C. XDR
D. Centralized proxy

9. A web application stores its session identifier in a cookie. A penetration test shows that an XSS flaw allows JavaScript to read the cookie and send it to an attacker. Which cookie attribute would have prevented the theft?

A. Secure
B. HttpOnly
C. SameSite=Lax
D. Domain

10. Most of a company's employees work remotely, and web filtering is currently performed by a proxy appliance in the headquarters data center. Logs show that remote users' web traffic is not being filtered. Which change BEST addresses this?

A. Add more URL categories to the proxy
B. Deploy agent-based content filtering on the laptops
C. Install a WIPS at headquarters
D. Replace the proxy with a Layer 4 firewall

11. After a web server running on a Linux host is compromised, the investigation finds that the attacker's process was blocked from reading /etc/shadow even though it was running with elevated privileges. Which control MOST likely blocked the access?

A. Group Policy
B. SELinux in enforcing mode
C. Discretionary access control
D. A network-based IPS

12. A company's login API is receiving thousands of password guesses per minute from a small number of IP addresses. Which mitigations would BEST reduce the effectiveness of this attack? (Select TWO.)

A. Rate limiting requests per source IP and per account
B. Publishing a DMARC record
C. Requiring multifactor authentication
D. Moving the API to a honeynet
E. Code signing the API

Answers and Explanations

1. B. Firewalls process rules top-down and stop at the first match. Rule 1 allows all traffic from the user VLAN to the server VLAN, so it matches database connections before rule 2 is evaluated; rule 2 is shadowed. Moving the specific deny above the broad allow fixes the problem (better still, replace rule 1 with specific allows). Changing rule 3 to allow all would open everything. SQL Server uses TCP 1433, so UDP would not match. Deleting rule 3 changes nothing about rule order and removes the logging of denials.
2. B. Honeyfiles have no legitimate use, so access to them is a high-fidelity indicator of an intruder or snooping insider, and they sit exactly where the attacker is searching. A perimeter NIDS does not see internal file share activity. A block list prevents known tools from running but does not detect searching. A captive portal controls network onboarding, not data access.
3. B. A WAF understands HTTP and can block SQL injection payloads, providing virtual patching until the code is fixed. A Layer 4 rule allowing TCP 443 still permits the malicious HTTPS requests. Antivirus does not inspect web requests for injection. Code signing proves the origin and integrity of binaries but does not stop injection.
4. A, C. 802.1X provides port-based authentication, EAP-TLS uses certificates, and the RADIUS authentication server validates the device and can return a VLAN assignment based on role. A captive portal uses browser-based authentication, typically for guests, and does not provide certificate-based port authentication. Application block lists and UTM appliances do not authenticate devices at the switch port.
5. C. DMARC is failing because the passing SPF domain is not aligned with the From: domain, but a p=none policy tells receivers to take no action. Changing to p=reject instructs receivers to refuse failing messages. A soft fail (~all) is weaker than hard fail and would not affect mail authorized for an unrelated domain. BIMI displays logos and does not enforce anything. An additional DKIM selector does not change policy.
6. B. Public repositories are scanned by attackers within minutes, so the key must be assumed compromised; revoking and rotating it is the first priority. Rewriting history and making the repository private do not invalidate copies already taken. Enabling secrets scanning is a good preventive step for the future but does not address the exposed key.
7. C. An allow list is default-deny, permitting only approved software, so unknown malware cannot execute; it is ideal for single-purpose systems like POS terminals. Signature-based antivirus and block lists only stop known-bad software. A host firewall controls network traffic, not program execution.
8. C. XDR correlates telemetry from email, identity, endpoint, network, and cloud sources into unified incidents and coordinates response across them. Antivirus and HIDS focus on a single host. A centralized proxy filters web traffic and does not correlate identity and endpoint events.
9. B. HttpOnly prevents client-side scripts from reading the cookie, which blocks the typical XSS cookie-theft technique. Secure only ensures the cookie is sent over HTTPS. SameSite limits cross-site sending and primarily mitigates CSRF. Domain scopes which hosts receive the cookie.
10. B. An agent-based filter enforces policy on the device itself, so it applies wherever the laptop connects. More URL categories do not help traffic that never reaches the proxy. A WIPS monitors wireless at headquarters, and a Layer 4 firewall cannot filter web content.
11. B. SELinux enforces mandatory access control that confines processes by type, even elevated ones, and blocks a web server process from reading files labeled for other purposes such as the shadow file. Group Policy applies to Windows domains. Discretionary access control is the standard permission model that elevated processes can bypass. A network IPS does not control local file access.
12. A, C. Rate limiting slows the number of guesses each source and account can make, and MFA ensures a correctly guessed password alone is not enough to log in. DMARC addresses email spoofing. Moving a production API to a honeynet makes no sense, and code signing proves software integrity but does nothing against password guessing.