The exam's most common IDS/IPS trap: students assume IDS = old/simple device, IPS = modern/advanced device. The actual distinction is entirely about network position and blocking capability.
- Inline position (in the traffic path): The device can block. It is operating as an IPS regardless of what the label says. Internet → Firewall → [device] → Switch — the device is between two segments.
- Passive position (SPAN port or tap): The device can only alert. It is operating as an IDS regardless of what the label says. The device receives copies; it cannot reach back and block the original.
An IPS appliance deployed on a SPAN port = IDS behavior. An IDS appliance deployed inline = IPS behavior (though unusual). The hardware is secondary to the network position.
The exam question pattern: "An organization uses an IPS connected to a SPAN port. A malware packet passes through the switch. What does the IPS do?" → It generates an alert. It cannot block — it is receiving a copy, not the original traffic.
Memory trick: Think of it as a physical analogy. A passive monitor watches traffic on a TV screen — it can describe what it sees but cannot reach through the screen to grab a packet. An inline device is a checkpoint — traffic must hand its "papers" over before passing through. Only the checkpoint can deny entry.
Students mix up fail-open and fail-closed, especially under exam pressure. The names seem counterintuitive until you anchor the terms to what "opens" and "closes."
- Fail-open: The device fails → the traffic path opens → traffic flows freely → network stays up, but uninspected. "Open" = the door is open; traffic walks through unexamined.
- Fail-closed: The device fails → the traffic path closes → traffic stops → network goes down, but nothing passes uninspected. "Closed" = the door slams shut; nothing gets through.
Which is preferred and when:
- Most networks → fail-open. Availability matters more than a brief uninspected window. Other security controls (firewalls, endpoint protection, access controls) are still in place during the failure.
- High-security environments → fail-closed. Classified networks, critical infrastructure, financial systems where uninspected access is worse than downtime. The organization must have rapid repair procedures.
- Clinical/medical environments → fail-open. Patient safety requires continuous network availability — downtime from a fail-closed device is a direct safety risk.
The exam question pattern: "An inline IPS fails. Network traffic continues to pass without inspection. Which failure mode is configured?" → Fail-open. "An inline IPS fails and all traffic to the protected network segment stops. Which failure mode is configured?" → Fail-closed.
Both SPAN and physical taps deliver traffic copies to passive monitoring devices. The exam tests whether students know the critical operational difference: packet drop behavior under load.
SPAN port behavior under load:
- SPAN copying is lower priority than regular switch forwarding
- When the switch's backplane is saturated (heavy traffic), SPAN copies are dropped first
- The switch preserves normal traffic; the monitoring device receives incomplete data
- During the moments most likely to contain attack traffic (high-load periods, DDoS), SPAN monitoring becomes least reliable
Physical tap behavior under load:
- Operates at Layer 1 — it is electrical/optical signal copying, not software-controlled packet duplication
- Load on the network does not affect the tap — it copies every signal on the wire regardless
- 100% packet fidelity even during traffic peaks
- Cannot drop copies — the physics of the signal copy are independent of traffic volume
The exam question pattern: "A forensic investigation requires complete packet capture of a 10Gbps link with no missed packets. Which method should be used?" → Physical network tap. "Which monitoring method is simpler to deploy but may drop packet copies under heavy load?" → SPAN port.
Trade-offs to know:
- SPAN: easy (software config), flexible (reconfigurable), free (no hardware), but drops packets at high load
- Physical tap: reliable (never drops), high-fidelity (100% capture), but requires hardware installation and cannot be reconfigured via software
A common exam scenario presents an IPS that starts blocking legitimate business traffic immediately after deployment. The test-taker must identify why this happened and what the correct deployment process should have been.
Why default IPS signatures cause outages:
- Signature databases contain generic rules designed to catch broad categories of attacks
- These broad rules frequently match legitimate application traffic — especially complex business applications that use unusual query patterns, large payloads, or non-standard protocols
- A database application running complex SELECT queries may look like SQL injection to a generic signature
- A large file upload may look like a buffer overflow
- An application health check with many parameters may match an XSS signature
The correct IPS deployment sequence:
- Deploy in passive/alert-only mode: The IPS is inline but configured to alert rather than block. All traffic flows normally; the IPS logs what it would have blocked.
- Observe for 1–2 weeks: Review what signatures are firing. Identify which alerts correspond to legitimate business traffic (false positives) vs. actual threats.
- Tune signatures: Create exceptions for known-good traffic. Adjust signature sensitivity. Disable signatures that generate only false positives for this environment.
- Enable blocking on high-confidence signatures: Switch well-tuned signatures from alert-only to block mode. Leave broad or sensitive signatures in alert-only mode.
- Monitor continuously: New applications and traffic patterns will generate new false positives. Tuning is an ongoing process, not a one-time task.
The exam question pattern: "A company deploys an IPS in blocking mode with default signatures. Shortly after, legitimate business application traffic is blocked. What should the organization have done first?" → Deployed in passive/alert-only mode and tuned signatures before enabling blocking.
Scenario A: A university IT team is designing intrusion detection for three network segments: (1) the student Wi-Fi (5,000+ devices, unpredictable traffic), (2) the research data network (sensitive research data, high-speed file transfers), and (3) the administrative network (financial and HR systems, 200 employees). For each segment, recommend: active or passive monitoring, and fail-open or fail-closed if inline. Justify each recommendation.
Show Answer
1. Student Wi-Fi — Passive monitoring (SPAN port):
Student Wi-Fi has inherently unpredictable, high-volume traffic from thousands of devices running a huge variety of applications. An inline IPS on this segment would generate massive false positive rates — gaming traffic, video streaming, peer-to-peer applications, and thousands of unique application signatures will constantly trigger generic attack rules. Passive monitoring with alert-only provides visibility into genuine threats (malware infections, botnet activity, illicit scanning) without causing service disruptions from false positives. The university's obligation to students is to provide working internet access — false-positive outages on a student Wi-Fi segment would be immediately visible and politically problematic. No fail-open/fail-closed consideration needed since the device is not inline.
2. Research data network — Passive monitoring (physical network tap):
High-speed research file transfers (large genomic datasets, simulation outputs, scientific imaging) are particularly likely to trigger buffer overflow and large-payload signatures in an IPS. False positives would disrupt critical research operations. More importantly, research networks often run specialized protocols (HPC interconnects, research-specific data transfer tools) that IPS signatures know nothing about — these will generate false positives constantly. A physical network tap (not SPAN) is preferred because the high-speed nature of research data links means SPAN may drop copies under load, reducing monitoring fidelity. Passive monitoring provides the security team with visibility into data exfiltration attempts and anomalous access patterns without risking research disruptions.
3. Administrative network — Active monitoring (inline IPS), fail-open:
Financial and HR systems are high-value targets that warrant inline IPS prevention. A credential stuffing attack against the HR portal or a SQL injection against the financial database represents a significant data breach risk — the ability to block in real time is worth the inline deployment risk. The IPS should be deployed in passive mode first to tune signatures against the administrative applications before enabling blocking. Fail-open is the correct failure mode: if the IPS fails, the administrative network stays operational (with firewall and endpoint controls still in place). Fail-closed would lock out all 200 employees from financial and HR systems on every IPS failure — an unacceptable operational impact.
Scenario B: A security analyst reviews IPS logs and discovers that over the past 30 days, the IPS has generated 14,000 alerts. Of these, the analyst estimates that 12,600 (90%) were false positives against legitimate application traffic, and 1,400 (10%) were genuine threat detections. The IPS is in passive/alert-only mode. The CISO asks: "Should we enable blocking on all signatures to stop the 1,400 real threats?" Advise the CISO on whether to enable blocking on all signatures, and explain the consequences of doing so without additional tuning.
Show Answer
Recommendation: Do NOT enable blocking on all signatures without tuning first.
The consequence of enabling blocking without tuning:
If blocking is enabled across all 14,000 alert signatures without tuning, the IPS will block 12,600 instances of legitimate traffic per month — an average of 420 false-positive blocking events per day. Each blocking event means a legitimate application transaction fails: a user gets an error, a business process stops, a file transfer is interrupted. The 90% false positive rate means the IPS would be causing 9x more operational incidents than the actual threats it stops.
The correct approach — selective blocking after tuning:
- Categorize the 14,000 alerts by signature: Which signatures are firing only on legitimate traffic? Which signatures are detecting genuine threats with no false positives? Which signatures have a mix?
- Enable blocking on high-confidence signatures: Signatures that fired only on genuine attacks (the 1,400 real detections) and never on legitimate traffic can be safely enabled in blocking mode. These might be 10–20 specific signature IDs covering specific CVEs or known malware patterns.
- Tune or disable the high false-positive signatures: Signatures that fired 12,600 times on legitimate traffic should be: (a) disabled if they never detect real threats in this environment, (b) refined with exceptions for known-good traffic (allow application server IP range to send large SQL queries), or (c) kept in alert-only mode for the analyst to review manually.
- Set blocking thresholds for behavioral rules: Anomaly rules (port scan detection, connection rate limits) should have thresholds tuned to the normal behavior of this environment — a research network will have different normal behavior than a corporate office network.
The goal is not to block all 14,000 alerts — it is to block the 1,400 real threats with high precision and minimal collateral disruption to legitimate traffic. An IPS with a 90% false positive rate deployed in blocking mode is worse than no IPS — it actively disrupts the business it is supposed to protect.
Scenario C: A financial services company operates a trading platform. The inline IPS between the trading application and the database has been running for 6 months with a tuned signature set. The trading platform processes 50,000 transactions per second during market hours. A new vulnerability is disclosed in the database software (CVE-2024-XXXX) with a working exploit. The security team wants to add an IPS signature to detect/block exploitation attempts. Describe the risks of adding a new untuned signature to a production inline IPS at 50,000 TPS, and outline the safest process for deploying the new signature.
Show Answer
Risks of adding an untuned signature in blocking mode to a 50,000 TPS production IPS:
- False positive at 50,000 TPS is catastrophic: If the new signature has even a 0.01% false positive rate, it will block 5 legitimate transactions per second during peak trading. Over a 6.5-hour trading day (23,400 seconds), that is 117,000 blocked legitimate trades — regulatory violations, financial losses, and client complaints.
- IPS throughput impact: A new complex signature adds processing overhead to every packet inspection. At 50,000 TPS, even microseconds of additional latency per packet can cause latency-sensitive trading to miss execution windows. Trading firms measure latency in microseconds — an IPS that adds milliseconds is a competitive disadvantage.
- Unknown interaction with existing exceptions: The new signature may interact with existing exception rules in unexpected ways — either bypassing protections or creating new false positives in combinations the signature writer did not anticipate.
Safest deployment process for the new signature:
- Non-trading hours first: Add the signature in alert-only mode during non-trading hours (overnight, weekend) and observe what it fires on against normal (low-volume) trading system traffic. Check for false positives against database health checks, application monitoring traffic, and scheduled maintenance queries.
- Staging environment validation: If a staging environment exists that mirrors production traffic patterns, deploy the signature in blocking mode there and run full regression testing of the trading application against it.
- Alert-only during first trading session: Add the signature in alert-only mode during the first live trading session. Monitor every alert in real time. Have the security team on standby with the authority to disable the signature immediately if false positives appear.
- Analyze after-session: Review all alerts from the trading session. Confirm that all alerts correspond to genuine exploitation attempts (there should be zero if the exchange is not under active attack). Confirm zero false positives against legitimate trading traffic.
- Enable blocking with a rollback plan: Enable blocking mode with an agreed rollback procedure: if any trading operations team reports anomalous transaction failures, the signature reverts to alert-only within 60 seconds. The rollback authority and procedure should be agreed before enabling blocking.
The urgency of the CVE (a working exploit exists) is real — but deploying a blocking IPS change without validation on a 50,000 TPS trading platform creates risks that may exceed the exploitation risk. The correct balance: alert-only detection provides immediate visibility into exploitation attempts while the signature is being validated for safe blocking deployment.