IT PATH
My Path

Security Monitoring and SIEM Operations

Run a monitoring capability with useful log sources, correlation rules, triage workflow, and measurable coverage.

Certification
CompTIA CySA+
Recommended study time
6h 35m
Status
Not started

Recommended study time

About 6h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 9 sittings.

  • Read the lesson21 min

    About 2,713 words at a careful technical reading pace.

  • Second pass with notes13 min

    Re-read the harder parts and write your own notes.

  • Recall from memory12 min

    2 written recall questions.

  • Practice decision12 min

    One applied decision with feedback.

  • Teach it back20 min

    Write the topic in your own words.

  • Real-world scenario15 min

    Read the situation and justify your decision in writing.

  • Hands-on practice3h 20m

    Labs, commands and configuration until you can do it unaided.

  • Spaced review1h 40m

    4 short review sessions spread over the following weeks.

Learning objectives

  • Select log sources that provide meaningful detection coverage.
  • Triage an alert from raw event to documented verdict.
  • Measure detection coverage and false positive cost honestly.

Start here

About 8 minutes of reading, in 10 short parts.

A SIEM is the tool a security team uses to watch everything happening across a company's computers, accounts, and cloud services at once, and to raise a hand when something looks wrong. On its own it collects logs; the value comes from what rules you write and how carefully an analyst checks each alert.

Where you meet it: A SOC analyst opens a ticket every time the SIEM fires an alert, from a strange login at 3 a.m. to a server suddenly talking to an unfamiliar country.

The lesson, part by part

Open one part at a time. Each part stands on its own, so you can stop and come back.

Imagine a large office building with hundreds of security cameras, badge readers, and alarm sensors. No single guard can watch every feed at once, so instead all of that footage and every badge swipe is sent to one control room. A SIEM is that control room for computers: it pulls in records from laptops, servers, firewalls, and cloud apps, and puts them on one screen.

The control room only becomes useful once someone writes rules like 'tell me if the same badge is used at two doors five minutes apart in different buildings' — because a human could never notice that by watching separate cameras. A SIEM does the same thing with digital events: it looks for combinations across many systems that a person staring at one log file would never catch.

Key ideas

If you remember nothing else from this topic, remember these.

  • A SIEM is only as good as the log sources feeding it, so coverage planning matters more than the platform brand.
  • Correlation rules turn isolated events into a single meaningful alert by combining signals across multiple systems.
  • Analysts must validate every alert against raw events rather than trusting a summary string, because parsers and enrichment can silently be wrong.
  • Mean time to detect and mean time to triage are the operational metrics that matter, not raw alert volume.
  • Retention policy directly limits how far back an investigation can reach, so it must be set before an incident, not during one.
  • Alert fatigue from poorly scoped rules is the most common reason real intrusions get missed inside a SIEM.
  • Use case management should record the evidence behind a verdict so closures are auditable and repeatable.

Triaging an impossible travel alert

A worked example, step by step.

A Tier 1 SOC analyst receives a Splunk correlation alert flagging two Azure AD sign-ins for the same account within 27 minutes from IP addresses in different countries.

  1. 01Pull raw eventsQuery index=identity sourcetype=azuread-signin for the account and confirm two SigninLogs entries: 03:02 UTC from a UK IP with mfa_result=satisfied, and 03:29 UTC from a Nigeria IP with mfa_result=satisfied.
  2. 02Check enrichmentLook up both IPs against the corporate VPN egress list and threat intelligence feed; the Nigeria IP has no VPN association and appears on a recent credential-stuffing IOC list.
  3. 03Map to ATT&CKClassify the activity as Valid Accounts (T1078) under Initial Access, since MFA was satisfied, indicating the token or session, not just the password, was compromised.
  4. 04Check for follow-on activitySearch for OAuth consent grants or inbox rule creation (New-InboxRule) in the 30 minutes following the second sign-in; find a new forwarding rule to an external address.
  5. 05EscalateOpen a Sev-2 incident case with a documented timeline: 03:02 legitimate, 03:29 anomalous, 03:41 inbox rule created, and notify the account owner's manager and IR lead.
  6. 06Containment actionForce a password reset, revoke all active refresh tokens, and remove the malicious inbox rule.
  7. 07Root cause noteDetermine the credential was likely captured via a prior phishing kit that also stole the MFA session cookie, not the password alone.
  8. 08Tuning follow-upFile a detection engineering ticket to also alert on new inbox forwarding rules created within one hour of an anomalous sign-in, closing the coverage gap.

Outcome: The account is contained within 40 minutes of alert generation, the exfiltration channel is removed before any email was forwarded, and a new correlation rule closes a related detection gap for future incidents.

SIEM operations reference

Worth keeping at hand while you work.

Windows Event ID 4624
Successful logon
Windows Event ID 4625
Failed logon attempt
Windows Event ID 4720
New user account created
Windows Event ID 4688
New process creation
Windows Event ID 1102
Security audit log cleared
MTTD
Mean time to detect, from compromise to alert
MTTR
Mean time to respond, from alert to containment
Syslog
Standard protocol for forwarding logs from network devices
CEF
Common Event Format, a normalised log schema
UEBA
User and entity behaviour analytics for anomaly baselining
Case management
Workspace recording evidence, verdict, and escalation for each alert
Retention window
Length of time raw events remain searchable

