Why the traditional firewall failed: The organization cannot block TCP/443 entirely — that would also break all HTTPS web browsing, online banking, and every cloud application. The traditional firewall has no way to distinguish YouTube traffic from legitimate HTTPS business traffic because both arrive on TCP/443. Blocking the port blocks everything; allowing the port allows everything.
What the NGFW does differently: The NGFW decodes the HTTPS traffic using deep packet inspection, identifies the application as YouTube (even though it arrives on TCP/443), and applies the policy to the application, not the port. The rule becomes: allow TCP/443 for business applications; deny TCP/443 specifically for YouTube and other personal streaming applications.
The outcome: YouTube streaming is blocked. HTTPS traffic to internal business systems, cloud productivity apps, and legitimate web browsing continues unaffected. The NGFW's application-layer awareness solved a problem that was impossible to address with port-based rules.
The lesson: Traditional firewalls and NGFWs are fundamentally different tools even though both are called "firewalls." When a policy requires distinguishing between applications that share the same port, an NGFW is required. Port-based rules cannot achieve this level of control.
Diagnosing the problem: The rules are evaluated top to bottom. Rule 1 allows HTTPS from any source. Rule 2 allows SSH from 10.0.1.0/24. But what protocol is SSH? TCP/22. What protocol is HTTPS? TCP/443. These are different ports — rule 1 would not match SSH traffic. So how did the penetration tester connect?
The root cause: On closer inspection, rule 1 was written as "Allow TCP from any" without specifying a destination port. The administrator intended it to mean "allow HTTPS" but wrote it as "allow all TCP." Because the rule matches before rule 3 (deny SSH from any), the penetration tester's SSH connection matched rule 1 (allow all TCP) and was permitted. Rule 3 was never reached for that traffic.
The correct rule order: (1) Allow TCP/443 from any [specific HTTPS rule]; (2) Allow TCP/22 from 10.0.1.0/24 [specific allowed SSH source]; (3) Deny TCP/22 from any [block all other SSH] — and the implicit deny handles everything else.
The lesson: Firewall rule mistakes are almost always about order and specificity. A broad allow rule placed above a specific deny rule silently overrides the deny. The implicit deny only catches traffic that reaches the bottom of the rule list — if a broad allow rule captures traffic first, the deny rules below it are irrelevant for that traffic. Always write rules from most specific to least specific.
Why Option A is dangerous: The web server must be accessible from the internet. Placing it on the internal network means internet traffic must be routed to the internal network. If the web server is compromised, the attacker is now on the internal network with direct access to the payment card database. One compromised server leads directly to the data breach.
How Option B (screened subnet) limits the blast radius: The web server is placed in the screened subnet. The firewall allows internet traffic to reach the web server on TCP/443. The database remains on the internal network. A firewall rule allows only TCP/3306 (MySQL) from the web server's IP to the database server IP — the minimum required for the web application to function.
What happens when the web server is compromised: An attacker exploits a vulnerability in the web application and gains control of the web server. They now have full control of a machine in the screened subnet. They attempt to pivot to the database server. The firewall blocks all connection attempts from the web server to the internal network except TCP/3306 to the specific database IP. The attacker can query the database through the existing application logic, but cannot connect directly to other internal systems, run lateral movement tools, or reach the internal network at all.
The lesson: A screened subnet does not prevent a breach of the public-facing server — it contains the breach. The firewall architecture limits what an attacker can do after gaining a foothold in the DMZ, significantly reducing the risk to internal systems and data.
What the IPS signature does: The Conficker signature describes a specific sequence of bytes that appears in Conficker's exploit payload. Every SMB packet passing through the NGFW is inspected against this signature. When a workstation infected with Conficker sends an exploit packet to another internal machine, the packet traverses the core switch and passes the NGFW. The IPS matches the Conficker signature, blocks the packet, and generates an alert.
What the security team sees: An alert identifying the source IP (the infected workstation), the destination IP (the target being probed), the rule that triggered, and the signature name (Conficker). The security team isolates the infected workstation, scans the environment, and patches the remaining vulnerable systems.
The limitation the exam tests: The signature-based IPS caught Conficker because a signature existed. If a new worm variant modifies even a few bytes in the payload to evade the signature, the same IPS fails to detect it. The signature database must be kept current — an outdated IPS is significantly less effective than a current one. And for completely new zero-day exploits, signature-based detection provides no protection at all.
The lesson: Signature-based IPS is highly effective against known threats but is entirely dependent on the quality and currency of its signature database. The moment a threat evolves past the known signatures, the IPS is blind to it.
Why signature-based detection fails here: The exploit was just discovered. The IPS vendor has not yet written a signature for it. No pattern in the current signature database matches the attack. A pure signature-based IPS allows the SQL injection to pass through undetected.
How anomaly-based detection catches it: The baseline shows that normal queries between the web server and database return an average of 2–5 KB of data per query. The SQL injection causes the database to return the entire customer table — 40 MB in a single response. The anomaly-based engine flags this: the query response is 8,000 times larger than the baseline average. Additionally, the query structure itself is anomalous — the specific SQL functions and syntax patterns deviate significantly from the baseline. Both anomalies trigger alerts.
The tradeoff the IPS team manages: Three days after deploying the anomaly threshold that caught this attack, the security team receives an alert about a legitimate database report job that was moved to business hours from its usual overnight window. The report queries return large result sets that exceed the anomaly threshold. This is a false positive — legitimate traffic that looks anomalous. The team adjusts the rule to exclude the report job's scheduled window and IP, maintaining detection coverage without blocking legitimate work.
The lesson: Anomaly-based detection fills the gap left by signature-based detection: it can catch zero-day attacks and novel exploits that have no signatures. The tradeoff is more false positives and the tuning overhead to manage them. An effective IPS strategy uses both methods together — signatures for known threats, anomaly detection for unknowns.