Unit 3: SIEM Tools & Event Analysis¶

Introduction¶

In Unit 1, you learned how networks function and how data flows between devices. In Unit 2, you performed packet-level analysis to identify suspicious or malicious activity at the individual communication level.

In this unit, we zoom out. Instead of examining one conversation at a time, we look at the entire organization at once using a tool called a Security Information and Event Management (SIEM) system.

Think of the difference this way: packet analysis is like reading a single letter. SIEM analysis is like managing a post office — tracking every letter, from every sender, to every destination, and flagging anything that looks out of place.

By the end of this unit, you will understand how SIEMs work, how to use them to investigate security events, and how to tune them so they catch real threats without drowning analysts in noise.

—

What Is a SIEM?¶

A Security Information and Event Management (SIEM) system is software that collects log data from across an organization, makes sense of it, and helps security teams detect and respond to threats.

Without a SIEM, each device on a network keeps its own logs. A firewall logs blocked connections. A web server logs page requests. A Windows workstation logs user logins. These logs sit in separate places, in different formats, with no connection to each other. If an attacker moves across multiple systems, no single log tells the whole story.

A SIEM solves this by:

Pulling logs from all of those sources into one place
Standardizing the format so they can be compared
Searching across all of them simultaneously
Correlating events so patterns become visible
Alerting analysts when something suspicious is detected

Common SIEM platforms include:

Splunk Enterprise Security — widely used in large enterprises; powerful query language called SPL (Search Processing Language)
Microsoft Sentinel — cloud-native SIEM integrated with Microsoft’s ecosystem
IBM QRadar — enterprise-focused with strong network flow analysis
Elastic SIEM — built on the open-source Elasticsearch stack
LogRhythm — known for built-in workflow and case management tools

Each platform has strengths depending on the organization’s size, budget, and existing infrastructure. The core concepts covered in this unit apply to all of them.

—

Why Centralized Logging Matters¶

Imagine an attacker who does the following over two days:

Tries 50 passwords on an employee’s email account (fails 49 times, succeeds once)
Logs into the VPN using the compromised account
Copies files from a shared drive to an external service

Without a SIEM:

The email system logs the failed attempts, but nobody is watching that log
The VPN system logs the login, but nobody connects it to the failed attempts
The file activity is logged, but in yet another system

With a SIEM, an analyst can search for all three events in a single query and immediately see the full picture of what happened — and when.

This is the fundamental value of a SIEM: connecting dots that would otherwise stay separate.

—

SIEM Architecture¶

Understanding how a SIEM is built helps you understand why it works the way it does and how to troubleshoot problems when something is missing or misconfigured.

Log Sources¶

A SIEM is only as useful as the data it receives. Common log sources include:

Firewalls — record which connections were allowed or blocked
Routers and switches — track network traffic flow between devices
IDS/IPS systems — generate alerts when known attack patterns are detected
Windows servers and workstations — record logins, privilege changes, software execution, and configuration changes
Linux servers — record system calls, file access, and authentication events
Web and application servers — record requests, errors, and user activity
Cloud platforms — AWS, Azure, and Google Cloud all generate audit logs for account activity and resource access
Email gateways — record message delivery, blocked attachments, and phishing attempts

The more sources you connect, the broader your visibility. However, more data also means more noise, which makes tuning (covered later) critical.

Collection Methods¶

Logs don’t arrive at a SIEM automatically — they have to be sent or retrieved. The main collection methods are:

Syslog: A standard protocol used by network devices and Linux systems to forward log messages to a central server. It is lightweight and widely supported but does not guarantee delivery.
Windows Event Forwarding (WEF): A built-in Windows feature that pushes event log entries to a central collector. Useful in Microsoft-heavy environments without needing extra software.
Agent-based collection: A small piece of software installed on the source system that monitors logs and forwards them to the SIEM. Agents offer more control and reliability than syslog but require installation and maintenance on each host.
API integrations: Cloud platforms and modern applications often expose logs through an API. The SIEM pulls data from these APIs on a schedule or in real time.

The Processing Pipeline¶

Once log data arrives at the SIEM, it moves through several stages before it becomes useful for analysis:

