SOC Analyst Hands-on Module 05: Log Management and Analysis

In today’s zettabyte era, logs are the lifeblood of cybersecurity. Every firewall, IDS/IPS, web server, and endpoint spews gigabytes of log data about who accessed what, when, and how. According to Gartner, “nearly every element” of modern IT produces log telemetry, so data volumes are exploding; by year-end, we will generate over 180 zettabytes worldwide. The log management market reflects this explosion: it is projected to grow from $3.76 billion in 2025 to $7.88 billion by 2030 (≈16% CAGR). In short, organizations are treating logs as a strategic asset. To harness this tsunami of data, Module  05 of SOC Analyst Hands-on training teaches SOC professionals how to collect, analyze, and hunt with logs. Buckle up, we are about to turn raw logs into actionable threat intelligence!

Understanding Log Sources

Logs come from many places. Each source has its own format and stories to tell, so a savvy SOC Analyst must understand them all. Let’s break down the big four.

• Firewalls: As the network perimeter’s gatekeeper, a firewall logs every allowed or blocked connection. Those “accept” and “deny” entries are invaluable. Secureworks notes that firewall logs were often the first clues of outbreaks before antivirus even had signatures. In practice, we scan firewall logs for patterns of denied connections, port scans, host sweeps, or huge spikes in traffic, because any intrusion from outside must leave a footprint on the firewall. In fact, firewall logs are an intrusion detection tool: they show you exactly which packets were stopped or passed, giving clues about scanning and attack attempts.

• IDS/IPS (Intrusion Detection/Prevention Systems): Unlike firewalls, IDS systems passively monitor traffic, while IPS systems can actively block threats. They generate logs rich with detail about any suspicious patterns they see (signatures, anomalies, etc.). These logs are forensic gold: they record the nature of the threat, source/destination IPs, and even payload snippets. IDS logs and stores data related to detected threats, which is valuable for forensic analysis. In practice, a detected attack by an IDS is usually forwarded into your SIEM or monitoring console so Analysts can review the full context. For example, an IDS might trigger on a known exploit signature and log that event; SOC Analysts can then trace that alert through the firewall and system logs. Many organizations forward IDS/IPS alerts into Splunk or another SIEM, centralizing all these warnings.

• Web Servers: Every HTTP request is logged by your web server (Apache, Nginx, IIS, etc.). These access logs are plain text records of who requested what, when, and from where. For example, a typical Apache access log line includes the client IP, timestamp, requested URL/path, HTTP status code, user agent, and more. This data is a goldmine: it tells you exactly which pages were hit, which files served, and which queries ran. Web logs help optimize performance (peak user times, pageviews) but also catch attacks. For example, repeated 404 Not Found errors on /admin pages, or a flurry of odd query strings (SQL keywords, strange encodings) can flag a brute-force or injection attempt. In fact, security experts sometimes describe an Apache log analysis as a form of IDS: by parsing those logs, you can detect intrusion or discovery attempts from outsiders.

• Endpoints (Workstations and Servers): Do not forget the machines themselves. Every endpoint, from user laptops to critical servers, generates logs via its operating system and security agents. Windows machines create Event Logs (Application, System, Security, etc.) that record logins, program errors, policy changes, and more. Linux hosts log syslog messages and authentication events. Additionally, modern Endpoint Detection and Response (EDR) tools continuously record detailed telemetry: process launches, file modifications, network connections, and user behavior. This endpoint data is crucial because many breaches start there. Endpoint logs are critical for modern security monitoring. Attackers who gain access to an endpoint device can use it to penetrate your network. Therefore, it is essential to collect data from endpoint logs and identify malicious or unauthorized activity.

Centralized Logging with Splunk

Collecting all these logs individually is a recipe for blindness. That’s why we use a centralized log management system. Splunk is one of the most popular SIEMs in SOCs, and for good reason. Splunk (and tools like it) ingest logs from every source, firewalls, IDS, web servers, and endpoints into a single searchable repository. This “single pane of glass” approach is a game-changer. Means, “Centralized logging consolidates logs from multiple sources into a single system”, greatly simplifying monitoring and analysis across complex environments.

Once logs are centralized, Splunk’s power becomes evident. You can write SPL queries to ask any question about your data. For example, you might search: index=firewall_logs action=deny | stats count by src_ip to find the top blocked IP addresses. Or use Splunk’s dashboards and alerts: “alert me if failed login count >100 in 5 minutes.” Splunk provides rich analytics and visualizations, charts, graphs, and dashboards that help us spot trends. According to Splunk, its advanced search, visualization, and alerting tools enable organizations to scale logging practices, meet compliance, and gain actionable insights.

