Detection and Analysis: Log Review and Alert Triage

Detection and Analysis: Log Review and Alert Triage

Why Log Review Matters

When a security incident occurs, logs are your primary source of truth. Firewalls, endpoints, and authentication systems generate continuous records of activity. Without the ability to read those records systematically, an analyst cannot separate routine noise from a genuine attack in progress. This lesson teaches you to import logs into a SIEM, write targeted queries, triage alerts, and assign severity levels — core skills tested on CompTIA Security+, CySA+, and ISC2 CC.

Types of Logs You Will Encounter

Firewall logs record allowed and denied connections, source and destination IP addresses, ports, and protocols. Look for outbound connections to IP addresses that appear on your IOC reference list, unusual port usage (for example, DNS over non-standard ports), and high-volume outbound transfers that could indicate data exfiltration.

Windows Event logs use numeric Event IDs to categorize activity. Event ID 4625 indicates a failed logon. Event ID 4648 indicates a logon attempt using explicit credentials. A cluster of 4625 events from a single source in a short window is a classic indicator of a brute-force attempt. Event ID 4663 records object access, which is relevant when investigating file theft.

Syslog is the standard logging format used by Linux systems, network devices, and many applications. Entries include a priority field (facility and severity), a timestamp, a hostname, and a message. Pay attention to authentication failures (`auth` facility), privilege escalation attempts (`sudo` usage), and unexpected cron jobs.

Using a SIEM for Log Analysis

A Security Information and Event Management (SIEM) platform ingests logs from multiple sources, normalizes them into a common format, and lets you search, correlate, and visualize events. In this lab you will use either Splunk Free or the Elastic Stack (Elasticsearch, Logstash, Kibana — often called ELK).

After importing your log sets, basic query patterns to run include:

• Failed logins: Search for Event ID 4625 (Windows) or `Failed password` strings (Linux/syslog). Filter for sources generating more than a defined threshold of failures in a short time window.
• Connections to known-bad IPs: Cross-reference firewall destination fields against your IOC list. In Splunk this is done with a lookup table; in Kibana you can use a terms filter or an enrichment policy.
• Large data transfers: Look for sessions where the bytes-out value significantly exceeds bytes-in, especially over protocols like FTP, HTTPS, or DNS where large uploads would be unusual.

Write your queries precisely. A query that is too broad returns thousands of irrelevant events; one that is too narrow misses real threats. Document every query you run in your triage worksheet so your work is reproducible.

Alert Triage: True Positive, False Positive, Benign Anomaly

Alerts generated by a SIEM or IDS/IPS fall into three categories you must be able to distinguish:

• True positive (TP): The alert fired and the activity is genuinely malicious or policy-violating. Action is required.
• False positive (FP): The alert fired but the activity is legitimate. The rule or threshold needs tuning. No incident action is required, but the alert should be noted so the rule can be improved.
• Benign anomaly: The activity is unusual and triggered an alert, but investigation shows it is not malicious — for example, a scheduled backup running at an unexpected time due to a time-zone change. Document it and close.

For every alert, ask: Does the activity match known attack patterns? Is there a business or technical explanation? Is the source or destination on an IOC list or a known-good asset list? Record your reasoning — written justification is required on your worksheet and is part of the passing standard.

Severity Classification

Not every confirmed incident demands the same urgency. Most organizations use a four-level classification:

| Level | Criteria |

|---|---|

| Critical | Active breach with data exfiltration underway, ransomware executing, or critical infrastructure affected. Immediate escalation. |

| High | Confirmed compromise of a system, successful credential theft, or lateral movement detected. Respond within hours. |

| Medium | Suspicious activity with no confirmed compromise; policy violation with moderate risk. Investigate within one business day. |

| Low | Informational or minor policy violations; isolated failed login attempts with no follow-on activity. Address during normal operations. |

Apply this matrix consistently. In your oral check, you must explain which criteria drove your rating — not just state the level.

Safety and Professional Practice

Log data often contains personal information: usernames, IP addresses linked to individuals, and browsing activity. Handle all lab data according to your program's acceptable-use policy. Do not copy log files outside the lab environment. In a real workplace, log access is governed by policy and sometimes by law (for example, HIPAA or state privacy statutes). Always work within your authorized scope; accessing systems or logs beyond your assignment is unauthorized access regardless of intent.

When working in lab VM environments, confirm you are connected to the isolated lab network before running queries or importing data — never run lab exercises on a production network segment.

Putting It Together

Effective log review requires a repeatable process: collect, normalize, query, triage, classify, and document. Speed and accuracy both matter. In this lab you triage 15 alerts; in a production SOC an analyst may triage dozens per shift. Building good habits now — structured queries, written justification, consistent severity ratings — prepares you directly for a Tier 1 SOC analyst role and for the detection and analysis questions on Security+ and CySA+ exams.