The Core Difference — Detection vs Prevention
The fundamental distinction between IDS and IPS is what they do when they identify a threat. An IDS (Intrusion Detection System) passively monitors network traffic or host activity, compares it against known threat signatures or behavioural baselines, and generates alerts when suspicious activity is detected. It does not interfere with traffic — it only observes and reports. A security analyst reviews the alerts and decides whether and how to respond.
An IPS (Intrusion Prevention System) sits inline with traffic — all traffic flows through it — and can actively drop packets, terminate connections, or modify traffic in real time when a threat is detected. The IPS doesn't wait for human review; it acts automatically based on configured policies. This makes IPS more effective at stopping attacks but introduces risk: a misconfigured IPS or a false positive can block legitimate traffic, causing outages.
IDS vs IPS — Key Differences
| Characteristic | IDS | IPS |
|---|---|---|
| Response to threats | Alerts / logs only | Blocks, drops, or modifies traffic |
| Network placement | Out-of-band (tap or mirror port) | Inline — all traffic passes through |
| Impact on traffic | None — passive monitoring | Adds latency; can block legitimate traffic |
| False positive risk | Low impact — generates alert only | High impact — blocks legitimate traffic |
| Response speed | Human review required | Automated real-time response |
| Failure mode | Fails open — traffic continues | Fail-open or fail-closed (configurable) |
| Primary use case | Forensics, compliance, visibility | Active threat prevention, blocking attacks |
Network-Based vs Host-Based
Both IDS and IPS come in two deployment variants that the exam tests separately:
NIDS/NIPS (Network-based) monitors traffic flowing across a network segment — either by connecting to a span/mirror port on a switch (NIDS) or by sitting inline between network segments (NIPS). Network-based systems provide visibility into all traffic traversing that network segment, regardless of which hosts are communicating. They're blind to encrypted traffic (unless combined with TLS inspection) and cannot see traffic that doesn't cross the monitored segment.
HIDS/HIPS (Host-based) runs as software on an individual endpoint — a server, workstation, or cloud instance. It monitors activity on that specific host: process execution, file system changes, registry modifications, system calls, and local network connections. Host-based systems can inspect encrypted traffic (because they see it before encryption and after decryption on the endpoint) and can detect attacks that originate from local processes. The trade-off is that they only protect the host they're installed on and consume endpoint resources.
A comprehensive security architecture uses both: NIDS/NIPS at network chokepoints (internet perimeter, between network zones, before critical servers) and HIDS/HIPS on critical endpoints (domain controllers, database servers, privileged workstations).
Detection Methods — Signature vs Anomaly vs Policy
Signature-based detection compares observed traffic or activity against a database of known attack signatures. If traffic matches a signature (a known SQL injection pattern, a specific malware command-and-control beacon, a recognisable exploit attempt), an alert is triggered or the traffic is blocked. Signature-based detection is highly accurate for known threats and generates few false positives — but it cannot detect novel (zero-day) attacks for which no signature exists yet. Signatures must be updated regularly to remain effective.
Anomaly-based detection (also called behaviour-based or heuristic detection) establishes a baseline of normal activity and alerts on deviations from that baseline. A user who normally downloads 10 MB of data per day suddenly transferring 10 GB would trigger an anomaly alert. This approach can detect zero-day attacks and insider threats that signature-based systems miss, but it generates significantly more false positives — normal behaviour changes (end of quarter data exports, system updates) can look like anomalies.
Policy-based detection evaluates traffic against administrator-defined rules — not signatures of known attacks, but explicit policies. "No SSH traffic should leave the network" is a policy — any SSH connection going outbound triggers a policy violation alert. Policy-based detection requires the administrator to define the rules explicitly, but generates very precise alerts for specific policy violations.
False positive: the IDS/IPS flags legitimate traffic as malicious — the attack didn't happen but the system said it did. Impact on IPS: blocks legitimate traffic, potential outage. False negative: the IDS/IPS misses a real attack — the attack happened but the system didn't detect it. False negatives with IDS = missed alerts, analyst doesn't know to investigate. False negatives with IPS = attack succeeds undetected. The scenario "which is more dangerous, a false positive or false negative?" has no universal answer — it depends on context. For an IPS protecting a critical system, false negatives are catastrophic. For an IPS on a production network, false positives can cause outages.
Where IDS and IPS Sit in the Network
Network placement determines what traffic each system sees. A common enterprise architecture: an NIPS at the internet perimeter, inline between the firewall and the DMZ, inspects all inbound and outbound internet traffic for known attack patterns. A NIDS on a span port of the core switch monitors internal east-west traffic for lateral movement and insider threats — it's out-of-band to avoid affecting production traffic. HIPS on servers (especially domain controllers and database servers) provides host-level protection and can detect attacks that arrive via encrypted channels or originate from internal networks.
The distinction between firewall and IPS is important for the exam. A firewall enforces access control based on rules (allow or deny traffic based on source/destination IP, port, protocol) — it doesn't analyse the content of traffic. An IPS performs deep packet inspection — it looks inside packets at the payload and application-layer content. A next-generation firewall (NGFW) combines both functions.
Fail-Open vs Fail-Closed
When an inline IPS device fails (hardware failure, software crash, power loss), it must decide what to do with the traffic it can no longer inspect. Fail-open means the device passes all traffic uninspected — network connectivity is maintained but threat detection stops. Fail-closed means the device drops all traffic — the network goes down but no uninspected traffic passes.
The right choice depends on context. A hospital network might choose fail-open to maintain life-critical network connectivity even at the cost of security. A financial institution with extreme security requirements might choose fail-closed to ensure no uninspected traffic reaches its core systems. On the exam, "fail-open prioritises availability" and "fail-closed prioritises security" is the framework for choosing between them in scenarios.
Exam Scenarios
Protocol Analyzers and Packet Captures in IDS Context
When an IDS/IPS generates an alert, the next step is typically to examine the actual network traffic that triggered it. Protocol analyzers (packet analyzers, packet sniffers) capture raw network traffic for detailed inspection. Wireshark is the most widely used tool — it captures packets, decodes protocol fields, and allows filtering to isolate specific conversations.
IDS systems often integrate with packet capture infrastructure to automatically collect full packet captures triggered by alerts — a practice called trigger-based packet capture or full packet capture (FPC). When an IDS signature fires, the system captures not just the alerting packet but a configurable window of traffic before and after the event, giving analysts the full context of the network conversation. This is essential for distinguishing genuine attacks from IDS evasion attempts (where attackers deliberately craft traffic to trigger alerts as cover for the real attack in adjacent packets).
For exam scenarios: Wireshark is the tool for capturing and analyzing network traffic at the packet level. A network tap (passive hardware device that copies traffic from a network link) or SPAN port (switch port configured to mirror traffic from other ports) is required to capture traffic from a network link where you are not the endpoint. If a scenario asks how a technician can capture traffic between two specific hosts without modifying those hosts' configurations, the answer involves a network tap or SPAN port feeding a capture station running Wireshark or a similar tool. SPAN ports only mirror traffic within a single switch; taps are needed for traffic between switches or on specific physical links.
Network Traffic Analysis (NTA)
Network Traffic Analysis (NTA) — also called Network Detection and Response (NDR) — is a detection approach that analyzes network flow data and packet captures to identify threats based on communication patterns rather than endpoint activity. Where EDR watches what happens on individual systems, NTA watches what happens between systems across the network. Together they provide complementary visibility: EDR catches malware execution and file operations, NTA catches lateral movement, data exfiltration, and communications between compromised systems.
NTA tools ingest NetFlow, IPFIX, or sFlow data from routers and switches — summarized records of network conversations (source IP, destination IP, port, bytes transferred, duration) without capturing full packet contents. This provides scalable visibility into network patterns across the entire infrastructure without the storage requirements of full packet capture. Anomaly detection algorithms baseline normal communication patterns and alert on deviations: a workstation that suddenly starts communicating with 50 internal servers it has never contacted (lateral movement), a server sending 10 GB overnight to an unfamiliar external IP (data exfiltration), or DNS queries to domains with high entropy names (DNS tunneling or DGA domains from malware).
The relationship between NTA and IDS/IPS: IDS/IPS focuses on detecting known attack signatures and enforcing policies on specific traffic flows in real time; NTA focuses on detecting behavioral anomalies in aggregate traffic patterns over time. Both are valuable in an enterprise security stack, and both feed into SIEM for correlation. The exam tests IDS/IPS as the primary network detection technology, but understanding NTA provides context for why network monitoring extends beyond traditional IDS into behavioral analytics.
Honeypots and Deception Technologies
A honeypot is a decoy system intentionally set up to attract and detect attackers. It appears to be a legitimate, valuable target (a file server, database, or workstation) but contains no real data and is isolated from production systems. Its only purpose is to be attacked — any connection to a honeypot is inherently suspicious because there is no legitimate reason for traffic to go there. Honeypots generate high-fidelity alerts with very low false positive rates, which makes them valuable for detection that cuts through normal network noise.
Honeypots serve several security purposes. Early warning: a honeypot in a network segment where only attackers should be (e.g., a dormant server IP space) will alert the moment a scanner touches it, often indicating an attacker is already inside the network performing reconnaissance. Intelligence gathering: because honeypot traffic is almost entirely malicious, it can be captured and analyzed to understand attacker techniques, tools, and objectives in detail — including zero-day exploits and novel attack patterns that haven't been seen elsewhere. Slowing attackers: a honeynet (network of honeypots) can waste significant attacker time as they explore systems that appear real but contain no valuable data.
Honeytokens extend the deception concept to data items rather than systems. A honeytoken might be a fake database credential embedded in a configuration file, a fake credit card number in a database, or a fake document with a unique identifier. If that credential is used in a login attempt, or that document is accessed from an unusual location, it's a reliable indicator of compromise — the data has no legitimate use, so any activity around it must be malicious. Honeytokens can be deployed at scale across a file system to create a fine-grained trip-wire detection system.
IDS/IPS Tuning and Managing Alerts
Deploying an IDS or IPS is not a "set it and forget it" task. Out-of-the-box configurations generate massive volumes of alerts, many of which are false positives — the system flagging legitimate traffic as suspicious. An untuned IDS in a real enterprise environment might generate thousands of alerts per day, making it impossible for analysts to identify genuine threats. This is called alert fatigue — when analysts are overwhelmed by alert volume, they start ignoring or bulk-dismissing alerts, causing real attacks to be missed.
IDS/IPS tuning is the process of adjusting detection rules to reduce false positives without increasing false negatives. The process involves: first, understanding normal traffic patterns in your specific environment (what applications, protocols, and behaviors are legitimate?); then, suppressing or adjusting rules that generate false positives for known-good traffic; and finally, validating coverage to ensure the tuning hasn't removed detection of real threats.
The fundamental tension in IDS/IPS tuning is the tradeoff between sensitivity and specificity. A highly sensitive configuration catches more real attacks but generates more false positives. A highly specific configuration reduces false positives but risks missing novel or slightly varied attacks. The right balance depends on the environment — a honeypot network might want maximum sensitivity, while a production payment system needs precision to avoid business disruption from false blocks.
IDS/IPS Integration with SIEM
IDS and IPS systems rarely operate in isolation in enterprise environments. Their alerts are fed into a SIEM (Security Information and Event Management) system that aggregates logs from across the entire security infrastructure — firewalls, endpoints, authentication systems, cloud services, DNS servers, and more. The SIEM correlates events from multiple sources that individually might not trigger an alert but together reveal a pattern of attack.
For example: a single failed SSH login attempt is normal noise. But if the SIEM correlates an IDS alert for a port scan from IP 10.0.5.200 at 2:00 AM, followed by 50 failed SSH login attempts from the same IP against multiple servers at 2:05 AM, followed by a successful login at 2:07 AM — the combined picture strongly indicates a successful brute-force attack that requires immediate investigation. No single event would have triggered a response, but the correlated story is unambiguous.
SIEM integration also enables automated response through SOAR (Security Orchestration, Automation, and Response) platforms. When a SIEM rule fires based on correlated IDS/IPS alerts, the SOAR can automatically trigger predefined response playbooks: blocking the attacking IP at the firewall, sending a notification to the on-call analyst, creating an incident ticket, and capturing forensic artifacts — all without waiting for human intervention. This dramatically reduces the time between detection and response.
Unified Threat Management (UTM) and NGFW
Modern enterprise security rarely deploys standalone IDS/IPS devices. Instead, IPS functionality is typically integrated into Next-Generation Firewalls (NGFW) or UTM (Unified Threat Management) appliances that combine multiple security functions into a single device.
A UTM appliance combines firewall, IPS, antivirus, web filtering, email filtering, and sometimes VPN into one box. This is popular in small and medium businesses because of simplified management and lower cost than deploying separate best-of-breed solutions for each function. The trade-off is that each individual function may be less capable than a dedicated solution.
An NGFW (Next-Generation Firewall) goes beyond traditional stateful packet inspection by adding application awareness (identifying applications regardless of port — detecting BitTorrent on port 80, for example), user identity awareness (enforcing policies based on Active Directory user identity rather than just IP address), SSL/TLS inspection (decrypting and inspecting encrypted traffic), and integrated IPS. NGFWs are the dominant enterprise perimeter security technology today. For exam scenarios: when the question mentions "application-aware firewall," "user-based firewall policies," or "integrated IPS and firewall," the answer is NGFW.