Security Monitoring and the SOC

Why monitor at all

Firewalls, patches, multi-factor authentication and training stop most attacks, but not all of them. A user approves a fake login prompt, a new vulnerability is exploited before a patch exists, a supplier's account is misused. Defense in depth therefore has a second half: if an attacker gets past the preventive controls, you want to notice quickly. Monitoring is a detective control; it does not stop anything by itself, but it turns a silent compromise into an incident that people can respond to.

Speed matters because attacks take time. Between the first foothold and the real damage (data copied out, backups deleted, ransomware started) there are usually several steps, each of which leaves traces. Every step that is detected is a chance to stop the attack before it reaches its goal. The attack models on the threat actors page describe those steps.

What to log

Logging everything is expensive and buries the useful events; logging too little leaves blind spots. Most organizations start with the sources that answer the basic questions of an investigation: who did what, from where, and when.

Two examples of what this looks like in practice: on Windows, the Security event log records a failed logon as event ID 4625 and a successful one as 4624; network devices send their messages over syslog. Cloud providers keep audit logs of control-plane activity, and the centralized logging section of the Cloud topic explains how logs are shipped to one place. On a single Linux server, the Linux security page shows where to look.

Time synchronization and log integrity

An investigation rebuilds a timeline from many sources. If the firewall clock is four minutes ahead of the domain controller, events appear in the wrong order and correlation rules miss them. Every system should therefore synchronize its clock with the Network Time Protocol (NTP) and log in Coordinated Universal Time (UTC), or at least with an explicit time zone.

Attackers who gain administrator rights often try to delete or change logs to hide their tracks. Logs are therefore sent off the system as they are written to a central store that ordinary administrators cannot change, with access to that store itself logged. Write-once storage, hashes over archived log files and a defined retention period make logs trustworthy enough to serve as evidence in an incident response.

SIEM: from raw logs to alerts

A SIEM (security information and event management) system collects security-relevant logs from across the organization, stores them centrally and searches them for signs of attack. The name combines two older product categories: security information management (long-term storage and reporting) and security event management (real-time analysis). The work happens in four steps:

1. Collection. Agents on endpoints and servers, syslog receivers and cloud connectors bring the logs in. Each source has its own format.
2. Normalization. Every event is parsed into common fields: time, source address, user, host, action, result. Only then can a rule compare a VPN login with a Windows logon.
3. Correlation. Rules combine events from one or more sources into a detection, such as "many failed logins followed by a success".
4. Alerting. A match creates an alert with a severity, which goes into a queue for an analyst, or straight into an automated response.

Correlation rules

A correlation rule is a detection that looks for a pattern across several events rather than in one event alone. One failed login means nothing; twenty failures for twenty different accounts from one address within a minute suggests password spraying. Five failures followed by a success from the same address suggests that a guess worked. Rules usually have three parts: which events to match, a grouping key (here the source address) and a time window.

The program below implements that last rule on a few fake VPN log lines (documentation addresses from RFC 5737, invented names). It first normalizes each line into named fields, then keeps, per source address, the times of recent failures:

from collections import defaultdict, deque
from datetime import datetime, timedelta

LOG_LINES = [
    "2026-10-01T08:58:12Z vpn01 login_failure user=e.bakker src=203.0.113.50",
    "2026-10-01T08:58:40Z vpn01 login_success user=e.bakker src=203.0.113.50",
    "2026-10-01T09:00:03Z vpn01 login_failure user=admin src=198.51.100.23",
    "2026-10-01T09:00:09Z vpn01 login_failure user=admin src=198.51.100.23",
    "2026-10-01T09:00:15Z vpn01 login_failure user=s.jansen src=198.51.100.23",
    "2026-10-01T09:00:21Z vpn01 login_failure user=s.jansen src=198.51.100.23",
    "2026-10-01T09:00:30Z vpn01 login_failure user=s.jansen src=198.51.100.23",
    "2026-10-01T09:00:37Z vpn01 login_success user=s.jansen src=198.51.100.23",
    "2026-10-01T10:15:00Z vpn01 login_failure user=m.visser src=192.0.2.14",
    "2026-10-01T10:16:00Z vpn01 login_failure user=m.visser src=192.0.2.14",
    "2026-10-01T10:17:00Z vpn01 login_failure user=m.visser src=192.0.2.14",
    "2026-10-01T10:18:00Z vpn01 login_failure user=m.visser src=192.0.2.14",
    "2026-10-01T10:19:00Z vpn01 login_failure user=m.visser src=192.0.2.14",
    "2026-10-01T10:45:00Z vpn01 login_success user=m.visser src=192.0.2.14",
]

THRESHOLD = 5                   # failures needed before a success is suspicious
WINDOW = timedelta(minutes=10)  # how far back the rule looks


def normalize(line):
    """Turn one raw log line into a dictionary with fixed field names."""
    stamp, host, action, user, source = line.split()
    return {
        "time": datetime.strptime(stamp, "%Y-%m-%dT%H:%M:%SZ"),
        "host": host,
        "action": action,
        "user": user.removeprefix("user="),
        "source": source.removeprefix("src="),
    }


failures = defaultdict(deque)   # source address -> times of recent failures
alerts = 0
for line in LOG_LINES:
    event = normalize(line)
    recent = failures[event["source"]]
    while recent and event["time"] - recent[0] > WINDOW:
        recent.popleft()        # forget failures older than the window
    if event["action"] == "login_failure":
        recent.append(event["time"])
    elif event["action"] == "login_success" and len(recent) >= THRESHOLD:
        alerts += 1
        print(f"ALERT {event['time']:%H:%M:%S} source={event['source']} "
              f"user={event['user']}: success after {len(recent)} failures "
              f"in {WINDOW.seconds // 60} min")
        recent.clear()

