IDS vs. IPS — Core Comparison
| Attribute | IDS (Intrusion Detection System) | IPS (Intrusion Prevention System) |
|---|---|---|
| Primary function | Detect and alert | Detect and block |
| Action on threat | Generates alert / log entry; traffic continues to destination | Drops malicious packet; traffic never reaches destination |
| Network position | Out-of-band (passive) — receives traffic copy | Inline (active) — sits in traffic path |
| Effect on traffic | None — does not touch the traffic path | Adds latency; failure behavior affects network availability |
| Failure impact | Monitoring stops; network unaffected | Depends on failure mode: fail-open (traffic continues) or fail-closed (traffic stops) |
| False positive impact | Spurious alert (annoyance; no operational impact) | Blocked legitimate traffic (operational incident) |
| False negative impact | Attack not detected (same as IPS) | Attack not blocked AND not detected |
| Best use case | When inline placement is not feasible; high-sensitivity environments where false positives would cause disruption; forensics and full packet capture | When active prevention is required; standard perimeter and segment boundary deployment |
| Real-time prevention? | No | Yes (inline only) |
Key insight: An IPS deployed in passive (out-of-band) mode behaves identically to an IDS — it can alert but not block. The device label matters less than the deployment position.
Failure Modes — Fail-Open vs. Fail-Closed
| Attribute | Fail-Open | Fail-Closed |
|---|---|---|
| What happens on device failure | Traffic continues to flow through the device uninspected | Traffic stops; network link is severed |
| Security impact | No inspection during the failure window; attacks may pass undetected | No uninspected traffic passes; protected segment is fully isolated |
| Availability impact | Network remains up; users unaffected (beyond loss of security) | Network goes down; users and services behind the device are unreachable |
| Preferred when | Availability is prioritized; other security layers (firewalls, endpoint protection) provide defense in depth; typical enterprise networks | Security is prioritized over availability; classified networks, critical infrastructure, high-value targets where uninspected access is unacceptable |
| Operational requirement | Rapid detection and repair of device failure; monitoring to detect when security inspection stops | Rapid repair or bypass procedure; documented failover plan to restore network when device is down |
| Risk accepted | Brief window of uninspected traffic during failure | Network downtime until device is restored |
| Most common choice | Yes — most enterprise environments prefer fail-open | Less common; high-security/classified environments |
Active vs. Passive Monitoring — Configuration Reference
| Attribute | Active Monitoring (Inline) | Passive Monitoring (Out-of-Band) |
|---|---|---|
| Device position | In the traffic path between network segments | Connected to a SPAN port or network tap; not in the traffic path |
| Traffic received | All actual traffic — the device forwards or drops each packet | Copies of traffic — the original continues to its destination regardless |
| Can block in real time? | Yes — drops packets before they reach the destination | No — original packet is already delivered before analysis completes |
| Effect on availability | Device failure affects network availability (fail-open/fail-closed) | Device failure has no effect on network availability |
| Latency added | Small but measurable — every packet is processed before forwarding | None — monitoring device is not in the forwarding path |
| Typical use | IPS for active prevention at network boundaries | IDS for monitoring; passive IPS; forensic capture; compliance logging |
| Equivalent behavior | IPS (prevention) | IDS (detection only), even if device hardware is an IPS |
Traffic Copy Methods — SPAN vs. Physical Tap
| Attribute | SPAN Port (Port Mirror) | Physical Network Tap |
|---|---|---|
| How it works | Switch software duplicates specified port traffic to a monitoring port | Hardware device inserted into a cable; passively copies all signals at Layer 1 |
| Implementation | Software configuration on a managed switch — no new hardware required | Requires physical hardware installation in the cable run |
| Packet capture fidelity | Can drop packets under heavy load (SPAN has lower priority than normal forwarding) | 100% fidelity — captures every bit on the wire; never drops packets |
| Effect on network if device fails | None — SPAN is a software copy; original traffic unaffected | None — passive taps are designed to pass traffic even with power loss |
| Flexibility | Easily reconfigured to monitor different ports via software change | Fixed to a specific cable segment; reconfiguration requires physical work |
| Best for | General monitoring; easy deployment; environments where occasional dropped copies are acceptable | Forensics; compliance; high-fidelity monitoring on critical links where no packets can be missed |
| Cost | No additional hardware cost if switch supports SPAN | Hardware cost per tap location |
Detection Methods — Signature vs. Anomaly
| Attribute | Signature-Based | Anomaly-Based |
|---|---|---|
| How it detects | Matches traffic against a database of known attack patterns | Compares traffic to a baseline of normal behavior; flags deviations |
| Zero-day detection | No — cannot detect attacks with no existing signature | Yes — novel attacks deviate from normal behavior even without a signature |
| False positive rate | Low for known threats — if the signature matches, the threat is known | Higher — legitimate but unusual activity can trigger alerts |
| Maintenance required | Continuous signature updates as new threats are discovered | Ongoing baseline calibration; re-baselining after major network changes |
| Evasion risk | Attackers can modify exploits to avoid matching known signatures | Harder to evade — attacker must mimic normal behavior to avoid detection |
| Best for | Known malware families, known exploit frameworks, compliance requirements for specific threat detection | Detecting novel attacks, insider threats, behavioral anomalies, C2 communications with unusual patterns |
IPS Traffic Flow — Active vs. Passive Paths
Understanding the traffic path is the foundation of IDS/IPS questions. Memorize which path allows blocking and which does not.
Active (inline) path:
Internet → Firewall → [IPS inline] → Core Switch → Internal hosts
↑
Malicious packet dropped HERE
Never reaches the core switch
Passive (out-of-band) path:
Internet → Firewall → Core Switch → Internal hosts (original traffic — always delivered)
↓ SPAN copy
IDS/IPS (analysis only — generates alert, cannot block)
The rule: If the monitoring device is in the path (between two devices), it is active and can block. If the monitoring device is receiving a copy (connected to a SPAN port or tap), it is passive and can only alert. The position in the network determines the capability.