Ingestion — Raw data is received from the source, whether via syslog, agent, or API.
Parsing — The SIEM reads the raw text or data and identifies the individual fields. For example, it extracts the timestamp, the source IP address, the username, and the action taken from a firewall log entry.
Normalization — Field names are standardized across sources. A Windows login event might call the user field Account Name. A Linux system might call it user. After normalization, both become username so they can be compared in a single search.
Enrichment — Additional context is added automatically. A raw IP address might be enriched with its geographic location (GeoIP), whether it appears on known threat intelligence feeds, or whether it belongs to the organization’s own address space.
Storage — Events are written to an indexed database optimized for fast searching across large volumes of data.
Correlation and alerting — The SIEM applies rules to the incoming stream of events, looking for patterns that match known attack behaviors and triggering alerts when matches occur.

Each stage builds on the last. If parsing is broken, normalization fails. If normalization fails, correlation rules produce incorrect results. Getting the pipeline right is foundational.

—

Log Types and Event Categories¶

Not all logs are equal. Understanding what kind of information each log type contains helps you know where to look when investigating an incident.

Authentication Logs¶

Authentication logs record whenever a user (or a system acting as a user) proves their identity — or fails to. These logs are among the most valuable for detecting account-based attacks.

Key events to watch for:

Successful logins — establishes who authenticated, from where, and when
Failed logins — single failures are normal; many failures in a short time suggest a brute-force attack
Account lockouts — often triggered automatically after too many failures; a pattern of lockouts across many accounts may indicate password spraying
Privilege escalation — when a standard user account gains administrative access, either legitimately or through exploitation

Authentication logs are generated by domain controllers, VPN systems, remote desktop services, web applications, and operating systems.

Network Logs¶

Network logs record what traffic moved across the network and what decisions were made about it.

Firewall allow/deny events — show which connections succeeded and which were blocked; sudden spikes in denied traffic can indicate scanning or an active attack
DNS queries — every device that looks up a domain name generates a DNS log; unusual domains, newly registered domains, or domains associated with malware command-and-control infrastructure often appear here first
VPN connections — record who connected remotely, from where, and when; useful for detecting account compromise or unauthorized access
Proxy logs — if web traffic passes through a proxy, these logs record every URL visited, which helps identify data exfiltration or communication with malicious sites

System Logs¶

System logs record what is happening on the operating system itself, independent of any specific user action.

Service start/stop — legitimate processes start and stop on schedule; attackers often install malicious services that appear in these logs
Process execution — records which programs ran, when, and under which user account; a legitimate user running a network scanning tool is a red flag
Configuration changes — modifications to security settings, firewall rules, or system policies are high-value events worth monitoring closely
File access events — records when sensitive files or directories are read, modified, or deleted

Security Alerts¶

These are events generated not by an underlying system but by a security tool that has already identified something suspicious.

Malware detections from endpoint protection software
IDS/IPS alerts when traffic matches a known attack signature
Vulnerability scanner alerts (important to recognize these because they can look like attacks and cause false positives)
Endpoint detection and response (EDR) alerts from tools that monitor behavior on workstations and servers

Security alerts are pre-filtered and high priority, but they still require human validation — automated tools produce false positives too.

—

Configuring a SIEM¶

A SIEM out of the box detects nothing useful. It has to be configured for your specific environment before it provides meaningful value.

Step 1: Define What You Want to Detect¶

Before connecting anything, decide what threats matter most to your organization. This shapes everything else. Common starting points include:

Detecting brute-force login attempts against user accounts
Identifying when a user transfers an unusually large volume of data outside the network
Monitoring the use of privileged administrator accounts
Detecting lateral movement — when an attacker moves from one internal system to another
Alerting when new software is installed on servers without an approved change request

Without defined use cases, you end up with an expensive log storage system rather than a detection platform.

Step 2: Onboard Log Sources¶

Once you know what you want to detect, identify which log sources are needed to detect it. Onboarding a log source typically involves:

Installing an agent on the source system, or configuring it to forward logs via syslog
Enabling the right logging policies on the source (Windows, for example, has many audit categories that are disabled by default)
Verifying that logs are arriving in the SIEM and that timestamps are correct
Confirming that the SIEM is parsing the logs correctly — spot-checking a few raw events and making sure fields are being extracted as expected