print(f"{len(LOG_LINES)} events, {alerts} alert(s)")

ALERT 09:00:37 source=198.51.100.23 user=s.jansen: success after 5 failures in 10 min
14 events, 1 alert(s)

Three things are worth noticing. The single typo by e.bakker causes no alert. The address 198.51.100.23 tried two accounts before one worked, which is exactly the pattern the rule exists for. And m.visser also failed five times, but the success came 26 minutes later, outside the window: probably a user who went to fetch their password from the service desk. Whether that last case should alert is a tuning decision, which is the subject of the next section.

False positives, false negatives and tuning

Every detection can be wrong in two ways. A false positive is an alert for activity that turns out to be harmless, such as a backup job that looks like data theft. A false negative is an attack that happened without causing an alert. The two pull against each other: a wider window or a lower threshold catches more attacks and also more innocent users.

False negatives are dangerous because nobody sees them. False positives are dangerous in a quieter way: a team that receives hundreds of meaningless alerts a day starts to skim, and the one real alert drowns. This is called alert fatigue. Tuning is the ongoing work of reducing noise without creating blind spots: excluding known-good activity precisely (this one backup server, not "all servers"), adding context such as asset criticality, raising the severity of rules that have caught real attacks, and retiring rules that never do. Every exclusion is itself a possible blind spot, so exclusions are documented and reviewed.

The security operations center

A security operations center (SOC) is the team, processes and tools that monitor an organization's environment for security events and respond to them, often around the clock. The SIEM is its main tool; the SOC is the people who decide what an alert means.

Analyst tiers

Many SOCs organize their analysts in tiers. The names differ between organizations, but the division of work is similar:

Attacks do not keep office hours, so a SOC either works in shifts or combines office-hours staffing with an on-call rotation for serious alerts at night and at weekends. A clear escalation path (who is called for what, and who may decide to isolate a production server at 3 a.m.) belongs in the incident response preparation.

Measuring a SOC

Two metrics appear in almost every SOC report. Mean time to detect (MTTD) is the average time between the start of malicious activity and its detection. Mean time to respond (MTTR) is the average time from detection until the threat is contained (some organizations measure until full recovery, so check the definition used). Both should go down over time. Other useful numbers are the alert volume per analyst, the share of alerts that turn out to be false positives, and the coverage of known attack techniques by detection rules. A metric that rewards closing alerts quickly can also reward closing them carelessly, so numbers are read together with case reviews.

SOAR: automating the routine

SOAR (security orchestration, automation and response) tools connect the SOC's systems through their interfaces and run predefined workflows when an alert arrives. A typical workflow for a reported phishing email: extract the links and attachments, look up their reputation, search all mailboxes for the same message, and present the analyst with one summary and a button to remove the message everywhere.

Automation is best at the repetitive enrichment steps that take an analyst ten minutes per alert. Automatic actions deserve more care: blocking an address or disabling an account automatically is fast, but a false positive then blocks a customer or locks out the chief financial officer during a payment run. Many teams automate collection and enrichment fully and keep a human approval step for disruptive actions.

Threat intelligence and indicators of compromise

Threat intelligence is analyzed information about threat actors, their goals and their methods, used to make better defensive decisions. It comes in levels: strategic (which kinds of attackers target our sector, for management), operational (an active campaign against water utilities this month) and tactical (concrete technical details). Sources include commercial feeds, government organizations such as the National Cyber Security Centre (NCSC-NL) in the Netherlands, sector-based information sharing groups, and open sources.

Indicators of compromise

An indicator of compromise (IOC) is a technical artifact that suggests a system has been compromised: an Internet Protocol (IP) address or domain of attacker infrastructure, the hash of a malicious file, a specific file name or registry key. A SOC loads IOCs into the SIEM and EDR so that any match raises an alert, and searches old logs for matches to find earlier infections. An IOC list on this page, with deliberately fake documentation values, could look like this:

type     value                                                             context
ipv4     203.0.113.66                                                      command-and-control server
domain   update-check.example.net                                          phishing landing page
sha256   0000000000000000000000000000000000000000000000000000000000000000  loader attached to invoice email

IOCs are useful but short-lived: an attacker changes an address or recompiles a file in minutes. Detections based on behavior (a word processor starting a command shell, a login followed by mass file renames) last much longer, because changing behavior costs the attacker more. Shared addresses add a second problem: blocking a cloud provider's address because it once hosted something malicious can block legitimate services too.

Threat hunting

Alerts only fire for what someone thought of in advance. Threat hunting is the proactive search through an environment's data for attacker activity that existing detections did not catch. Hunting starts from a hypothesis, often based on threat intelligence or on a technique from the MITRE ATT&CK knowledge base: "if an attacker had stolen VPN credentials, we would see logins for one account from two countries within an hour". The hunter then searches the data for that pattern.

A hunt has three possible outcomes, and all three are useful: it finds an attack (start incident response), it finds nothing but shows the data to look for it is missing (improve logging), or it finds nothing and the pattern can be turned into a new correlation rule so the next occurrence is detected automatically. That last step is how hunting feeds detection engineering.

Managed SOC and MDR for smaller organizations

A SOC that works around the clock needs at least several analysts per shift position, plus tooling and engineering: out of reach for most small and medium-sized organizations. They often buy the service instead. A managed SOC or managed security service provider (MSSP) monitors the customer's logs remotely; managed detection and response (MDR) adds hands-on response, such as isolating an infected laptop through the EDR agent at night.

Outsourcing the monitoring does not outsource the responsibility. The organization still decides which systems are in scope, keeps its asset list current, provides contact persons who can be reached, and must know what the provider will do on its own authority and what needs permission. Those agreements are made before the first incident, not during it.