A SOC Analyst might run searches like sourcetype=apache_access status=404 | top client_ip to find which IPs are triggering 404 errors on the web server, or index=edr device=”*workstation*” | timechart count by event_type to see spikes in endpoint alerts. Having all logs in one place also makes correlation trivial: you can join firewall, IDS, and host logs to trace the path of an attack. In summary, centralized logging is the glue that makes log analysis possible.

Identifying Anomalies in Logs

With logs flowing in, the next skill is spotting the needles in the haystack. Not every event is malicious, so we look for anomalies, the unusual or outlying patterns. Anomaly detection in security means flagging events that deviate from your “normal” baseline. Anomaly detection is like identifying patterns that “deviate from an established norm. In other words, we teach our SIEM what normal looks like, then hunt for anything that strays. For example, suppose the web server normally sees 10–20 hits per minute on /index.html. If you suddenly see 1000 hits in one minute from an unknown IP, that’s an anomaly. Or imagine your firewall usually logs a dozen external connection attempts per hour, then overnight it logs 10,000, likely an automated scan.

Lab: Analyzing Apache Server Logs for Intrusion Attempts

Let’s walk through a hands-on example: hunting for threats in Apache web server logs. Imagine you are the SOC Analyst on duty and you suspect someone is poking at your web servers. Here’s how you might proceed:

1. Access the Logs: SSH into the Apache server (or wherever you gather logs) and open the access log (/var/log/apache2/access.log) and error log. These files list every HTTP request. For convenience, you might also ingest them into Splunk or another SIEM ahead of time.

2. Filter by Errors: Start by scanning for error responses, which often hint at scanning or attacks. For example, run: grep ” 404 ” access.log | sort | uniq -c

This shows which IPs generated lots of 404 “Not Found” errors. A burst of 404s from one IP often means an attacker is probing directories that don’t exist (a common reconnaissance technique). Similarly, check for 500 errors (server errors), which might indicate someone triggered a crash.

3. Look for Login and Admin Attempts: Search the logs for attempts to access login or admin pages. For example: grep -E “(wp-login|admin|login|phpmyadmin)” access.log

Any hits here suggest brute-force attempts on known entry points. An IP repeatedly requesting /admin or /wp-login.php is suspicious.

4. Check for Injection Patterns: Hackers often try SQL injection or command injection. Use regex to spot these. For example: grep -E “(union|select|drop|–|/etc/passwd)” access.log

Look for keywords like UNION SELECT, DROP, or directory traversal (../). If you find them in query strings (e.g. GET /page.php?id=1%20UNION%20SELECT…), that’s a red flag.

5. Use SIEM Queries: If your logs are in Splunk, try a search like: index=apache_logs | stats count by client_ip, status | sort – count

This quickly shows which IPs are most active and what status codes they’re getting. A sudden high count of 401 or 404 responses to one IP stands out instantly.

SOC Analyst Hands-on Training with InfosecTrain

Log management is not glamorous, but it is critical. By mastering log management and analysis, you gain an eagle’s-eye view of your entire infrastructure. You have seen how firewalls and IDS/IPS provide perimeter insights, web servers capture every HTTP interaction, and endpoints reveal the machine’s perspective.

When you centralize all of this in Splunk or any modern SIEM, that overwhelming avalanche of logs transforms into actionable security intelligence. With smart alerting, threat correlation, and anomaly detection, you start catching the attacks that traditional defenses miss.

This is exactly the kind of real-world capability you build in InfosecTrain’s SOC Analyst Hands-On Training. From log parsing and threat hunting to SIEM dashboards, alert tuning, and incident investigation workflows, the program ensures you not only understand log management but can operate like a true SOC professional from Day 1.

TRAINING CALENDAR of Upcoming Batches For SOC Analyst Training Course

Start Date	End Date	Start - End Time	Batch Type	Training Mode	Batch Status
02-May-2026	14-Jun-2026	09:00 - 13:00 IST	Weekend	Online	[ Open ]	Enroll Now
11-Jul-2026	05-Sep-2026	19:00 - 23:00 IST	Weekend	Online	[ Open ]	Enroll Now
05-Sep-2026	25-Oct-2026	09:00 - 13:00 IST	Weekend	Online	[ Open ]	Enroll Now