Common misunderstandings

What most beginners get wrong here.

  • More alerts mean better security coverage.

    High alert volume without tuning usually indicates poor scoping and causes analysts to rubber-stamp closures, reducing actual detection quality.

  • A closed alert marked false positive needs no further documentation.

    Every closure should record the specific evidence reviewed, since undocumented closures repeat the same investigative mistake later.

  • If the SIEM dashboard is quiet, the environment is safe.

    A silent dashboard can mean a collector or forwarder has failed; log source health must be checked independently of alert volume.

  • The SIEM's summary text is always accurate.

    Summaries can be stale or mask a parsing error; analysts must pull the underlying raw events before making a verdict.

  • Buying a better SIEM product fixes weak detection.

    Detection quality depends on log source coverage and correlation logic, not the platform brand.

Exam traps

How the question writers try to catch you out.

  • CySA+ questions often describe a scenario with a plausible business explanation for an anomaly and expect you to identify the specific corroborating evidence, not just say true positive or false positive.
  • Expect a question distinguishing a SIEM from a SOAR: the SIEM detects and correlates, while a SOAR automates the response playbook after detection.
  • Watch for scenarios that test whether you know log retention limits an investigation's lookback window, framed as why an analyst cannot answer a question about activity from months ago.
  • Exam scenarios frequently reward choosing to check collector health first when a source that should be noisy goes silent, rather than assuming the environment improved.
  • Impossible travel and MFA fatigue attacks are commonly tested together; know that satisfied MFA does not rule out compromise if session tokens were stolen.

Check yourself

Answer in your head first, then reveal. This is not scored.

  • What is the difference between a log source and a correlation rule?

  • Why should an analyst pull raw events instead of trusting the alert summary?

  • What ATT&CK technique applies to a compromised account with satisfied MFA?

  • Why is short log retention a risk?

  • What metric better reflects SOC effectiveness than alert count?

  • Why can a quiet SIEM dashboard be dangerous?

Quick reference

A condensed summary of the lesson above, for revision.

What It Is

Security information and event management platforms centralise logs from endpoints, identity providers, network devices, and cloud services, normalise them, and apply correlation rules to raise alerts. Analysts triage alerts by validating the signal, enriching it with context, determining true or false positive, and escalating confirmed incidents with a documented timeline.

Why It Matters

Detection is where most organisations are weakest. Knowing which sources actually detect attacker behaviour, and being able to justify tuning decisions, is the core skill of a security analyst role.

How It Works

  • Collectors ship events, which are parsed and normalised into a common schema.
  • Rules and analytics evaluate events and generate alerts with severity and context.
  • Analysts triage, enrich, and either close with a verdict or escalate to incident response.

Where You See It

  • Security operations centres, managed detection services, cloud security monitoring, and compliance reporting.

Key Terms

Log source
A system providing events, such as EDR or identity sign-in logs.
Correlation rule
Logic raising an alert when conditions across events match.
Enrichment
Adding context such as asset owner, geolocation, or threat intel.
True positive
An alert that correctly identified malicious or unwanted activity.
Detection coverage
Which attacker techniques the current rules can observe.

Examples

  • Identity sign-in logs detect impossible-travel and MFA-fatigue patterns that endpoint logs cannot.
  • Process creation logging with command lines is essential to detect living-off-the-land techniques.

Common Problems

  • Noisy rules
  • Missing critical log sources
  • Broken parsing after a vendor change
  • No asset context
  • Unretained logs

How It Fails

  • A silently broken collector removes visibility from an entire estate without alerting.
  • Unbounded false positives cause analysts to auto-close a class of alerts, including a real one.
  • Short retention prevents investigation of activity that began months earlier.

How to Troubleshoot

  1. Verify event flow and parsing before concluding no activity occurred.
  2. Compare the alert against raw events rather than trusting the summary.
  3. Check asset and identity context before judging severity.

Practical Knowledge

  • Monitor the monitoring: alert when a log source stops reporting.
  • Record tuning decisions with justification so coverage changes are visible.

Exam Coverage

  • Log sources and data collection
  • Correlation, alerting, and triage
  • Detection coverage and tuning

Interview Questions

  • Which log sources would you prioritise with a limited budget?
  • How do you decide whether to tune out a noisy alert?

Watch and read

Verified official and reputable sources for this topic. Links open in a new tab.

Video training

  • Professor Messer video channel — general CompTIA training (no dedicated CompTIA CySA+ course)

    Professor Messer

    Video
    Free
    Watch

Lesson notes and bookmark

Notes and bookmarks for this lesson, saved with everything else you have marked.

No notes on this item yet.

Learning progress

0% across six evidence areas. Reading alone does not change progress.

Understanding0%
Recall0%
Application0%
Practical ability0%
Troubleshooting0%
Retention0%

Prerequisites

Next steps

  1. 01List the top five log sources in your environment and what each can detect.
  2. 02Write a triage note for one alert including evidence and verdict.