Chapter 3: SIEM & Data Lake Basics - Quiz¶

**A)** Successful logins from unusual locations
**B)** Brute force attempts (>10 failed logins per account/IP pair)
**C)** Process creations with encoded commands
**D)** Network connections to malicious IPs

??? success "Answer"
    **Correct Answer: B) Brute force attempts (>10 failed logins per account/IP pair)**

    **Explanation:** Let's break down the query:

    ```spl
    index=windows_auth EventCode=4625    # Windows failed login events
    | stats count by Account_Name, Source_IP  # Count failures per account+IP
    | where count > 10                    # Only show if >10 attempts
    | sort -count                         # Order by most attempts first
    ```

    **Windows Event IDs:**
    - **4624:** Successful login
    - **4625:** Failed login
    - **4634/4647:** Logoff

    This query identifies brute force password guessing attempts by flagging accounts with more than 10 failed login attempts from the same source IP.

    **Reference:** [Chapter 3, Section 3.3 - Example 1: Search for Failed Logins](../chapters/ch03-data-modeling-normalization.md)

**A)** To delete failed login events
**B)** To find accounts with >10 failed logins FOLLOWED BY a successful login (potential brute force success)
**C)** To encrypt the query results
**D)** To create new user accounts

??? success "Answer"
    **Correct Answer: B) To find accounts with >10 failed logins FOLLOWED BY a successful login (potential brute force success)**

    **Explanation:** This query detects **successful** brute force attacks:

    **Logic:**
    1. Find accounts with >10 failed logins (EventID 4625) in last 10 minutes
    2. Join with successful logins (EventID 4624) on the same account
    3. Result: Accounts that experienced failed attempts AND then successfully authenticated

    **Why This Matters:**
    - Failed logins alone might be typos or legitimate password resets
    - Failed logins + successful login = Attacker may have guessed the password
    - This is a higher-fidelity alert than just failed login counts

    **Reference:** [Chapter 3, Section 3.3 - Example 2: Detect Brute Force](../chapters/ch03-data-modeling-normalization.md)

**A)** Combining events from different log sources
**B)** Triggering an alert when a count/value exceeds a defined limit (e.g., >10 failed logins in 5 minutes)
**C)** Encrypting correlation results
**D)** Automatically blocking IPs

??? success "Answer"
    **Correct Answer: B) Triggering an alert when a count/value exceeds a defined limit**

    **Explanation:** Threshold-based correlation triggers alerts when event counts or values cross predefined boundaries.

    **Example:**
    ```
    IF failed_login_count > 10 in 5 minutes
    THEN alert "Brute Force Attempt"
    ```

    **Other Correlation Types:**
    - **Sequence-based:** Event A followed by Event B within timeframe
    - **Behavioral anomaly:** Activity exceeds baseline + standard deviations

    **Tuning Challenge:** Setting thresholds too low = false positives; too high = missed threats.

    **Reference:** [Chapter 3, Section 3.4 - Types of Correlation](../chapters/ch03-data-modeling-normalization.md)

**A)** Real-time alerting on brute force attempts
**B)** Historical investigation of a 6-month-old breach
**C)** Sub-second dashboard updates
**D)** Active incident response coordination

??? success "Answer"
    **Correct Answer: B) Historical investigation of a 6-month-old breach**

    **Explanation:**

    **SIEM (Hot Path):**
    - Real-time detection and alerting
    - Active incident response
    - Fast dashboards and searches
    - **Timeframe:** Last 30-90 days

    **Data Lake (Cold Path):**
    - Historical investigations (6+ months ago)
    - ML model training on large datasets
    - Compliance audits requiring years of logs
    - Cost-effective long-term retention
    - **Timeframe:** 1-7 years

    **Example Workflow:**
    ```
    Active incident → Query SIEM (fast results)
    Historical breach analysis → Query data lake (Athena, Databricks)
    ML training → Pull raw data from data lake
    ```

    **Reference:** [Chapter 3, Section 3.5 - Hybrid Architecture](../chapters/ch03-data-modeling-normalization.md)

**A)** To delete events
**B)** To aggregate data (count, sum, average) by specified fields
**C)** To encrypt search results
**D)** To create new user accounts

??? success "Answer"
    **Correct Answer: B) To aggregate data (count, sum, average) by specified fields**

    **Explanation:** The `stats` command performs aggregation operations in SPL:

    **Common Operations:**
    ```spl
    | stats count by user                  # Count events per user
    | stats sum(bytes) by dest_ip          # Total bytes per destination
    | stats avg(response_time) by service  # Average response time
    | stats values(host) by user           # List unique hosts per user
    ```

    **Example:**
    ```spl
    index=firewall action=allowed
    | stats count by dest_ip, dest_port
    | where count > 100
    ```
    This finds destinations with >100 connections, useful for detecting data exfiltration or port scans.

    **Reference:** [Chapter 3, Section 3.3 - Writing SIEM Queries](../chapters/ch03-data-modeling-normalization.md)

**A)** It's perfectly optimized
**B)** It uses wildcards inefficiently, searching all indexes and sources (slow and resource-intensive)
**C)** It will automatically fix itself
**D)** It only searches encrypted data

