The problem SIEMs are designed to solve

Host machines and endpoints record logs for many activities: user logins, processes running, commands executed, configuration changes, and network connections. These logs contain valuable evidence, but at scale they become hard to manage. A SOC analyst can’t realistically review logs manually across many machines, especially when each system logs data differently.

A SIEM (Security Information and Event Management) helps by providing:

• A centralized platform for collecting logs from multiple sources
• Normalization to convert different log formats into a consistent structure
• Dashboards and reporting to visualize and summarize events
• Real-time alerting to notify analysts when suspicious patterns appear

Host-centric vs network-centric logs

One useful way to understand logs is to group them into two broad categories: host-centric and network-centric. You need both to form a clear picture during investigations.

Host-centric logs

Host-centric logs describe what happens on a system. Examples include:

• User logins and logouts
• PowerShell command execution
• Registry modifications
• Process creation and termination
• Service and scheduled task changes

Network-centric logs

Network-centric logs describe how systems communicate. Examples include:

• VPN connections
• SSH logins
• Web traffic (HTTP/HTTPS connections)
• File transfers (FTP/SFTP)
• Firewall and IDS/IPS events

Where logs are stored on different systems

I also explored where logs live on different host machines, which is useful when you’re troubleshooting, doing incident response, or collecting evidence.

Windows

Windows logs are available through Event Viewer. This is where you’ll find categories like Security, System, and Application logs. These logs are especially valuable for investigating authentication activity, privilege use, and suspicious processes.

Linux (and Linux-based web servers)

Linux commonly stores logs under /var/log. For example, web server logs may appear in folders like:

• /var/log/httpd (commonly Apache on some distributions)
• /var/log/apache2 (Apache on other distributions)
• /var/log/nginx (Nginx)

Different services generate different logs, but the key idea is that Linux centralizes many logs inside /var/log and service-specific directories.

How SIEM alerts are created

SIEMs generate alerts using rules. Rules define conditions that represent suspicious behavior. When an event matches a rule (or when a rule condition is satisfied over time), an alert is triggered for analysts to investigate.

The interesting part is that alerting is not just about single events. Often it’s about patterns, such as repeated failures, unusual sequences of actions, or correlations across systems.

How SIEMs collect logs: agents, forwarding, and offline upload

Another key point I learned is that SIEMs don’t magically have logs — they need a way to ingest them. Like EDR solutions, SIEMs often use agents or log forwarding to retrieve logs from endpoints. They can also support uploading offline logs for normalization and analysis, which can be useful during investigations or when reviewing historical data.

Final takeaway

What stood out to me most is that SIEMs help analysts handle scale. Instead of manually reviewing logs across many systems, a SIEM centralizes data, normalizes it, and turns it into actionable alerts. And because logs come from both hosts and networks, understanding both perspectives is critical for detecting real threats.