Master the SOC analyst's core skill — efficiently prioritising and classifying a queue of IDS/IPS alerts, understanding the four alert outcome categories, applying contextual enrichment to separate signal from noise, tuning signatures to reduce false positive volume, and documenting triage decisions in a professional format.
IDS/IPS Alert Triage
An Intrusion Detection System (IDS) monitors network traffic and generates alerts when patterns match known attack signatures. An Intrusion Prevention System (IPS) does the same but also blocks matching traffic automatically. Both generate high volumes of alerts — many of which are false positives — requiring a SOC analyst to triage each alert and determine whether it represents a real threat requiring investigation and response.
Alert triage is one of the most common and most consequential SOC tasks. The skill is not just identifying true positives but doing so efficiently at scale — a SOC that chases every alert with equal effort will miss the real threats buried in the noise, experience analyst burnout, and gradually train its team to stop investigating carefully. Effective triage is simultaneously a detection skill, an investigation skill, and a data management skill.
IDS vs IPS — Detection and Prevention
The distinction between IDS and IPS matters operationally. An IDS only alerts — it generates a notification that an analyst must review and act on. An IPS both alerts and takes automated blocking action. IPS mode introduces its own risk: a false positive in IPS mode may block legitimate business traffic, causing operational disruption. This is why most organisations run new signatures in IDS mode first, tuning for false positives before converting them to blocking rules in IPS mode.
The false positive cost asymmetry is significant: an IDS false positive costs analyst time. An IPS false positive may cost business continuity. Understanding which mode a given signature is operating in changes how urgently false positive tuning should be prioritised.
Imagine a security guard who receives radio calls from motion sensors across a large campus. Some sensors fire every time a pigeon lands on the roof. Some fire when the cleaning crew arrives at 6am. Some fire when a legitimate delivery is made to the loading dock. And occasionally, one fires because an actual intruder is cutting through a fence. The guard who runs to investigate every pigeon will be exhausted, ignore the radio eventually, and miss the fence-cutter. The effective guard knows which sensors reliably signal real problems, what time-of-day context changes the meaning of each alert, and how to quickly verify whether a given trigger is legitimate before committing to a full response. IDS/IPS triage is exactly this — applying context and pattern recognition to a high-volume alert stream to identify the signals that matter.
Triage Methodology
Step 1 Read the alert: signature name, source IP, destination IP and port Step 2 Check severity: Critical/High/Medium/Low -- prioritise accordingly Step 3 Check context: is the source internal or external? Known asset? Step 4 Look up source IP: reputation (AbuseIPDB, VirusTotal), ASN, geolocation Step 5 Correlate: other alerts from same source? Same destination? Same time window? Step 6 Verify: is the target actually vulnerable to what this signature detects? Step 7 Classify: True Positive / False Positive / Benign Positive / False Negative
IDS Triage in Practice
True Positive An external IP sending SQL injection payloads to a login page running on a database-backed web server. Every contextual check confirms the alert is legitimate.
Alert: ET WEB_SERVER SQL Injection Attempt Severity: HIGH Source: 45.33.32.156 (Russia, AS49505) Dest: 10.0.0.80:80 (web01.corp.com -- Apache/MySQL) Payload: GET /login.php?id=1' UNION SELECT 1,2,3-- Response: 200 (page returned data -- possible successful extraction) # TRUE POSITIVE: External attacker, valid target, SQLi in payload # Action: Block IP at perimeter, check for successful data extraction in app logs
False Positive Internal scanners like Nessus and Qualys trigger many IDS signatures by design — their purpose is to probe for vulnerabilities using the same techniques an attacker would use. Whitelisting known scanner IPs during authorised scan windows prevents alert fatigue.
Alert: ET SCAN Nmap Scripting Engine User-Agent Severity: MEDIUM Source: 10.0.1.200 (internal) Dest: 10.0.0.0/8 (internal network) Source identified: Nessus vulnerability scanner (scheduled weekly scan) Scan authorised: Yes (Thursday 02:00-06:00 maintenance window) # FALSE POSITIVE: Authorised internal scanner during scheduled window # Action: Suppress alerts from 10.0.1.200 during 02:00-06:00 Thursday windows
True Positive An internal host making regular HTTPS connections to a known C2 infrastructure — confirmed malware infection requiring immediate containment.
Alert: ET MALWARE Cobalt Strike Beacon SSL Certificate Severity: CRITICAL Source: 10.0.5.44 (CORP-WS-033 -- Sarah Johnson's workstation) Dest: 185.220.101.67:443 Certificate CN: matches known Cobalt Strike default certificate pattern Connection pattern: every 300 seconds (regular 5-minute beacon interval) # TRUE POSITIVE: Internal host beaconing to known C2 infrastructure # Action: Immediate isolation of CORP-WS-033, EDR triage, user notification
Benign A legitimate business application triggering a signature not designed for its traffic. Requires a policy exception documented in the SIEM, not a block action.
Alert: ET POLICY Dropbox.com Accessed Severity: LOW Source: 10.0.2.0/24 (marketing department subnet) Dest: dropbox.com Business justification: Marketing uses Dropbox for client deliverables (approved) Policy: Dropbox approved for Marketing (10.0.2.0/24) only # BENIGN POSITIVE: Authorised tool for this department # Action: Add exception for 10.0.2.0/24 → dropbox.com in this signature rule
What You Need to Know
The Four Alert Outcomes — A Complete Taxonomy
Every IDS/IPS alert falls into one of four outcome categories. Understanding the full taxonomy — including the two that don't generate alerts at all — is essential for designing an alert management strategy that catches what matters without drowning analysts in noise.
True Positive Real attack matched by signature correctly. Requires investigation and response. The goal state for every alert.
False Positive Benign traffic matched by a poorly tuned signature. Requires suppression or signature refinement. Volume is the enemy of detection.
Benign Positive Legitimate but policy-relevant traffic (shadow IT, personal tools, non-business apps). Requires a documented exception, not a block.
True Negative Normal traffic correctly not matched. The baseline for all the traffic that doesn't need attention. What the system is supposed to ignore.
False Negative Real attack not matched by any signature. The most dangerous outcome — an attack passes undetected. Requires threat hunting and signature development to address.
Contextual Enrichment — Transforming Alerts into Intelligence
A raw IDS alert contains four fields: signature name, source IP, destination IP, and port. This is insufficient to classify the alert in most cases. Enrichment adds the contextual data that makes the raw alert meaningful — converting noise into signal. The goal is to spend 2–4 minutes on enrichment for most alerts and determine classification without escalating to a senior analyst or full investigation.
The Enrichment Stack
Enrichment proceeds in layers, stopping when the classification becomes clear:
- Source IP reputation: Is the source IP in a threat intelligence feed? AbuseIPDB, VirusTotal, Shodan, or your SIEM's threat intel integration. A source with 847 prior abuse reports across multiple categories changes the probability of a true positive dramatically.
- Source geolocation and ASN: An alert from a Russian exit node to a web server is different from the same alert from your office IP. Not conclusive — attackers proxy through domestic infrastructure — but adds context for prioritisation.
- Destination asset context: What is this destination host? Is it running the software the signature targets? An Apache vulnerability signature firing against a Windows IIS-only server is almost certainly a false positive. CMDB or asset inventory lookup answers this in seconds.
- Internal vs external source: An alert from an internal source is a fundamentally different situation than one from an external source for most signature categories. Internal sources imply post-compromise activity, lateral movement, or an insider; they warrant different urgency and different investigation paths.
- Temporal correlation: Is this the only alert from this source, or are there 300 alerts from the same IP in the last 10 minutes? Correlation changes a single low-confidence alert into a high-confidence detection. Burst patterns often confirm automated attack tooling.
- Historical baseline: Has this source ever triggered this signature before? Is this destination host normally targeted by this alert type? Anomaly against baseline is more meaningful than any single data point.
A medium-severity alert that initially looks like a routine false positive becomes a confirmed true positive after three enrichment steps.
# Initial alert (looks routine): Alert: ET SCAN Port Scan Detected Severity: MEDIUM Source: 10.0.3.100 Dest: 10.0.0.0/8 Ports: multiple # First instinct: internal scanner, probably IT doing maintenance # Enrichment Step 1: CMDB lookup on source IP 10.0.3.100 = CORP-PC-045 (Accounts Payable workstation -- Linda Chen) Asset type: Standard user workstation. NOT a scanner or IT asset. # Enrichment Step 2: SIEM correlation -- recent activity from CORP-PC-045 09:14 Received phishing email with malicious attachment 09:31 Office macro executed (Sysmon Event 1) 09:33 New outbound connection to 185.220.101.67 (known C2 IP) 09:41 Port scan begins -- automated network reconnaissance by malware # Classification revised: TRUE POSITIVE -- malware post-exploitation # Action: Isolate CORP-PC-045, pull EDR telemetry, declare incident
Reducing False Positives — Signature Tuning in Practice
Every false positive that an analyst investigates and closes without action represents wasted analyst time and a reduction in the SOC's effective capacity. Signature tuning — modifying the conditions under which a rule fires — is the discipline that keeps the alert queue manageable and the team's detection capability sharp.
Tuning is not disabling signatures. It is adding specificity: narrowing the conditions that trigger an alert to those where the alert is actually meaningful, while preserving detection of genuine threats. The goal is high-confidence, low-volume alerting rather than broad-coverage, high-volume alerting.
Whitelist known-good sources: Add suppression for authorised scanner IPs, monitoring agents, and known vendor ranges. The most common tuning action — eliminates entire classes of false positives in one rule.
Add destination context: A web attack signature that fires on any HTTP traffic can be scoped to only fire when the destination is actually running a web server. CMDB integration enables this automatically.
Add time-of-day context: Maintenance window suppression for scheduled scans and patching activity prevents overnight alert storms from drowning morning triage queues.
Document every exception: Every suppression rule must be documented with the business justification, the analyst who created it, and a review date. Undocumented suppressions become invisible detection gaps.
Scope exceptions tightly: Suppress the specific source IP and signature combination — not the entire signature. Suppressing "all alerts from 10.0.1.0/24" eliminates detection for an entire network segment.
Review exceptions periodically: Scanner IP changes, vendors are terminated, maintenance windows shift. Stale suppression rules create gaps. Quarterly review of all active suppressions is a minimum standard.
A SOC analyst suppresses all "ET SCAN" alerts from the marketing department subnet (10.0.2.0/24) after the marketing team complains their legitimate LinkedIn Sales Navigator tool triggers port-scan signatures when it probes prospect domains. The suppression is created broadly: all ET SCAN signatures, all sources in 10.0.2.0/24.
Six weeks later, an attacker compromises a marketing workstation via a phishing attachment. The malware begins lateral movement with a network port scan. The ET SCAN signature fires — and is suppressed by the analyst's broad rule. The first alert the SOC sees is a C2 beaconing signature three hours later, by which time the attacker has already enumerated the network, identified the domain controllers, and established persistence on two additional hosts.
The lesson: tuning exceptions must be as specific as possible. The correct suppression was: suppress ET SCAN from marketing workstations (10.0.2.0/24) where the destination is outside the corporate network (not RFC 1918). Internal scanning should never be suppressed categorically — that is exactly what post-compromise lateral movement looks like.
Triage Documentation — The Professional Standard
Every alert that passes through an analyst's queue must be documented, regardless of classification. Triage documentation serves multiple functions: it creates the audit trail that proves the SOC reviewed the alert (critical for compliance and incident post-mortems), it captures the reasoning behind classification decisions (allowing supervisors to review quality and new analysts to learn), it feeds the tuning process (patterns in false positive documentation reveal where signatures need refinement), and it forms the basis of any incident report if a true positive escalates.
A complete triage record covering all required fields. This format works for both ticket-based systems and structured SIEM case notes.
Alert ID: IDS-2026-05-26-0847 Time: 2026-05-26 08:47:23 UTC Analyst: J. Harrington Signature: ET WEB_SERVER SQL Injection Attempt (SID 2006445) Source: 45.33.32.156:54821 (Russia, AS49505, AbuseIPDB: 94/100) Destination: 10.0.0.80:80 (web01.corp.com -- Apache 2.4/MySQL) Investigation: 1. Source IP: AbuseIPDB 94/100 confidence, 847 prior phishing/scan reports 2. Destination: confirmed Apache/MySQL (CMDB verified), SQLi applicable 3. Payload: UNION SELECT injection in id parameter 4. Response: HTTP 200 with application data returned 5. Correlation: 23 additional alerts same source IP last 10 minutes Classification: TRUE POSITIVE -- Active SQL injection attack, data returned Actions taken: 08:49 Blocked 45.33.32.156 at perimeter firewall 08:51 Flagged web01.corp.com for app log review (check extraction success) 08:52 Created incident ticket INC-2026-0471 for app security team 08:55 Checked for additional affected hosts -- none in correlation window
Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — IDS/IPS Triage→← Return to all labs