Step 3: Normalize and Map Fields¶

As described in the processing pipeline, normalization ensures that the same concept is called the same thing regardless of which device generated the log.

Standard field names used across most SIEM platforms include:

src_ip — the IP address that initiated the connection or action
dest_ip — the IP address that received the connection or action
username — the account associated with the event
event_id — a numeric code identifying the specific event type
timestamp — when the event occurred (critical to get right — clock skew on source systems causes events to appear out of order)
action — what happened (allowed, denied, failed, succeeded)

Proper normalization is what makes it possible to write a single rule that catches brute-force attempts across Windows, Linux, and web application logs simultaneously.

—

Correlation and Detection Rules¶

Correlation is the heart of what makes a SIEM more powerful than a log viewer. A correlation rule watches the incoming stream of events and triggers an alert when a specific pattern is met.

Understanding Correlation Rules¶

A rule has several components:

Event source: Which type of log or device should trigger this rule. A brute-force rule watches authentication logs. A data exfiltration rule might watch firewall and proxy logs.
Condition: The logic that must be true for the rule to fire. Conditions can check field values (action = "failed_login"), counts (count > 5), or sequences (event A followed by event B).
Threshold: A numeric limit, often combined with a time window. Five failures in two minutes is a threshold. The right threshold depends on your environment — a shared service account used by thousands of automated systems will generate many more failures than a personal user account.
Aggregation key: The field used to group events before counting. For brute-force detection, you group by username so you can tell whether five failures all targeted the same account or five different accounts.
Time window: The span of time over which the threshold is evaluated. A two-minute window catches rapid automated attacks. A 24-hour window might catch slower, more patient attackers.
Severity level: How urgent the alert is. Severity should reflect the likelihood that the event is a real threat and the potential impact if it is.

Brute Force Detection¶

A brute-force attack is when an attacker tries many passwords against an account in rapid succession, hoping to guess correctly.

A basic detection rule:

Condition: failed login events for the same username
Threshold: 5 or more failures
Time window: within 2 minutes
Aggregation key: username
Action: trigger alert and notify the security team

A more sophisticated version also checks whether a successful login follows shortly after the failed attempts — a strong indicator that the brute-force worked.

Password Spraying¶

Password spraying is a variation on brute force. Instead of trying many passwords against one account, the attacker tries one common password against many accounts. This avoids triggering account lockout policies.

A password spraying detection rule looks different from a brute-force rule:

Condition: failed login events across different usernames
Threshold: failures affecting 10 or more distinct usernames
Time window: within 5 minutes
Aggregation key: src_ip (the source doing the spraying)
Action: trigger high-severity alert

The key difference is that the aggregation is on the source IP rather than the username — you’re looking for one attacker hitting many targets.

Impossible Travel¶

An impossible travel alert fires when the same user account authenticates from two geographic locations within a time window that makes physical travel between them impossible.

Example:

8:00 AM — successful login from New York
8:45 AM — successful login from London

A person cannot fly from New York to London in 45 minutes. This either means the account is compromised (someone else is using it), or the user is employing a VPN that masks their real location.

Rule logic:

Condition: two successful logins from the same username
Check: calculate the distance between login locations and divide by the time between logins to get a required travel speed
Threshold: required travel speed exceeds a physically possible limit
Severity: high

This type of rule requires GeoIP enrichment to be working correctly in the pipeline.

Data Exfiltration Detection¶

Data exfiltration is when an attacker (or a malicious insider) copies sensitive data out of the organization.

Detection approaches:

Volume-based: alert when a user uploads an unusually large amount of data to an external service, compared to their own historical baseline
Destination-based: alert when data is sent to a country or cloud provider the organization does not normally do business with
Time-based: alert when large data transfers occur at unusual hours, such as 2 AM on a weekend

Exfiltration rules often combine network logs (which show the volume and destination of transfers) with authentication logs (to confirm who was logged in at the time).

—

Querying and Investigating Events¶

When an alert fires, the investigation begins. SIEM platforms provide query languages that let analysts search across millions of log entries in seconds.

