Exam questions describe a security scenario and ask which log source provides the needed information. Use this decision tree:
- "Was this connection allowed or blocked at the perimeter?" → Firewall logs
- "What application is generating this traffic on an unusual port?" → NGFW application ID
- "Did this user log in successfully? How many times did they fail?" → Application / OS security logs
- "What attack signature was detected?" → IPS/IDS logs
- "Where did this email actually come from?" → Email metadata (headers)
- "What is happening right now in my environment?" → Dashboard
- "What happened over the past 90 days?" → SIEM / historical reports
- "What exactly was transmitted in each packet?" → Packet capture (Wireshark)
The exam will rarely name the log source directly — it will describe a scenario and require you to identify which source answers that specific question.
Metadata questions will either ask what metadata is, or describe a situation and ask whether content or metadata is being examined.
Key rule: Metadata answers who/when/where/how. Content answers what.
- Email headers (relay path, DMARC results) = metadata, not content
- GPS coordinates in a photo = metadata (EXIF), not the photo itself
- File author and creation date = metadata, not the file body
- NetFlow bytes/duration per connection = metadata, not packet payload
Exam trap: "An analyst reviewed email headers to determine the source of a phishing message" = metadata analysis, NOT content analysis. The message body was not read. Metadata can be forensically sufficient to establish origin without reading content.
Second trap: NetFlow/IPFIX is metadata about network connections. It does NOT capture payload. If an exam question requires payload analysis, metadata is wrong — packet capture is the answer.
This distinction appears in questions about what tool to use for a given task. Time horizon determines the answer:
- Current status / right now / real-time → Dashboard
- Last week / last quarter / 90 days ago / forensic review → SIEM report / historical analysis
Dashboards are SOC monitoring tools. SIEM reports are compliance, management, and forensic tools.
Exam trap: "The security manager needs to review all failed login attempts from the past 30 days." Answer: SIEM scheduled report or ad-hoc query, not a dashboard. Dashboards typically retain only a short window of data and are not designed for historical review.
Both require SIEM as the backend — dashboards visualize real-time SIEM data, reports query historical SIEM data. The SIEM is the source for both; the dashboard and report are different views into that source.
SIEM correlation questions describe a detection that requires combining events from multiple log sources. If the scenario describes a single log source finding something, it is not a SIEM correlation question.
Classic SIEM correlation patterns:
- Impossible travel: two authentication events from distant locations (auth logs + geo lookup)
- Brute force success: N failed logins followed by success (auth logs over time)
- IPS alert + vulnerability scan: exploit attempt against a confirmed-vulnerable system = critical
- Data exfiltration: unusual outbound data volume (firewall + endpoint logs + DLP)
Memory hook: SIEM = "Sees It Everywhere Merged." The value of SIEM is that it takes data from everywhere and merges it to see patterns no single source can see.
Practice Scenarios
A security analyst must answer five different questions during an investigation. For each question, identify the best log source:
- An employee claims she never received a suspicious email. Was it blocked by the email gateway?
- A file found on a compromised system shows a different author than expected. What log source reveals the original author without reading the file content?
- The CISO wants a monthly summary of all firewall policy changes for compliance review.
- Malware on a compromised workstation is communicating with an external IP. What exact protocol is it using?
- A WAP is reporting unusual de-authentication floods. What type of attack does this indicate?
Answers: (1) Email gateway/application logs — show whether the message was delivered or quarantined. (2) File metadata (author field) — this is metadata, not content; no need to read the file. (3) SIEM scheduled report — historical monthly view, not a dashboard. (4) Packet capture (Wireshark/pcap) — only log source with full payload to identify the C2 protocol precisely. (5) WAP logs showing de-auth floods indicate a de-authentication (de-auth) attack, often used to force clients off a legitimate AP to connect to an evil twin. WAP logs are the specific source for wireless authentication events.
A SIEM generates an alert: "Account JSmith authenticated successfully from Chicago at 09:00. Account JSmith authenticated successfully from Amsterdam at 09:12. IPS detected port scanning from 203.0.113.47 targeting JSmith's workstation at 09:15. Vulnerability scan data shows JSmith's workstation has CVE-2024-1234 unpatched (CVSS 9.8). JSmith's VPN session (Chicago) downloaded 4.2 GB in 8 minutes at 09:18."
What three log sources contributed to this SIEM alert? What does the full correlation indicate? What immediate action is required?
Answer: Three sources: (1) Authentication logs (impossible travel: Chicago at 09:00 + Amsterdam at 09:12). (2) IPS logs (port scan against JSmith workstation). (3) Vulnerability scan data (CVE-2024-1234 unpatched on target). Bonus: VPN data volume logs (4.2 GB download). Full correlation indicates: JSmith credentials are compromised (impossible travel). An attacker (Amsterdam) is using the credentials remotely. A second attacker or the same is scanning JSmith's workstation, targeting a known critical vulnerability. Simultaneously, large data transfer is occurring on the VPN session. This is an active, multi-vector attack. Immediate actions: disable JSmith account, isolate the workstation, capture RAM before shutdown, engage incident response team, escalate to management.
A company has 5,000 Windows workstations. Each generates approximately 2,000 security events per hour (Event ID 4624 logon success, 4625 logon failure, 4634 logoff, 4648 explicit credential use, and hundreds of other routine events). The SIEM administrator wants to forward all events to SIEM for comprehensive visibility. The security team objects, noting that the relevant events are fewer than 50 per hour per workstation.
What is the problem with forwarding all OS security events? What approach should be taken, and which event types are genuinely security-relevant?
Answer: Forwarding all events from 5,000 workstations at 2,000 events/hour = 10 million events/hour. This overwhelms SIEM storage (licensing cost scales with event volume), buries relevant events in noise (analysts cannot triage effectively), and degrades SIEM query performance. Approach: implement log collector filtering rules before SIEM forwarding. Forward only security-relevant events: 4625 (failed logon — brute force indicator), 4648 (explicit credential use — pass-the-hash indicator), 4720 (account creation), 4728/4732 (group membership changes — privilege escalation), 4698 (scheduled task creation — persistence), 1102 (audit log cleared — anti-forensics indicator). Routine logon success (4624) and logoff (4634) events from all workstations are high-volume with low signal value and should be filtered or sampled rather than forwarded completely.