Example 1 · Inline IPS Blocking a SQL Injection Attack
A web application server hosts a customer database. An attacker probes the login form and discovers it is vulnerable to SQL injection. The attacker crafts a payload designed to dump the user table. The organization has an IPS deployed inline between the firewall and the core switch.
Without IPS (no inline device):
10:14:22 — Attacker sends HTTP POST: username=' OR 1=1--&password=anything
10:14:22 — Packet reaches firewall: HTTP traffic on port 443, permitted
10:14:22 — Packet reaches web server
10:14:22 — Web application executes: SELECT * FROM users WHERE username='' OR 1=1--
10:14:22 — Query returns all 84,000 user records
10:14:23 — Attacker extracts full user table over next 3 minutes
Result: 84,000 user credentials exfiltrated in 3 minutes
Detection: access log anomaly found 6 hours later during routine review
With inline IPS (active monitoring):
10:14:22 — Attacker sends HTTP POST: username=' OR 1=1--&password=anything
10:14:22 — Packet reaches firewall: HTTP traffic on port 443, permitted
10:14:22 — Packet reaches IPS (inline)
10:14:22 — IPS inspects payload: matches SQL injection signature (SQLI-001)
10:14:22 — IPS drops packet; generates alert (HIGH severity, SQLI attempt, src: 203.0.113.44)
10:14:22 — Web server never receives the request
10:14:22 — SOC receives alert
10:14:45 — Analyst confirms: SQL injection attempt blocked; source IP blocked at firewall
Result: 0 records exfiltrated
Detection: real-time; 23 seconds from attack to IP block
The lesson: The firewall is not the right tool to block SQL injection — it permitted the packet because HTTP on port 443 is legitimate traffic. The IPS inspects the packet's payload, not just its header, and recognizes the malicious content. The inline position means the block happens before the web server ever processes the request. This is the core value of an IPS over a firewall: deep packet inspection at the application layer.
Example 2 · Fail-Open vs. Fail-Closed — Hospital Network IPS Failure
A regional hospital has an IPS deployed inline between the internet-facing firewall and the clinical network. The IPS fails at 11:30 PM due to a memory fault. The hospital has two different configurations being evaluated.
Configuration A — Fail-open:
11:30 PM — IPS memory fault; device becomes unavailable
11:30 PM — Traffic continues to flow through the device (fail-open behavior)
11:30 PM — Clinical workstations remain connected to EHR system
11:30 PM — ED physicians continue accessing patient records — no interruption
11:30 PM — SIEM alert: IPS health check failure detected
11:35 PM — On-call network engineer paged
11:50 PM — Engineer reboots IPS device; comes back online
11:50 PM — IPS resumes active monitoring
Clinical impact: zero — no downtime
Security impact: 20 minutes of uninspected traffic
Security posture during failure: firewall and endpoint controls still in place
Risk: attacker active during the 20-min window would not be detected by IPS
Configuration B — Fail-closed:
11:30 PM — IPS memory fault; device becomes unavailable
11:30 PM — Network link severs (fail-closed behavior)
11:30 PM — Clinical workstations lose connection to EHR system
11:30 PM — ED physicians cannot access patient records
11:30 PM — Hospital activates paper-based downtime procedures
11:31 PM — Network team paged (critical clinical system outage)
11:35 PM — Decision: bypass the IPS temporarily to restore clinical access
11:35 PM — IPS bypassed; clinical systems restored
11:50 PM — IPS rebooted; bypass removed; active monitoring resumes
Clinical impact: 5 minutes of EHR downtime; downtime procedures activated
Security impact: same 20 minutes of uninspected traffic (bypass required anyway)
Patient safety risk: clinical decisions made without record access during downtime
The lesson: For a hospital, fail-open is the clearly correct choice. The fail-closed configuration caused clinical disruption — an immediate patient safety risk — while providing no actual security benefit (the IPS had to be bypassed anyway to restore access). The security gap was identical in both scenarios (20 minutes of uninspected traffic), but fail-closed added a patient safety incident. For most healthcare environments, fail-open is the only acceptable configuration for any inline security device.
Example 3 · SPAN Port Detecting Lateral Movement — Internal Network Monitoring
A financial services firm deploys an IDS using a SPAN port on the core switch. The SPAN duplicates all traffic between internal VLANs and sends copies to the IDS for analysis. An attacker breaches a user workstation via a phishing email and begins lateral movement.
Monday 14:22 — User opens phishing attachment; macro executes
14:22 — Reverse shell established to attacker C2 (outbound HTTPS — not flagged by perimeter)
14:25 — Attacker begins internal reconnaissance from compromised workstation
14:25 — ARP scan: WORKSTATION-FIN-07 probes 254 IPs in 192.168.10.0/24
14:25 — SPAN port sends copy of all ARP traffic to IDS
14:25 — IDS matches anomaly signature: 254 ARP requests in 2 seconds from single host
14:25 — IDS generates HIGH alert: "Internal port scan — WORKSTATION-FIN-07"
14:26 — SOC analyst receives alert
14:27 — Analyst confirms: unusual ARP pattern from workstation that should have no reason to scan
14:29 — Workstation isolated at switch port level
14:30 — WORKSTATION-FIN-07 offline; lateral movement stopped
Detection: 3 minutes from start of lateral movement to isolation
Packets blocked: 0 (IDS is passive — the ARP requests reached the network)
Lateral movement prevented: yes — workstation isolated before attacker pivoted
Note: IDS could NOT block the ARP packets in real time. But the alert allowed the SOC
to manually isolate the workstation — achieving prevention through human response.
The lesson: A passive IDS cannot stop packets, but rapid alert-to-response can still prevent successful lateral movement. The 3-minute detection-to-isolation cycle was faster than the attacker's reconnaissance cycle. This demonstrates the operational model for passive IDS: detection enables fast human response, which achieves the prevention goal. For internal network monitoring (east-west traffic), a passive IDS on a SPAN port is often the practical deployment — inline placement of an IPS on every internal segment is expensive and architecturally complex.
Example 4 · IPS False Positive — Blocking Legitimate Database Traffic
A retail company installs a new IPS inline between their application servers and their database servers. The IPS is deployed with default signatures at maximum sensitivity. The following morning, the e-commerce application begins throwing database connection errors.
08:00 AM — IPS goes live with default signatures
08:01 AM — E-commerce application begins database queries for product catalog
08:01 AM — IPS matches product search query against SQLI-Generic-002 signature
(signature triggered by SELECT statements with WHERE clauses containing user input)
08:01 AM — IPS blocks database traffic — false positive
08:01 AM — Application returns 500 errors to customers
08:15 AM — Help desk receives flood of customer complaints
08:20 AM — Network team identifies IPS blocks in firewall log
08:25 AM — Decision: put IPS in "alert only" mode (passive) to restore service
08:25 AM — Application traffic restored; errors stop
Business impact: 24 minutes of e-commerce downtime; estimated $45,000 in lost orders
Root cause: overly broad signature matched legitimate parameterized queries
Tuning process (over the next 2 weeks):
1. Analyze all IPS alert logs from "alert only" mode
2. Identify which signatures fire on legitimate application traffic
3. Create exceptions for known-good traffic patterns (app server IP → DB server, port 5432)
4. Re-enable blocking mode for signatures that do not fire on legitimate traffic
5. Set remaining broad signatures to alert-only rather than block
6. Return IPS to inline blocking mode with tuned signature set
The lesson: Deploying an IPS with default signatures in blocking mode without prior testing is a common source of outages. The correct deployment process: (1) deploy in passive/alert-only mode first; (2) observe which signatures fire and whether they are legitimate or false positives; (3) tune exceptions and adjust sensitivity; (4) enable blocking only for high-confidence signatures; (5) monitor continuously. The initial passive phase is not optional — it prevents false-positive outages. This is also why some organizations permanently run IPS in passive mode for segments with complex application traffic.
Exam Scenario · Choosing the Right IDS/IPS Configuration
Scenario: A security architect is designing the monitoring strategy for a manufacturing company. The network has four segments: (1) an internet-facing web application, (2) a production database cluster, (3) an internal corporate network with 400 workstations, and (4) a SCADA network controlling physical manufacturing equipment. Answer the following.
A. The web application segment receives 10,000 requests per second during peak hours. The security team wants to block SQL injection and XSS attacks in real time. What configuration is needed, and what must the team verify before going live?
An IPS in active (inline) monitoring mode is required — passive monitoring cannot block attacks in real time. The IPS must be placed between the firewall and the web application servers. Before going live in blocking mode, the team must: (1) deploy in passive/alert-only mode and observe what signatures fire against normal production traffic; (2) tune exceptions for any legitimate traffic that triggers signatures; (3) verify the IPS hardware can sustain 10,000 requests/second throughput at peak with inspection enabled (throughput capacity is a hardware spec — an undersized IPS will drop packets or become a bottleneck); (4) confirm the fail-open/fail-closed configuration — fail-open is typically preferred for internet-facing segments to prevent the IPS from causing a service outage.
B. The SCADA network controls physical manufacturing equipment. Any disruption to network connectivity could cause production line failures. The security team needs visibility into SCADA traffic to detect anomalies, but cannot risk any downtime from a security device failure. What is the correct monitoring approach?
Passive monitoring via SPAN port or network tap is the only acceptable configuration for this segment. Because the SCADA network cannot tolerate any downtime from a security device failure, an inline IPS (even fail-open) introduces unacceptable risk — fail-open behavior still requires brief processing time during a crash, and fail-closed would halt production. A SPAN port on the SCADA switch sends traffic copies to an IDS for analysis. The IDS generates alerts on anomalous SCADA traffic (unexpected commands, unusual timing, unauthorized source IPs) without any possibility of disrupting actual traffic. The limitation — traffic cannot be blocked in real time — is accepted in exchange for zero availability risk. Any blocking response must be manual (engineer isolates the affected device after investigating the IDS alert).
C. The internal corporate network has 400 workstations. An attacker breaches one workstation via phishing. The security team wants to detect lateral movement quickly. They have two options: an inline IPS on the core switch, or a SPAN-based IDS on the core switch. The inline IPS would add 2ms latency to all internal traffic. What should they choose and why?
A SPAN-based IDS is likely the better choice for internal lateral movement detection in this context. The reasons: (1) 2ms latency added to all internal traffic affects every application, every file transfer, every database query — internal network latency is very visible to users; (2) Lateral movement detection is primarily an alert-and-investigate workflow — the goal is fast detection followed by manual isolation, not automated inline blocking; (3) The SPAN-based IDS provides identical detection capability for lateral movement signatures (port scans, unusual connection patterns, credential harvesting traffic); (4) A mistuned inline IPS on the core switch would affect all 400 workstations — the blast radius of a false positive is the entire internal network. However, if the organization has a high-maturity SOC with rapid automated response capabilities and has thoroughly tuned the IPS, inline blocking could be deployed for high-confidence signatures while maintaining passive mode for broader anomaly detection.