Writing Queries¶

Most SIEM query languages follow a similar pattern: filter events down to a relevant subset, then perform some calculation or summarization.

A Splunk-style query to find brute-force candidates:

index=authentication_logs
action="failed_login"
| stats count by username, src_ip
| where count > 5
| sort - count

Reading this step by step:

index=authentication_logs — look only in the authentication logs
action="failed_login" — filter to only failed login events
| stats count by username, src_ip — count how many times each username/IP combination appears
| where count > 5 — only show combinations with more than 5 failures
| sort - count — show the highest counts first

Another example — finding logins outside of business hours:

index=authentication_logs
action="successful_login"
| eval hour=strftime(_time, "%H")
| where hour < 7 OR hour > 19
| table timestamp, username, src_ip, hour

This query extracts the hour from each successful login timestamp and filters to only those occurring before 7 AM or after 7 PM.

The Investigation Workflow¶

A structured approach prevents investigators from going in circles or missing important context. Follow these steps:

1. Validate the alert

Before doing anything else, determine whether the alert is a true positive (a real threat) or a false positive (a benign event that matched a rule). Check whether the activity makes sense in context. A brute-force alert at 9 AM targeting an IT admin account is very different from one at 3 AM targeting an account that has been inactive for months.

2. Identify the affected user or system

Determine exactly which account, device, or service is involved. Collect identifiers: username, IP address, hostname, device ID.

3. Establish a timeline

Use the SIEM to build a chronological sequence of events. Find:

The first suspicious event
What happened immediately before it (for context)
What happened afterward (did the attacker succeed? Did they move laterally?)

4. Check for lateral movement

If an account or system was compromised, look for evidence that the attacker used it as a stepping stone. Did the compromised account authenticate to other systems? Did it access new file shares? Did new processes run on the affected host?

5. Determine scope and impact

How many systems are involved? What data was accessed? Are there signs that data left the organization? Was any malware installed?

6. Document findings

Write up what you found, in order. Good documentation supports escalation to incident response, legal or compliance requirements, and post-incident review.

—

Dashboards and Visualization¶

Dashboards give security teams a real-time overview of what is happening across the environment without requiring manual queries. A well-built dashboard surfaces the most important information immediately.

What Makes a Good Dashboard¶

A good dashboard is designed around specific questions. Ask: what does a security analyst need to know at a glance to understand whether the environment is healthy?

Principles of effective dashboard design:

Focus on actionable metrics — show things that require a response, not just things that are interesting
Avoid clutter — too many widgets make it hard to notice when something is wrong
Use clear severity indicators — color coding (green/yellow/red) helps analysts quickly triage what needs attention
Enable drill-down — clicking a metric should take the analyst directly to the underlying events so they can investigate without starting from scratch

Common Dashboard Widgets¶

Top failed login sources: Shows which IP addresses are generating the most authentication failures. A single IP at the top of this list is a strong indicator of a brute-force or spraying attempt.
Geographic login map: Visualizes where successful logins are originating from. Logins from unexpected countries stand out immediately.
Malware detections over time: A timeline of endpoint protection alerts. A sudden spike may indicate an outbreak or an attacker deploying tools across multiple systems.
Network traffic volume by destination: Highlights unusual spikes in outbound traffic, which may indicate data exfiltration or a device participating in a denial-of-service attack.
Alert severity distribution: Shows the ratio of low, medium, and high severity alerts. A sudden increase in high-severity alerts requires immediate attention.
Privileged account activity: Tracks when and how administrator accounts are used. Activity outside of change windows or from unexpected locations is a red flag.

—

Event Analysis Methodology¶

Responding to an alert is a skill that improves with practice and structure. The following methodology applies to most investigations.

Validate the Alert¶

Not every alert represents a real threat. Before treating an alert as an incident:

Review the rule that fired. Is it well-tuned, or does it have a history of false positives?
Look at the raw events. Do they match the alert description?
Check whether there is a known benign explanation. A vulnerability scanner running on schedule will trigger brute-force rules. A developer deploying code during a maintenance window may trigger configuration change alerts.

If the alert is a false positive, document why and consider adjusting the rule.

