Lesson 3.5: IDS, IPS & SIEM | AP Cybersecurity
Topic 3.5: IDS, IPS & SIEM
After the firewall and the segmentation, the detective layer — the systems that watch all traffic, correlate events across sources, and tell the security team what is happening inside the network right now.
- 3.5.1 — Learning Objectives(3 min)
- 3.5.2 — Why Detection Matters After Firewalls(6 min)
- 3.5.3 — Essential Vocabulary & Exam Tips(10 min)
- 3.5.4 — IDS vs. IPS In Depth(10 min)
- 3.5.5 — Detection Methods: Signature vs. Anomaly(10 min)
- 3.5.6 — False Positives, False Negatives & the Tuning Challenge(8 min)
- 3.5.7 — SIEM: Aggregation, Correlation & Response(10 min)
- 3.5.8 — Real-World Case Studies(8 min)
- 3.5.9 — Worked Examples: Predict First(5 min)
- 3.5.10 — AP Exam Strategy(5 min)
- 3.5.11 — Frequently Asked Questions(3 min)
13.5.1 — Learning Objectives
- Distinguish between an IDS (passive detection and alerting) and an IPS (active inline blocking), explain why the deployment position differs for each, and identify the tradeoff each creates
- Compare signature-based and anomaly-based detection methods: explain how each works, what attacks each excels and fails at detecting, and when each is appropriate
- Define false positive, false negative, true positive, and true negative in the context of intrusion detection, and explain the security impact of each error type
- Explain the tuning challenge: describe how decreasing false positives often increases false negatives and vice versa, and why proper tuning is a continuous operational process
- Describe what a SIEM does: log collection, normalization, correlation, alerting, and dashboarding — and explain how correlation across multiple log sources detects attacks that individual logs would miss
- Explain what a SOC (Security Operations Center) does and describe how analysts use SIEM data to investigate and respond to security incidents
- Apply IDS/IPS/SIEM knowledge to Vantex Financial Group’s detection architecture and identify gaps in coverage
- Recognize the four most common AP exam traps on IDS, IPS, and SIEM questions
23.5.2 — Why Detection Matters After Firewalls
Firewalls and segmentation (Lessons 3.3 and 3.4) define what traffic is permitted and block everything else. But firewalls have a fundamental limitation: they can only enforce rules about what they know. A firewall permits HTTPS traffic to the web server because HTTPS is necessary. An attacker who sends a SQL injection payload inside a perfectly valid HTTPS connection is permitted through the firewall — the HTTPS is correct; the content is malicious.
This is where detection systems become essential. Instead of asking “is this traffic permitted?” (the firewall question), detection systems ask “does this permitted traffic contain attack patterns?” and “does this combination of events across the network indicate an ongoing attack?”
The Detection Gap: What Firewalls Miss
- Permitted traffic carrying malicious payloads: SQL injection in HTTPS requests, malware in email attachments from legitimate senders, command injection in API calls. All look like permitted traffic from the firewall’s perspective.
- Compromised internal systems behaving normally: A malware-infected workstation making normal DNS requests to resolve attacker-controlled domains looks like legitimate DNS traffic. A compromised server exfiltrating data over HTTPS looks like normal outbound web traffic.
- Slow, low-and-slow attacks: An attacker conducting reconnaissance by scanning one port per hour over days avoids rate-based firewall triggers. Each individual scan packet is benign; the pattern reveals the attack.
- Lateral movement between permitted segments: Once inside the network, an attacker may move between systems using permitted protocols (SMB, WMI, RDP) that the inter-VLAN firewall allows for legitimate operations. The movement is permitted; the pattern is malicious.
The detection principle: Assume some attacks will bypass preventive controls. The question is not “can we prevent every attack?” but “when an attack happens, how quickly do we detect it, and how thoroughly do we understand what happened?” Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) are the key metrics. The Vantex Security Operations Center (SOC) targets MTTD under 15 minutes for high-severity events and MTTR under 4 hours.
Which statement BEST explains the difference?
33.5.3 — Essential Vocabulary & Exam Tips
| Term | Definition | Exam Trap / Critical Distinction |
|---|---|---|
| IDS (Intrusion Detection System) | A passive security device that monitors network or host traffic for suspicious activity and generates alerts. An IDS does NOT take action to block traffic; it detects and reports. Deployed out-of-band (traffic is copied to the IDS, not routed through it). | KEY IDS = detect and alert only. IDS does NOT block. “The IDS blocked the attack” is always wrong. If the scenario describes automatic blocking, it is an IPS. Deployment: out-of-band (tap or SPAN port). Cannot stop attacks in progress; can only record them for response. |
| IPS (Intrusion Prevention System) | An active security device deployed inline in the traffic path that monitors for suspicious activity AND automatically blocks or drops malicious traffic. All traffic flows through the IPS; it is in-band. Can block attacks in real time. | KEY IPS = detect AND block. Deployed inline (all traffic passes through). Risk: false positives cause legitimate traffic to be blocked. A misconfigured or overly-sensitive IPS can cause outages by blocking legitimate traffic — this is the primary operational risk of IPS vs IDS. |
| NIDS / NIPS | Network-based IDS/IPS. Monitors network traffic at a specific point in the network. NIDS sees all traffic at that point; can detect network-level attacks like port scans, DoS attempts, and lateral movement. | NOTE NIDS/NIPS cannot see encrypted traffic unless SSL inspection is implemented. A NIDS positioned after the perimeter firewall sees all permitted inbound traffic — but if that traffic is HTTPS, the NIDS sees encrypted bytes, not the plaintext payload. NGFW with SSL inspection or endpoint monitoring fills this gap. |
| HIDS / HIPS | Host-based IDS/IPS. Runs as software on individual endpoints. Monitors system calls, file changes, process activity, registry modifications, and local network connections. Can see activity after decryption (the host decrypts its own TLS traffic). | KEY HIDS sees what NIDS cannot: endpoint behavior, process activity, and post-decryption content. But HIDS requires software installation on every monitored host. A HIDS on the web server can detect a SQL injection execution even if the network-level IDS missed it because it saw the OS-level behavior (unexpected database query spawning a shell). |
| Signature-Based Detection | Detection method that compares traffic or system activity against a database of known attack patterns (signatures). A signature is a specific pattern that, when found, indicates a known attack type. Highly accurate for known attacks; completely blind to unknown attacks. | KEY Signature = known attack. Cannot detect zero-day exploits or novel attack techniques not in the signature database. Signatures must be updated regularly (like antivirus definitions). Fast and low false-positive rate for known attacks. |
| Anomaly-Based Detection | Detection method that establishes a baseline of normal behavior and alerts when activity deviates significantly from that baseline. Can detect unknown attacks (zero-days) by flagging abnormal patterns even if no signature exists. | KEY Anomaly = deviation from baseline. Higher false positive rate than signature-based (legitimate but unusual activity can trigger alerts). Requires a learning period to establish the baseline. Can detect zero-day attacks and insider threats that signature-based systems miss. |
| False Positive (FP) | An alert generated for legitimate, benign activity that was incorrectly classified as an attack. “The IDS alarmed on traffic that was not actually malicious.” Wastes analyst time and, in IPS deployments, blocks legitimate traffic. | KEY False positive = alert when there is NO attack. The IDS/IPS is wrong — it thought something was an attack but it was not. The security risk: analyst fatigue from too many FPs causes real alerts to be missed. IPS risk: FP causes legitimate traffic to be blocked, creating outages. |
| False Negative (FN) | A missed detection — a real attack occurred but the IDS/IPS did not generate an alert. “The IDS did not alarm even though an attack was in progress.” The most dangerous error type from a security perspective. | KEY False negative = no alert when there IS an attack. The IDS/IPS failed to detect a real threat. A zero-day attack against a signature-based IDS is a guaranteed false negative (no signature exists for it). This is why defense-in-depth — not relying on any single control — is essential. |
| SIEM (Security Information and Event Management) | A centralized platform that collects log data from across the organization, normalizes it into a common format, correlates events across sources to identify attack patterns, and provides dashboards and alerting for security analysts. The “single pane of glass” for security operations. | KEY SIEM aggregates and correlates — it is not itself a detection sensor. The SIEM receives data from firewalls, IDS/IPS, servers, endpoints, and applications. Its value comes from correlation: seeing that a failed login on server A and a port scan on server B and an ARP anomaly on switch C are all happening within the same 10 minutes, suggesting a coordinated attack. |
| SOC (Security Operations Center) | A team of security analysts (Tier 1: triage, Tier 2: investigation, Tier 3: threat hunting/incident response) who monitor SIEM dashboards, investigate alerts, and respond to security incidents. The human component of the detection and response architecture. | NOTE The SOC is the human layer that acts on SIEM data. Technology detects; the SOC investigates and responds. SIEM alert quality directly determines SOC effectiveness: too many false positives = analyst fatigue and missed real threats; too many false negatives = attacks going undetected entirely. |
Match each to its detection approach.
43.5.4 — IDS vs. IPS In Depth
3.5.4a — Deployment Positions: Where IDS and IPS Are Placed
| Position | What It Monitors | Vantex Use |
|---|---|---|
| Perimeter (before firewall) | All inbound internet traffic before firewall filtering. Sees all attack attempts, including those blocked by the firewall. Useful for threat intelligence and understanding the attack surface. | IDS only at this position — monitoring what attacks are attempted (even blocked ones), feeding threat intelligence to the SIEM. Overwhelming volume of automated scan traffic requires careful filtering to surface meaningful alerts. |
| Perimeter (after firewall / DMZ ingress) | Traffic that has been permitted by the firewall. Focuses inspection on traffic that actually reached the DMZ. Lower volume, higher signal-to-noise ratio than before-firewall placement. | IPS inline at DMZ ingress. Blocks known attack signatures in permitted HTTPS and SMTP traffic. Protects web server from SQL injection, XSS, and known web application exploit signatures. |
| Internal (inter-VLAN) | East-west traffic between VLANs. Detects lateral movement, internal reconnaissance, and compromised internal systems attacking other internal systems. | NIDS via SPAN ports on core switches, monitoring all inter-VLAN traffic. Signatures tuned specifically for lateral movement patterns: SMB exploitation, credential spraying, unusual port scanning between segments. |
| Host-based (endpoints) | Individual workstation or server activity: process execution, file modifications, registry changes, memory anomalies, local network connections. Sees post-decryption content and host-level attack indicators. | HIPS deployed on all servers (VLAN 30 and VLAN 40). HIDS deployed on all employee workstations (VLAN 10). Endpoint logs forwarded to SIEM for correlation with network-level events. |
This is classified as a:
53.5.5 — Detection Methods: Signature-Based vs. Anomaly-Based
Every IDS and IPS must decide whether a given packet or behavior is an attack. Two fundamentally different approaches have emerged, and modern systems typically combine both for broader coverage.
How it works: Maintains a database of attack signatures — specific byte patterns, protocol anomalies, or behavioral rules that uniquely identify known attacks. Compares incoming traffic against this database. A match = alert (or block).
Example Vantex signature: “TCP packet to port 1433 (SQL Server) containing the string EXEC xp_cmdshell” → alert as possible SQL Server command injection attempt.
Strengths: Very high accuracy for known attacks. Low false positive rate when signatures are well-written. Fast execution (database lookup is computationally efficient). Specific and explainable: “Alert triggered because packet matched Signature ID 12847 (MS-SQL xp_cmdshell exploitation).”
Fatal limitation — zero-day blindness: Signature-based detection is completely unable to detect attacks for which no signature exists. A brand new exploit, a novel malware variant, or a customized attack that modifies known patterns to evade signatures will generate zero alerts. On the day a new vulnerability is announced, there is a window (hours to days) before a signature is written and deployed where signature-based IDS provides no protection.
Requires: Continuous signature updates from threat intelligence sources. Outdated signatures = outdated protection. Major vendors release signature updates daily or faster.
How it works: Establishes a statistical baseline of normal behavior over a learning period (typically 2–4 weeks). Compares current activity against the baseline. Significant deviations trigger alerts regardless of whether they match a known attack signature.
Example Vantex anomaly: Baseline for the accounts payable workstation: 50–200 file accesses per day, all to the finance share. Anomaly: 15,000 file accesses in 2 hours to an unusual SMB share. Alert: “Access volume 75x above baseline, unusual destination — possible data staging or ransomware.”
Strengths: Can detect zero-day attacks and novel techniques by recognizing that something unusual is happening even without a specific signature. Effective for insider threats (a user accessing systems outside their normal pattern). Can detect slow, low-and-slow attacks that spread activity over time (each individual event is normal; the pattern is not).
Fatal limitation — false positive risk: Legitimate but unusual business activity can trigger anomaly alerts. A new employee running a large file migration, a quarterly report process that runs once per quarter, or a product launch that generates unusual traffic patterns can all appear as anomalies. Requires careful baseline calibration and ongoing tuning to reduce false positive rate.
Requires: Learning period to establish baseline (3–4 weeks of normal activity). Ongoing recalibration as business patterns change. Human analyst judgment to distinguish legitimate anomalies from real attacks.
Detection Method vs. Attack Type: Which Catches What
| Attack Type | Signature-Based | Anomaly-Based |
|---|---|---|
| Known malware (WannaCry, EternalBlue) | ✓ Detects reliably — well-known signatures exist | ✓ May detect via abnormal SMB traffic patterns, but signature is faster/more reliable |
| Zero-day exploit (no signature yet) | ✗ Cannot detect — no signature exists | ✓ May detect via abnormal behavior even without signature |
| Slow port scan (1 port/hour over days) | ≈ May not trigger — rate-based signatures miss slow scans | ✓ Pattern over time deviates from baseline |
| Insider threat (unusual data access) | ✗ Cannot detect — no specific signature for “unusual access” | ✓ Access pattern deviates from user baseline |
| DDoS volumetric attack | ✓ Detects via protocol anomaly signatures (SYN flood pattern) | ✓ Traffic volume far exceeds baseline |
| Polymorphic malware (changes signature to evade) | ✗ Evades by changing byte patterns faster than signatures update | ✓ Behavioral patterns (file encryption, network C2) remain detectable |
| Legitimate but unusual activity (large backup) | ✓ Correctly ignores — no malicious signature present | ✗ May incorrectly alert (false positive) if activity deviates from baseline |
A system that detects threats and alerts but does NOT block is an .
A system that detects AND blocks threats inline is an .
A platform that aggregates and correlates logs from multiple sources is a .
When analysts become desensitized from too many false positives, this is called alert .
A platform that automates incident response from SIEM alerts is called .
63.5.6 — False Positives, False Negatives, and the Tuning Challenge
Every intrusion detection decision falls into one of four categories based on whether an attack actually occurred and whether the system alerted. Understanding these four outcomes — and the real-world security consequences of each — is essential for AP exam questions and for understanding why IDS/IPS tuning is a continuous operational discipline.
| Alert Generated | No Alert Generated | |
|---|---|---|
| Real Attack Occurred |
True Positive (TP) The system correctly detected a real attack. Vantex example: SQL injection attempt detected and alerted. SOC investigates and confirms malicious payload. Attack stopped or investigated. This is the desired outcome. |
False Negative (FN) A real attack occurred but went undetected. Vantex example: Zero-day exploit against the web server. No signature exists. No anomaly triggered. Attack succeeds silently. Most dangerous outcome. The attack is invisible. |
| No Real Attack (Normal Activity) |
False Positive (FP) The system alarmed on benign activity. Vantex example: Vulnerability scanner running a legitimate internal scan triggers SQL injection signatures. 847 alerts in 20 minutes, all false. Wastes analyst time. IPS FPs block legitimate traffic. |
True Negative (TN) Normal activity correctly not flagged. Vantex example: Customer accesses banking portal via HTTPS. No attack patterns. No alert. Normal session continues. Also a desired outcome — the system correctly ignores benign traffic. |
3.5.6a — The Tuning Challenge: The FP/FN Tradeoff
Every IDS/IPS configuration involves a fundamental tradeoff: making the system more sensitive (lower detection threshold) catches more real attacks (fewer false negatives) but also generates more false alarms (more false positives). Making the system less sensitive (higher threshold) reduces false alarms but misses more real attacks.
The Vantex tuning example: Vantex’s IPS is configured with an anomaly-based rule: “Alert if a single workstation initiates more than 100 connections in 60 seconds.”
- Threshold set too low (50 connections/60 seconds): Catches more real malware C2 and scanning behavior (fewer FNs). But legitimate video conferencing, software updates, and browser prefetching regularly exceed 50 connections/60 seconds — dozens of FP alerts per hour. Analysts stop investigating because they expect most alerts to be false.
- Threshold set too high (500 connections/60 seconds): Almost no false positives. But most malware C2 and scanning activity stays below 500 connections/60 seconds — many real attacks go undetected (more FNs). The system is quiet but blind to moderate-intensity attacks.
- Optimal tuning (100 connections/60 seconds): Based on analysis of 3 months of baseline data showing legitimate traffic rarely exceeds 85 connections/60 seconds. Alert rate is manageable (5–10 per day), and real attacks (which typically exceed 200+) are reliably caught. Tuning is empirical, not theoretical — it requires real traffic data.
Alert fatigue: The most dangerous consequence of a high false positive rate is alert fatigue — analysts who see 500 false alarms per day stop taking alerts seriously and begin dismissing them without investigation. When a real attack generates an alert, it may be dismissed along with the false positives. This human response to excessive noise is well-documented and is one reason why proper IDS/IPS tuning is treated as a critical security engineering discipline, not an afterthought.
Which detection method catches novel/unknown attacks?
73.5.7 — SIEM: Aggregation, Correlation, and Response
An IDS generates alerts. A firewall generates logs. An Active Directory server generates authentication logs. A database generates query logs. Each of these sources tells part of the story of what is happening on the network — but no single source tells the whole story. A SIEM (Security Information and Event Management) solves this by aggregating logs from all sources, normalizing them into a common format, and applying correlation rules that identify multi-source patterns indicating attacks.
Vantex SIEM Pipeline: From Raw Log to SOC Alert
3.5.7a — Why Correlation Is the SIEM’s Core Value
Consider a multi-stage attack against Vantex. Traced individually, each event looks benign or routine:
| Time | Event | Source | Individually Suspicious? |
|---|---|---|---|
| 01:47 | SSH login to web server from 10.10.10.205 (employee workstation) | Server authentication log | Low — IT staff sometimes access servers at night |
| 01:49 | New outbound HTTPS connection from web server to 185.44.22.100 | Firewall egress log | Low — servers make outbound HTTPS connections for updates |
| 01:52 | Large DNS query volume from web server to external resolver (800 queries/minute) | DNS server log | Medium — unusual but could be a monitoring agent |
| 02:00 | Workstation 10.10.10.205 reported as “offline” by monitoring system | Network monitoring | Low — workstations go offline regularly |
| 02:15 | IDS alert: SQL injection attempt from web server to database server | IDS sensor, VLAN 30→40 | High — but web servers occasionally trigger SQL injection signatures on parameterized queries |
Individually, none of these events triggers a P1 response. But the SIEM correlation rule sees: a workstation that went offline → SSH login from that workstation IP to the web server → new outbound connection to an unknown external IP → unusual DNS volume → SQL injection attempt from the web server to the database. The correlation produces: “Possible account takeover of workstation 10.10.10.205, lateral movement to web server, C2 communication, SQL injection toward database. P1 — Immediate response.”
Select ALL log sources that provide high-value security data for the SIEM.
83.5.8 — Real-World Case Studies: Detection in Action
What happened: Target had deployed a security monitoring tool (FireEye) that detected the malware being installed on their POS systems in November 2013. The FireEye system generated specific, accurate alerts about the malware — these were true positive detections. The alerts were reviewed by Target’s security operations team in Bangalore and dismissed as not requiring escalation. The malware continued operating for three weeks, stealing 40 million payment card numbers.
Why the alerts were missed: Two reasons: (1) The FireEye alerts were one source among many in a high-volume alert environment. Without correlation context showing the relationship between the FireEye detection and the anomalous outbound traffic that was simultaneously occurring, the alert appeared to be a routine malware detection on an isolated system. (2) The SOC was not empowered to take automatic remediation action; escalation to U.S.-based response teams required judgment calls that the offshore team was reluctant to make for what appeared to be a single-system event.
Detection lesson: A true positive alert that goes unacted-upon is operationally equivalent to a false negative from a security outcome perspective. Detection capability without response capability provides no security value. The Target case established that: (1) Alert volume must be manageable enough that real alerts are not drowned out; (2) SOC teams must be empowered to act, not just observe; (3) SIEM correlation should have connected the FireEye malware alert to the simultaneous anomalous outbound traffic — the combination would have been unmissable.
Background: Equifax’s 2017 breach (discussed in Unit 2) involved an unpatched Apache Struts vulnerability exploited starting May 13, 2017. The breach went undetected for 76 days. One contributing factor: Equifax’s SSL inspection appliance had been misconfigured for 19 months, preventing inspection of encrypted traffic — including the attacker’s exfiltration of data over HTTPS.
What SIEM correlation would have detected: Even without SSL inspection, correlation of available signals would have been revealing: (1) The Apache Struts server (a specific IP) showed anomalous CPU utilization starting May 13. (2) Starting May 13, outbound connections from the same IP to new external IPs began. (3) The volume of data in outbound connections from that server increased significantly. (4) DNS queries from that server included unusual domain names not in normal business operations. Any SIEM correlation rule linking “new external connection from known application server + increased outbound data volume + unusual DNS queries” would have generated a P1 alert on May 13 rather than 76 days later.
Detection lesson: SIEM correlation does not require perfect visibility. Even imperfect data — CPU logs, connection volume, DNS logs — correlates into strong attack signals when combined. Organizations that believe “we can’t detect what we can’t decrypt” are ignoring the significant detection value of metadata even without payload inspection.
Scenario: At 11:47 PM on a Tuesday, Vantex’s SIEM fires a P2 alert: “ARP anomaly detected on Switch-03 port Gi0/14 — unsolicited ARP replies associating IP 10.10.10.1 (default gateway) with MAC AA:BB:CC:01:02:03 (not the gateway’s registered MAC).” The Tier 1 analyst escalates to Tier 2 at 11:52 PM.
Tier 2 investigation (11:52 PM — 12:18 AM): The SIEM search shows MAC AA:BB:CC:01:02:03 belongs to a device connected to the employee VLAN, plugged in at 11:31 PM (Switch-03 port Gi0/14). Cross-referencing the DHCP lease for that MAC shows the device was assigned IP 10.10.10.188. This IP has no registered owner in the asset inventory — it is an unauthorized device. Port mirroring activated by the Tier 2 analyst shows the device is capturing traffic from the employee VLAN using a packet analyzer.
Response (12:18 AM — 12:24 AM): The network team shuts down switch port Gi0/14. The device is physically located (Conference Room B on floor 3). Physical security is notified and retrieves the device at 12:47 AM — a laptop with no corporate asset tags. Incident classified as insider threat (someone with physical access). ARP poison active for 46 minutes; SIEM confirms no cross-VLAN traffic was captured due to DAI blocking the actual poisoning.
What made this work: SIEM correlation of the DAI alert (Layer 2) with DHCP logs (IP assignment) with asset inventory (unknown device) with port mirror traffic (confirmed packet capture) — across four separate sources in 26 minutes. Without the SIEM, the DAI alert would have been one log entry on one switch that no analyst would have seen until the next morning.
Match each capability to what it provides.
93.5.9 — Worked Examples: Predict First, Then Classify
Apply the 2x2 Matrix
Ask two questions for each: (1) Did a real attack occur? (2) Did the IDS alert?
A: Real attack? No (authorized scanner). Alert? Yes. → False Positive (alert with no real attack).
B: Real attack? Yes (real attacker). Alert? Yes. → True Positive (alert with real attack).
C: Real attack? No (podcast streaming). Alert? Yes. → False Positive (alert with no real attack).
D: Real attack? Yes (zero-day). Alert? No. → False Negative (no alert with real attack).
A = FP, B = TP, C = FP, D = FN. Note that event D is the most serious: a successful zero-day exploit went completely undetected. Events A and C are operationally problematic (alert fatigue risk) but not security failures. Event B is the ideal outcome. Reducing A and C (FPs) without increasing D (FNs) requires careful tuning: whitelist the internal scanner IP (eliminates A), adjust the DNS volume threshold based on podcast streaming behavior analysis (refines C threshold).
Apply the IDS vs. IPS Decision Criteria
Use IPS when: real-time blocking is needed and false positives are acceptable. Use IDS when: detection without blocking is sufficient, or when false positives would cause unacceptable service disruption.
Position 1 (Internet perimeter, 10 Gbps): High-value location for blocking known attack patterns. High-throughput hardware IPS can handle 10 Gbps. Known attacks (SQL injection, known exploit signatures) should be blocked, not just detected. → IPS (with hardware acceleration). Tuning critical to manage FP rate.
Position 2 (App → Database, SPAN port): Using SPAN port means detection only (IDS by architecture — traffic is mirrored, not routed through). This is appropriate: between internal segments where blocking anomalies could cause app failures, detection and alerting allows human validation before blocking. → IDS (SPAN port dictates out-of-band deployment).
Position 3 (Legacy payment server): Compatibility issue causes IPS false positives that block payment transactions. Blocking legitimate payment transactions is a direct business impact. → IDS. Detection only until the false positive issue is resolved and validated. Blocking legitimate payment processing is a worse outcome than the risk of a missed attack on this segment (additional controls on the payment server compensate).
Position 1: IPS. Position 2: IDS. Position 3: IDS until FP issue resolved. The deployment decision is always a tradeoff: the benefit of real-time blocking vs. the risk of legitimate traffic disruption. Where blocking is needed and FPs can be controlled → IPS. Where detection is sufficient or blocking risk is too high → IDS.
This is called:
103.5.10 — AP Exam Strategy: IDS, IPS, and SIEM Questions
Strategy 1: IDS vs. IPS in One Question
The AP exam distinguishes IDS and IPS precisely. Use these identifiers:
- IDS: detects, alerts, passive, out-of-band, no blocking
- IPS: detects AND blocks, active, inline, real-time prevention
- “The system generated an alert” = could be either IDS or IPS
- “The system blocked the attack” = IPS only
- “The attack reached the server despite the alert” = IDS (no blocking)
- IPS risk: false positive = outage. IDS risk: false negative = missed attack. Know both risks.
Strategy 2: Signature vs. Anomaly Mapping
Match the attack type to the detection method:
- Known, specific attack pattern: Signature catches it
- Zero-day exploit (no signature): Only anomaly can detect
- Insider threat / unusual access: Only anomaly (behavior deviation)
- Slow reconnaissance: Anomaly (cumulative pattern); signature misses
- Polymorphic malware: Anomaly (behavior); signature misses (evades)
- High FP activity: Signature is more specific; anomaly fires on legitimate unusual behavior
Strategy 3: The Four Fatal Traps
- Trap 1 — IDS blocks attacks: Wrong. IDS only detects and alerts. Blocking = IPS.
- Trap 2 — Signature detects zero-days: Wrong. Zero-day = no signature = guaranteed false negative for signature-based systems.
- Trap 3 — SIEM is a detection sensor: Wrong. SIEM aggregates and correlates data from sensors (IDS, firewall, endpoints). SIEM does not independently detect traffic — it processes what detection systems and log sources send it.
- Trap 4 — False positive = security failure: Partially wrong. False positives waste analyst time and can cause IPS outages, but the most dangerous error is a false negative (missed real attack). Both are problems but for different reasons.
Strategy 4: SIEM Correlation Value
AP questions about SIEM focus on what correlation does that individual logs cannot:
- Individual log = one event from one source
- SIEM = patterns across multiple sources over time
- A single failed login = noise. 50 failed logins from different IPs against many accounts = credential stuffing (only visible in SIEM)
- SIEM detects what individual tools cannot: multi-stage attack chains, slow reconnaissance, coordinated attacks
- SIEM value = correlation. Not collection. Not storage. Correlation.
What automates the response between detection and action?
?3.5.11 — Frequently Asked Questions
Q: Why would you ever choose an IDS over an IPS if an IPS both detects AND blocks?
Because false positives from an IPS cause outages. An IPS that incorrectly blocks a payment transaction, a critical business application request, or a customer login creates immediate business impact. In environments where: (1) false positive rates cannot be tuned to near-zero levels; (2) the application being protected has low tolerance for disruption; (3) the monitored traffic is internal (where blocking may cause cascading failures); or (4) the detection system has known compatibility issues — an IDS is the correct choice. You get detection and alerting while a human makes the blocking decision. The cost: attacks may succeed before the analyst responds. The benefit: no false-positive outages. Both are real trade-offs, not one being categorically better.
Q: How long does anomaly-based detection take to start working?
Anomaly-based detection requires a learning period to establish a reliable baseline — typically 2–4 weeks of normal business activity. During this period, the system observes and records what normal looks like: how many connections does each workstation make per hour, what files does each user access, what DNS queries does each server generate. If the learning period includes unusual activity (a major product launch, end-of-quarter reporting, a holiday period), the baseline may be skewed, producing excessive alerts once the learning period ends. Best practice: deploy anomaly detection during a representative “normal” business period, review the initial baseline for accuracy, and recalibrate quarterly as business patterns change.
Q: What is the difference between a SIEM and a log management system?
A log management system collects, stores, and provides search/retrieval for log data. It is an archive with a search engine — valuable for forensics and compliance but reactive (you search after something happens). A SIEM adds real-time correlation on top of log collection: it continuously applies rules that match patterns across multiple log sources and generates alerts when attack sequences are detected. The SIEM is proactive; it identifies attacks as they happen rather than after the fact. The boundary is blurring: modern SIEMs include log management, and modern log platforms add SIEM-like correlation. For AP exam purposes: SIEM = aggregation + normalization + correlation + real-time alerting. Log management = collection + storage + search.
Q: What is UEBA and how does it relate to anomaly-based detection?
UEBA (User and Entity Behavior Analytics) is an advanced form of anomaly-based detection specifically focused on user and endpoint behavior. Where traditional anomaly-based IDS might look at network traffic volume, UEBA builds behavioral profiles of individual users (when they log in, which systems they access, how much data they transfer, what commands they run) and detects deviations from each user’s specific baseline. UEBA is the control most effective against insider threats and credential compromise — attacks that use legitimate credentials but exhibit unusual behavior. UEBA is often implemented as a module within a SIEM platform (Splunk UBA, Microsoft Sentinel UEBA, IBM QRadar UEBA). The distinction: IDS watches network traffic patterns; UEBA watches individual user behavior patterns.
Q: Why does having more log sources in the SIEM make it more effective?
Attackers leave traces across multiple systems during a multi-stage attack: a port scan leaves traces on the firewall, lateral movement leaves traces on switches and Active Directory, data access leaves traces on servers and databases, exfiltration leaves traces on egress firewall and DNS logs. With only one or two log sources, the SIEM sees isolated events. With comprehensive coverage, it can correlate the full attack chain — seeing that events across five different systems over 90 minutes form a coherent attack sequence. Each additional log source increases the SIEM’s ability to detect multi-stage attacks earlier and more accurately. The Target breach illustrates this: FireEye detected the initial malware but the SIEM did not correlate it with the anomalous outbound traffic from the same system because the egress firewall logs may not have been feeding the SIEM with adequate fidelity.
Q: How does IDS/IPS fit into Vantex’s Network Security Audit Report project?
The detection layer (Layer 5 in Vantex’s DiD architecture) assessment should evaluate: Is there an IDS/IPS deployed at critical network boundaries (perimeter, DMZ ingress, inter-VLAN critical paths)? Are both signature-based and anomaly-based detection methods in use? What is the false positive rate and is alert fatigue a risk? Is a SIEM aggregating and correlating logs from all critical sources (firewall, IDS, AD, database, endpoint)? What is the MTTD (Mean Time to Detect) for high-severity events? What is the SOC escalation process and response time? Gaps in detection coverage translate directly into risk exposure: without a SIEM correlating across sources, a multi-stage attack like the Equifax breach could go undetected for weeks. The ALE of a 76-day undetected breach is substantially higher than the ALE of a breach detected in 15 minutes — quantifying this difference justifies the SIEM investment.
Select ALL valid tuning actions to reduce false positives while maintaining real threat detection.
Tanner has taught AP Computer Science for 11+ years and built APCSExamPrep.com to give every student access to the same resources his own students use. He holds 1,845+ verified tutoring hours on Wyzant with a 5.0 rating from 451+ reviews. His AP CSA students score 5s at more than double the national average (54.5% vs. 25.5% nationally).
+Continue Learning
Practice what you learned, then move to the next topic in Unit 1:
Lesson → Exercise 1 → Exercise 2 → Lab → Quiz
Get in Touch
Whether you're a student, parent, or teacher — I'd love to hear from you.
Just want free AP CS resources?
Enter your email below and check the subscribe box — no message needed. Students get daily practice questions and study tips. Teachers get curriculum resources and teaching strategies.
Message Sent!
Thanks for reaching out. I'll get back to you within 24 hours.
Prefer email? Reach me directly at [email protected]