SEC 450.1 — Blue Team Tools and Operations
1. Module Goals
This module covers [1]:
- Defining events, alerts, and incidents
- The flow of event logs versus alert logs
- Considerations for event and alert collection
- Goals for alert triage
- The distinction between signature-based and anomaly-based alerts
- The job of an analyst
2. Events, Alerts, and Incidents
Per NIST SP800-61 [2]:
- Event: Any observable occurrence in a system or network
- Alert: An event of interest that may be unwanted or unauthorized
- Incident: A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices
These form an escalating hierarchy: events feed into alerts, and alerts (once confirmed) escalate into incidents.
3. Event Collection
Most logs are records of events represented as transaction data [3] — for example:
- Endpoint process-creation logs (fields like UtcTime, ProcessId, Image, User, source/destination IP and port)
- Network service logs (proxy, web server access, DNS query, authentication logs)
4. How Much Should I Collect?
Collecting large volumes of events seems useful for detection, but comes with trade-offs [4]:
- In most SIEMs, more volume means more cost
- Searching more data takes longer
- Finding real signal becomes harder, slower, and more expensive (the “needle in a haystack” problem)
5. Event Log Flow
Network events and endpoint events flow into the SIEM, where enrichment and analytic rules are applied [5]. This generates alerts, which flow into a triage or incident management system for analyst review.
6. Alert Collection
Alerts are typically more structured and specific than raw events [6], often generated by IDS/IPS or firewall tools — for example:
- A Snort/Suricata rule match on a driveby exploit attempt
- A next-gen firewall log flagging a connection to a known malware-hosting URL
7. Alert Triage
Generated alerts are routed to one or more interfaces for triage [7]. The keys to successful triage are:
- Prioritization
- Context
- Speed
8. Successful Triage
Triage takes alerts from all sources as input and produces ranked alerts by priority as output [8]. Goals:
- Easy identification of the most important alerts or most dangerous attacks (based on high-priority systems, data, and users)
- Effective management of queue size
9. Alert Log Flow Options
Two general triage models [9]:
- Triaging alerts within separate point-product consoles — security tools may offer a better interface for assessing their own specific alert types
- Triaging all alerts in one consolidated queue (in the SIEM or elsewhere) — provides important context not available in individual appliances, and a single queue to work from
Alerts can originate as security-tool alerts (from monitoring tools with separate consoles) or as SIEM-generated alerts (from events plus analytic rules). Both paths can converge into a single “all alerts” queue.
10. Two Types of Alerts
An important question when triaging: “What type of alert am I looking at?” [10]
- Known-bad signature match: e.g., a known malware download or contact with a malicious domain
- Reads as: “something happened that looks like a known attack”
- Action: Verify whether the detection was correct or a false positive
- Anomaly-based alerts: e.g., a user login from a new PC/location or non-standard protocol usage
- Reads as: “an unusual thing happened here, but it’s not necessarily bad”
- Action: Investigate to verify both the anomaly itself and whether it is malicious
11. Designing Workflow Around the Two Alert Types
Triage workflow should prioritize the most dangerous items first [11]:
- Malicious-activity signature alerts are more likely to be dangerous and are typically addressed first
- Anomaly-based alerts are lower fidelity and require more time to investigate, but may catch unknown or novel attack types that signatures would miss
12. Discussion: IDS — Signature-Based or Anomaly-Based?
Example Snort/Suricata rule names for discussion [12]:
ET EXPLOIT Apache log4j RCE AttemptET JA3 Hash – Suspected Cobalt Strike Malleable C2ET POLICY Wget User AgentET CHAT IRC JOIN command
Which represent known-bad signature detections, and which are anomaly-based detections of unusual-but-not-inherently-malicious behavior?
13. High-Level Workflow
An interesting event leads to a generated alert [13]:
- If the alert is high-fidelity, a new incident ticket is created directly
- If not, the alert undergoes enrichment, correlation, and further analysis
- Is it genuine malicious activity (“evil”)?
- Yes → Incident ticket created
- No → Closed as false positive
14. True Positive and False Positive
A 2×2 framework relates predicted classes to true classes [14]:
| Attack Occurs | No Attack | |
|---|---|---|
| Alarm Activates | ✅ True Positive — server is saved | ⚠️ False Positive — unnecessary tension |
| No Alarm | ❌ False Negative — data is lost | ✅ True Negative — all good |
15. Events, Alerts and Incidents Summary
This section covered [15]:
- The differences between events, alerts, and incidents
- The differences between anomaly and signature-based detections
- With these definitions and an understanding of the flow of events and alerts, we can now jump into the tools that manage this information and the incidents created from their output
References
[1] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 70 — Module goals for Events, Alerts, Anomalies, and Incidents
[2] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 71 — NIST SP800-61 definitions: events, alerts, incidents
[3] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 72 — Event collection: log records as transaction data
[4] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 73 — Volume vs. cost vs. signal tradeoff in event collection
[5] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 74 — Event log flow: events through SIEM to alerts
[6] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 75 — Alert collection from IDS/IPS and firewall tools
[7] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 76 — Alert triage: routing alerts for analyst review
[8] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 77 — Successful triage: ranking alerts by priority
[9] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, pp. 78–79 — Alert log flow options: two triage models
[10] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 80 — Two types of alerts: known-bad signatures vs. anomalies
[11] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 82 — Workflow design: prioritizing signature vs. anomaly alerts
[12] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 83 — Discussion: IDS signature-based or anomaly-based detection examples
[13] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 84 — High-level alert workflow from event to incident or false positive
[14] NetRiders Academy — True Positive / False Positive confusion matrix
[15] SANS Institute. SEC450: Blue Team Fundamentals — Security Operations and Analysis (Book 1), 2022, p. 85 — Events, alerts, and incidents summary