Establish a Timeline¶

A timeline is the backbone of any investigation. It answers: what happened, in what order, and how quickly?

To build one:

Set your SIEM time range to start before the first suspicious event
Search broadly first (all events from the affected account or IP), then narrow
Note timestamps precisely — a gap of two minutes between events means something different than a gap of two hours

A good timeline makes it possible to distinguish between an attack that is still in progress and one that ended hours ago.

Identify Impact¶

Impact assessment answers: how bad is this?

Consider:

Systems affected: one workstation vs. a domain controller vs. a database server carry very different levels of risk
Accounts involved: a standard user account vs. an administrator account vs. a service account used by critical systems
Data accessed: did the affected account or system have access to sensitive data? Were those files opened or copied?
Duration: how long was the attacker active before detection?

Containment and Escalation¶

Once you understand what happened, take action:

Disable compromised accounts immediately to prevent further access
Isolate affected systems from the network if there is evidence of active compromise or malware
Preserve evidence — do not wipe or reboot systems before forensic data is collected
Escalate to incident response if the scope exceeds what a SIEM analyst should handle alone
Create formal documentation — a clear, timestamped record of findings, actions taken, and outstanding questions

—

Tuning and Reducing False Positives¶

A SIEM that generates hundreds of alerts per day, most of which are harmless, trains analysts to ignore alerts. This is called alert fatigue, and it is one of the most dangerous failure modes in a security program — real attacks get buried in noise.

Why False Positives Happen¶

Poorly defined thresholds: A brute-force rule set to trigger after 3 failures will fire constantly in an environment where users regularly mistype their passwords. The threshold needs to reflect what is normal for that environment.
Missing contextual data: A rule that fires on failed logins without considering the source IP cannot distinguish between a user locked out of their own account and an external attacker. Adding context (is the source internal or external? is this a service account?) dramatically improves accuracy.
Shared or automated accounts: Service accounts used by automated systems often authenticate thousands of times per hour. Rules that treat them like human user accounts generate constant false positives. These accounts need to be handled differently — either excluded from certain rules or given their own baselines.
Vulnerability scanners: Internal vulnerability scanners probe every system for weaknesses. From a SIEM’s perspective, this looks like an attacker scanning the network. If the scanner’s IP is not whitelisted, it generates noise across multiple rule types simultaneously.

Tuning Techniques¶

Whitelisting known-good sources: Exclude trusted IP addresses (like vulnerability scanners or monitoring systems) from rules where their activity is expected and benign.
Adjusting thresholds and time windows: After reviewing a rule’s performance over time, raise or lower thresholds to match the environment’s baseline. A threshold that is too low generates false positives; one that is too high misses real attacks.
Adding contextual conditions: Instead of alerting on any 5 failed logins, alert on 5 failed logins from an IP address that is not on the internal network range. This one addition eliminates a large category of false positives caused by users forgetting their passwords.
Incorporating threat intelligence: Connect the SIEM to threat intelligence feeds that provide lists of known malicious IP addresses, domains, and file hashes. Rules that match against these lists are more precise than rules based on behavior alone.
Baselining normal behavior: Some SIEM platforms support behavioral analysis, which learns what is normal for each user or system and alerts only when behavior deviates significantly from that baseline. A user who suddenly downloads 100 times more data than usual is flagged even if the absolute volume does not cross a fixed threshold.

The Continuous Improvement Loop¶

Tuning is never finished. After every significant incident or investigation:

Review whether the relevant rules fired as expected
Identify any gaps — events that should have triggered an alert but did not
Improve log coverage if key events were missing from the SIEM
Update thresholds and conditions based on what the incident revealed about normal vs. abnormal behavior in your environment

A SIEM that is actively maintained becomes more accurate over time. One that is deployed and ignored becomes a liability.

—

Putting It All Together: A Sample Scenario¶

The following example illustrates how the concepts in this unit work together in a real investigation.

The alert: At 2:14 AM, the SIEM fires a high-severity alert: 47 failed login attempts against the finance_admin account from IP address 203.0.113.44 over a period of 90 seconds.

