Attack-to-Mitigation PBQ Tables
Key Takeaways
- PBQ-style network security tasks often require mapping symptoms to attacks and then to practical mitigations.
- Layer 2 attacks are commonly mitigated with switch hardening, DHCP snooping, dynamic ARP inspection, and port controls.
- Wireless attacks require SSID validation, WPA3 or WPA2-Enterprise, 802.1X, monitoring, and user awareness.
- DDoS mitigation often requires upstream or cloud-based capacity, filtering, and prepared runbooks.
- Controls should match the attack path instead of being selected only because they sound secure.
Last updated: April 2026
Attack-to-Mitigation Tables
Performance-based questions often ask you to drag controls, choose device settings, or complete a policy table. The reliable method is to identify the attack path first, then choose the mitigation that breaks that path with the least side effect.
Layer 2 and Access Edge
| Symptom or evidence | Likely attack or issue | Best mitigation direction |
|---|---|---|
| User port negotiates as trunk and reaches other VLANs | VLAN hopping or trunk misconfiguration | Force access mode, disable DTP where applicable, restrict allowed VLANs, harden native VLAN |
| Switch CAM table fills with many source MACs | MAC flooding | Port security, MAC limits, storm control, 802.1X |
| Clients get wrong gateway and DNS settings | Rogue DHCP | DHCP snooping, trusted uplink ports only, investigate unauthorized server |
| ARP cache maps gateway IP to attacker MAC | ARP poisoning | Dynamic ARP inspection with DHCP snooping bindings, static entries for critical systems where appropriate |
| Unknown device plugged into office port | Unauthorized access | 802.1X, NAC, disabled unused ports, port security |
DNS, Wireless, and User-Focused Attacks
| Symptom or evidence | Likely attack | Best mitigation direction |
|---|---|---|
| Known hostname resolves to unexpected IP | DNS poisoning or rogue DNS | Secure DNS infrastructure, restrict DNS server assignment, monitor DNS changes, DNSSEC where supported |
| Users see familiar SSID with weak signal near lobby | Evil twin | WPA2/WPA3-Enterprise, certificate validation, wireless IDS, user training |
| Users repeatedly disconnect from Wi-Fi then join fake portal | Deauth abuse plus evil twin | Wireless monitoring, strong enterprise authentication, avoid auto-join to open networks |
| Help desk resets VPN password after suspicious call | Social engineering | Identity verification procedure, MFA reset controls, staff training, ticket evidence |
| User enters credentials into fake VPN page | Phishing | MFA, phishing-resistant authentication, domain monitoring, user reporting workflow |
Availability and Perimeter
| Symptom or evidence | Likely attack | Best mitigation direction |
|---|---|---|
| Internet circuit saturated by traffic from many sources | Volumetric DDoS | ISP coordination, scrubbing provider, CDN or anycast, rate limiting upstream |
| Firewall session table exhausted | State exhaustion DoS | Tune limits, rate limit, upstream filtering, capacity planning |
| Web app overwhelmed by expensive requests | Application-layer DoS | WAF, rate limiting, caching, application tuning |
| Public DNS receives amplified response traffic | Reflection or amplification | Provider mitigation, source validation, rate limiting, avoid open resolvers |
Management Plane and Credential Abuse
| Symptom or evidence | Likely problem | Best mitigation direction |
|---|---|---|
| Admin logins from unusual countries | Compromised credential or risky access | MFA, geofencing, conditional access, account review |
| Router changes made by shared admin account | Weak accountability | Named accounts, TACACS+, command authorization, accounting logs |
| SNMP community string observed in packet capture | Insecure management protocol | Use SNMPv3 with authentication and privacy |
| Management interface reachable from guest VLAN | Excessive exposure | ACLs, management VLAN, jump host, firewall rules |
PBQ Method
- Identify the affected layer: physical, wireless, Layer 2, IP, DNS, application, identity, or provider edge.
- Identify the asset and trust boundary: guest, user, server, management, cloud, or OT.
- Match evidence to a specific attack, not a broad fear.
- Select the control that blocks the attack path.
- Preserve visibility with logs, alerts, and validation tests.
Common Traps
- Using a firewall rule to solve a rogue DHCP problem on the same access VLAN may miss the source because DHCP discovery is local broadcast traffic.
- Enabling encryption does not stop a user from joining a fake SSID if certificate validation is ignored.
- DDoS filtering must happen before the bottleneck link when bandwidth is saturated.
- A mitigation table should include validation, such as testing from the guest VLAN or reviewing switch security counters.
- More controls are not always better if they do not address the observed path.
Test Your Knowledge
A PBQ shows user switch ports dynamically becoming trunks and unauthorized VLAN access. Which mitigation should be placed on the user ports?
A
B
C
D
Test Your Knowledge
A company Internet link is saturated by traffic from many networks before packets reach the firewall. Which mitigation is most relevant?
A
B
C
D
Test Your KnowledgeMulti-Select
Which attack-to-mitigation pairs are appropriate? Select three.
Select all that apply
Rogue DHCP: enable DHCP snooping and trust only uplink ports
ARP poisoning: use dynamic ARP inspection with valid bindings
Shared admin account: use named accounts with TACACS+ accounting
Evil twin: disable all certificate validation
MAC flooding: remove all switch port limits