??? success "Answer"
    **Correct Answer: B) It uses wildcards inefficiently, searching all indexes and sources (slow and resource-intensive)**

    **Explanation:** This query violates SIEM query optimization best practices:

    **Problems:**
    - `index=*` searches ALL indexes (could be 50+ indexes across terabytes)
    - `source=*` searches all data sources
    - `user=*` searches all users
    - Result: Extremely slow, high resource consumption

    **Optimized Version:**
    ```spl
    index=windows_auth EventCode=4625
    | stats count by Account_Name
    | where count > 5
    | sort -count
    ```

    **Optimization Rules:**
    1. Specify exact index
    2. Use specific EventCode/sourcetype
    3. Use specific field names instead of wildcards
    4. Add time constraints (`earliest=-24h`)
    5. Filter early (before stats/joins)

    **Reference:** [Chapter 3, Practice Tasks - Task 3: Optimize a Query](../chapters/ch03-data-modeling-normalization.md)

**A)** Total number of alerts generated
**B)** TP / (TP + FP) - The percentage of alerts that are actually malicious
**C)** TP / (TP + FN) - The percentage of threats that were detected
**D)** Response time per alert

??? success "Answer"
    **Correct Answer: B) TP / (TP + FP) - The percentage of alerts that are actually malicious**

    **Explanation:**

    **Precision = TP / (TP + FP)**
    - **Meaning:** Of all alerts the rule generates, how many are true threats?
    - **High Precision:** Few false alarms, analyst time well-spent
    - **Example:** 90 true positives, 10 false positives → Precision = 90%

    **Recall = TP / (TP + FN)**
    - **Meaning:** Of all actual threats, how many did the rule catch?
    - **High Recall:** Few missed threats

    **Tuning Trade-offs:**
    - Increasing threshold: Higher precision, lower recall
    - Decreasing threshold: Lower precision, higher recall
    - Goal: Balance based on risk tolerance and analyst capacity

    **Reference:** [Chapter 3, Section 3.6 - Metrics for Tuning](../chapters/ch03-data-modeling-normalization.md)

**A)** Alert when failed logins exceed 10
**B)** Alert when login from IP_A is followed within 1 hour by login from IP_B >1000km away (Impossible Travel)
**C)** Alert when any user logs in
**D)** Alert when disk space is low

??? success "Answer"
    **Correct Answer: B) Alert when login from IP_A is followed within 1 hour by login from IP_B >1000km away (Impossible Travel)**

    **Explanation:** Sequence-based correlation detects multi-step patterns where event order and timing matter.

    **Example Logic:**
    ```
    IF (login_from_IP_A at time T1)
    THEN (within 1 hour, login_from_IP_B at time T2)
    WHERE distance(IP_A, IP_B) > 1000 km
    THEN alert "Impossible Travel"
    ```

    **Other Sequence Examples:**
    - Credential dumping → Lateral movement
    - Malware execution → C2 connection → Data exfiltration
    - Privilege escalation → Account creation

    **Contrast with Threshold-based:**
    - Threshold: Count exceeds limit (no sequence requirement)
    - Sequence: Event A must occur before Event B

    **Reference:** [Chapter 3, Section 3.4 - Types of Correlation](../chapters/ch03-data-modeling-normalization.md)

**A)** SPL (Splunk Processing Language)
**B)** KQL (Kusto Query Language)
**C)** SQL (Structured Query Language)
**D)** Python exclusively

??? success "Answer"
    **Correct Answer: C) SQL (Structured Query Language)**

    **Explanation:** AWS Athena uses standard SQL to query data stored in S3.

    **Example:**
    ```sql
    SELECT userIdentity.userName, sourceIPAddress, COUNT(*) as event_count
    FROM cloudtrail_logs
    WHERE eventTime > '2026-02-01'
      AND eventName = 'AssumeRole'
    GROUP BY userIdentity.userName, sourceIPAddress
    HAVING event_count > 50
    ```

    **Data Lake Query Tools:**
    - **AWS Athena:** SQL (Presto-based)
    - **Azure Data Explorer:** KQL
    - **Databricks:** SQL, Spark (Python/Scala)
    - **Google BigQuery:** SQL

    **Trade-off:** SQL is powerful and flexible, but requires more analyst skill than purpose-built SIEM UIs.

    **Reference:** [Chapter 3, Section 3.5 - Querying a Data Lake](../chapters/ch03-data-modeling-normalization.md)

**A)** Failed - recall decreased, rule should be reverted
**B)** Successful - precision greatly improved with acceptable recall trade-off, and alert volume is manageable
**C)** Failed - alert volume decreased too much
**D)** No change - metrics are irrelevant

??? success "Answer"
    **Correct Answer: B) Successful - precision greatly improved with acceptable recall trade-off, and alert volume is manageable**

    **Explanation:** Let's analyze the impact:

    **Before Tuning:**
    - 200 alerts/day × 20% precision = 40 true positives
    - 200 alerts/day × 80% FP rate = 160 false positives/day
    - Analysts waste time on 160 FPs daily
    - 95% recall = catching 95% of threats

    **After Tuning:**
    - 50 alerts/day × 70% precision = 35 true positives
    - 50 alerts/day × 30% FP rate = 15 false positives/day
    - 90% recall = catching 90% of threats

    **Trade-offs:**
    - Lost 5 true positives (40 → 35)
    - Eliminated 145 false positives (160 → 15)
    - Recall slightly decreased (95% → 90%) - acceptable
    - Alert volume now manageable (50 vs 200)

    **Result:** **SUCCESS**. Analysts handle volume better, focus on genuine threats, reduced burnout. The 5% recall loss (missing 5 out of 100 threats) is acceptable given the massive reduction in noise.

    **Reference:** [Chapter 3, Section 3.6 - Metrics for Tuning Example](../chapters/ch03-data-modeling-normalization.md)