Step 1 — Validate: The analyst checks the raw events. The failures are real, consistent, and come from an IP address in a country the organization does not operate in. This is not a vulnerability scanner. The alert is a true positive.

Step 2 — Check for success: The analyst queries authentication logs for finance_admin during the same time window. At 2:15 AM — one minute after the failures began — there is a successful login from the same IP address.

Step 3 — Timeline: The analyst expands the timeline to see what happened after the successful login. Over the next 20 minutes, finance_admin authenticated to three file servers and a cloud storage service. The cloud storage service shows 4.2 GB of outbound data transfer.

Step 4 — Containment: The analyst disables the finance_admin account and blocks the external IP address at the firewall. The incident is escalated to the incident response team.

Step 5 — Review: After the incident, the team notes that the brute-force rule fired 90 seconds into the attack. The successful login happened at the one-minute mark. The rule’s threshold was 40 failures — too high. It is adjusted to 10 failures in 60 seconds to catch future attacks before they succeed.

This scenario illustrates why each component of a SIEM program matters: detection, investigation, containment, and continuous improvement all play a role.

—

Summary¶

Packet analysis (Unit 2) shows you individual conversations in detail. SIEM analysis shows you the entire organization at once.

The two approaches are complementary. SIEM correlation and alerting surfaces events worth investigating. Packet analysis provides the low-level evidence needed to understand exactly what an attacker did once you know where to look.

The skills covered in this unit — understanding the processing pipeline, onboarding log sources, writing correlation rules, following investigation workflows, and continuously tuning detections — form the foundation of day-to-day work in a Security Operations Center (SOC).

—

Quiz¶

Choose the best answer for each question.

An organization stores logs from its firewall, email gateway, and Windows servers in three separate systems with no connection between them. What is the most significant security risk this creates?
1. Logs will consume too much disk space
2. An attack that spans multiple systems may go undetected
3. Firewall rules cannot be enforced properly
4. Users will have slower login times
A SIEM processing pipeline includes a stage where all log sources use the same field name for a user account (username) regardless of what the original device called it. What is this stage called?
1. Ingestion
2. Enrichment
3. Normalization
4. Correlation
During the enrichment stage, a SIEM automatically adds the country of origin to every log entry that contains an IP address. What data source makes this possible?
1. GeoIP database
2. Windows Event Forwarding
3. Syslog forwarding
4. The firewall rule set
A security team notices that their brute-force detection rule is constantly firing alerts for a service account used by an automated backup system that runs every hour. What is the most appropriate corrective action?
1. Whitelist the backup system’s IP address or account from the rule
2. Disable logging on the backup system
3. Delete the brute-force detection rule
4. Increase the account lockout threshold for all accounts
An analyst sees a successful login from user jsmith in Chicago at 9:00 AM, followed by another successful login from the same account in Tokyo at 9:40 AM. What type of SIEM rule would flag this activity?
1. Brute-force detection
2. Privilege escalation detection
3. Impossible travel detection
4. Data exfiltration detection
A password spraying attack differs from a brute-force attack in a critical way. Which of the following best describes that difference?
1. Password spraying uses encrypted traffic; brute force does not
2. Password spraying is faster than brute force
3. Password spraying requires physical access; brute force does not
4. Password spraying targets many accounts with one password; brute force targets one account with many passwords
An analyst is investigating an alert about a large data transfer. Which combination of log sources would be most useful for determining both the volume of data sent and who was logged in at the time?
1. DNS logs and system logs
2. Malware detection alerts and service start/stop logs
3. IDS alerts and firewall configuration logs
4. Network/proxy logs and authentication logs
A SIEM analyst is overwhelmed by alerts, most of which turn out to be benign activity from an internal vulnerability scanner. What is the most targeted fix for this problem?
1. Raise all alert thresholds organization-wide
2. Disable alerting during business hours
3. Whitelist the scanner’s IP in relevant detection rules
4. Replace the SIEM with a different platform
After a brute-force attack succeeds, an analyst builds a timeline and finds that the compromised account then logged into two internal servers and a cloud file-sharing service. What behavior does this most likely represent?
1. Normal user activity
2. Lateral movement followed by potential data exfiltration
3. A misconfigured service account
4. A failed brute-force attempt
A correlation rule fires correctly when an attack occurs but also fires dozens of times per week for benign activity. After reviewing the rule, the team decides to add an additional condition requiring the source IP to be from outside the corporate network. What is the expected outcome of this change?
1. The rule will produce fewer false positives while still catching external threats
2. The rule will stop detecting external attacks
3. The rule will fire more frequently
4. The rule will require a new log source to function

—

Answer each question in 2–4 sentences.

Explain why the normalization stage is necessary in a SIEM processing pipeline. Use a specific example of what could go wrong without it.
Describe the difference between a brute-force detection rule and a password spraying detection rule. What is the key difference in how the aggregation works?
What is alert fatigue, and why is it considered a security risk rather than just an inconvenience?
A SIEM rule fires an alert for a failed login event. Describe two pieces of additional context an analyst should gather before deciding whether to treat this as a real incident.
After a security incident is fully resolved, what actions should the security team take regarding their SIEM rules and log coverage? Why is this step important?

—

Answer Key¶

Part A: Multiple Choice

B — See Why Centralized Logging Matters section. An attack that spans multiple systems (initial compromise, lateral movement, data exfiltration) will not be visible in any single log. Without correlation across sources, the full attack chain remains invisible.
C — See The Processing Pipeline subsection. Normalization is the stage that standardizes field names across different log sources so they can be compared and searched consistently.
A — See The Processing Pipeline subsection. GeoIP databases map IP addresses to geographic locations and are used during enrichment to add location context to log events.
A — See Tuning Techniques subsection. Whitelisting the known-good source prevents the rule from firing on expected benign activity without disabling the rule entirely or introducing broader changes.
C — See Impossible Travel subsection. A login from Chicago followed by a login from Tokyo 40 minutes later is physically impossible and is the defining pattern that impossible travel rules are designed to detect.
D — See Password Spraying subsection. Spraying uses one common password against many accounts to stay below account lockout thresholds. Brute force uses many passwords against one account.
D — See Log Types and Event Categories section. Network and proxy logs show volume and destination of data transfers. Authentication logs show who was logged in. Together they establish both the activity and who performed it.
C — See Tuning Techniques subsection. Whitelisting the scanner’s IP is the most targeted solution — it addresses the specific source of false positives without broadly weakening detection across the environment.
B — See The Investigation Workflow subsection and Putting It All Together section. Moving from an initially compromised account to other internal systems is lateral movement. Sending data to an external cloud service shortly afterward suggests data exfiltration.
A — See Tuning Techniques subsection. Adding a condition that limits the rule to external sources removes the category of false positives caused by internal activity while preserving detection of external attacks.

Part B: Short Answer — Sample Responses

Normalization ensures that the same concept (such as a username) uses the same field name regardless of which device generated the log. Without it, a correlation rule designed to detect brute force would only search the field name used by one type of device. For example, Windows logs might call the field Account Name while Linux logs call it user — without normalization, a single rule cannot match both, and cross-platform attacks go undetected.
A brute-force rule counts failures grouped by username — it looks for many attempts targeting the same account. A password spraying rule counts failures grouped by source IP — it looks for one source hitting many different accounts. The aggregation key is different because the attacker’s behavior is different: brute force is deep (many attempts, one target) and spraying is wide (one attempt, many targets).
Alert fatigue occurs when analysts receive so many alerts — most of them false positives — that they begin to treat all alerts as noise. It is a security risk because real attacks get buried alongside the false positives and may be ignored or dismissed without proper investigation, effectively disabling the detection system despite it technically still running.
The analyst should check how many failures occurred and over what time period (one failure is likely a typo; 50 failures in 60 seconds suggests an automated attack). They should also identify whether the source IP is internal or external to the organization, since an external IP failing to log in is far more suspicious than an employee mistyping their password from the office.
The team should review whether existing rules detected the attack as early as possible and identify any gaps where relevant events were missing from the SIEM. They should adjust rule thresholds and conditions based on what the incident revealed about attacker behavior and normal activity in the environment. This step is important because each incident is an opportunity to improve detection so that the same type of attack is caught faster — or prevented — in the future.

—

End of Unit 3