SIEM: searching, correlating and not drowning

Objective 1.3 · Security Operations · 34% of the exam

Why this matters

The SIEM is where an analyst spends most of their day. Objective 1.3 is about using tools to determine malicious activity, and the SIEM is the tool that ties every other source together — it is the only place the network evidence from lesson 6 and the host evidence from lesson 7 sit side by side.

The exam does not test a specific vendor's query language, and neither does this lesson. It tests whether you understand what a SIEM does, what a correlation rule costs, and why tuning is a first-class activity rather than an admission of failure.

The lesson

Index, parse, search: the shape of every SIEM

Whatever the product, the pipeline is the same four stages.

Collect. Agents, forwarders, syslog receivers and API pollers bring data in. This is where coverage gaps live, and they are invisible from further down the pipeline.

Parse and normalise. Raw lines become structured fields, mapped to a common schema, as covered in the logging lesson. A broken parser here empties fields further down without any error.

Index and store. Data is written so it can be searched quickly, usually tiered into hot, warm and cold storage as it ages.

Search and correlate. Analysts query it; rules query it continuously and raise alerts.

Two properties of this shape drive everything else:

  • Ingest volume is the cost driver, typically licensed by gigabytes per day or by events per second. Every "collect everything" instinct meets a budget, which is why the value-per-gigabyte ranking from the logging lesson matters commercially as well as analytically.
  • Search performance falls off with time range. A query over 24 hours is cheap; the same query over a year may be impossible. This shapes how you investigate: narrow first, widen deliberately.

Writing a query that answers one question

The single biggest improvement most analysts can make is to stop writing queries that return "everything about this host" and start writing queries that answer one question.

A disciplined query has four parts, in this order:

  1. Time range. Always. The most common cause of a slow search is an unbounded one.
  2. The narrowest filter available, applied first — a specific index, source type, host or account. Filtering early is what makes the rest fast.
  3. The condition you actually care about.
  4. A shaping step — aggregate, count, sort, or deduplicate — so the result is readable rather than ten thousand raw lines.

A worked example of the thinking, vendor-neutral:

Question: did any internal host contact this domain in the last 30 days? Bad: search the whole estate for the domain string, unbounded. Better: DNS and proxy sources only, last 30 days, domain equals the value, then group by source host and count. One screen of output, and it answers the question asked.

Three habits that pay off repeatedly:

  • Pivot on the strongest identifier. Hashes and full domains beat IP addresses, which change; IP addresses beat host names, which are ambiguous.
  • Count distinct things. "How many distinct destinations did this host talk to?" often reveals more than listing them.
  • Search for absence too. Which hosts did not report this event? That is how coverage gaps surface.

Save the queries that work. An investigation you cannot repeat next month is an investigation you will redo from scratch.

Correlation rules and the cost of a bad one

A correlation rule runs continuously and raises an alert when its condition is met. Typical forms:

  • Threshold: more than N failures in M minutes.
  • Sequence: event A followed by event B within a window — a failed burst then a success, for instance.
  • Cross-source: an IDS alert for a host that also shows a suspicious process launch.
  • Anomaly: deviation from a learned baseline.
  • Enrichment-driven: any connection to an address on a current intelligence list.

Every rule carries three costs, and only the first is obvious:

  1. Compute, continuously, forever.
  2. Analyst attention, per firing. A rule generating 40 alerts a day consumes an analyst.
  3. Credibility. This is the expensive one. A rule with a poor true-positive rate teaches the team that its alerts are noise, and that lesson generalises — analysts start closing everything quickly, including the real one.

So a rule should be judged before deployment by asking: what will fire this besides an attacker, how often, and what exactly should the analyst do when it fires? A rule with no answer to the third question should not exist, which is the argument for a documented response path — the playbook idea from the automation lesson.

The sequencing matters too. Rules that require a sequence across sources are far more specific than single-event rules, which is why "beaconing plus a new persistence entry on the same host" is worth ten times "beaconing".

Dashboards that a tired analyst can read at 3am

Dashboards are frequently built to impress and rarely built to be used. The test is whether someone half-awake can tell in five seconds whether anything needs attention.

What works:

  • One question per panel, with the question as the title. "Hosts with new persistence in 24h" beats "Endpoint Overview".
  • Absolute numbers next to a baseline. 47 means nothing; "47, usual range 10-20" means something.
  • Deviation highlighted, not raw volume. Total event count is the least actionable number in security and the most commonly displayed.
  • A visible data-freshness indicator. A dashboard that silently shows yesterday's data because ingest broke is worse than a blank screen, and this is exactly the failure mode from the logging lesson appearing at the top of the stack.
  • Drill-through to the underlying events. A number nobody can open is decoration.

What fails: pie charts of event types, world maps of attack origins, and anything whose purpose is to look busy on a wall. They answer no question an analyst has.

Tuning: suppressing noise without suppressing signal

Tuning is the ongoing work of making alerts mean something, and it is a first-class activity rather than a sign the detection was bad.

Legitimate tuning:

  • Exclude a specific, documented benign cause. The backup agent on these named servers, performing this named action. Narrow, justified, and recorded.
  • Raise a threshold to match observed normal, having actually measured it.
  • Add a condition that increases specificity — not just the suspicious process, but the suspicious process with an unusual parent.
  • Route rather than suppress. Low-value alerts can go to a review queue or a daily digest instead of the live queue. They still exist when you need them during an investigation.

Tuning that quietly destroys the detection:

  • Excluding broadly. "Ignore all activity from the server subnet" silences the segment you most want to watch.
  • Excluding by account — usually a service account, which is precisely the account an attacker wants to use.
  • Raising a threshold until it never fires. The rule is now a comment.
  • Disabling and not recording why, so nobody knows six months later whether it was noise or an outage.

Two disciplines make the difference. First, every exclusion carries a reason and a date, and gets reviewed; an exclusion added for a migration should not outlive it. Second, re-test the detection after tuning using the lab from lesson 2: run the benign technique and confirm it still fires. Otherwise you are back to the theme this course keeps returning to — silence that could equally mean safe or blind, with nothing distinguishing them.

Topics this lesson owns

  • [x] Index, parse, search: the shape of every SIEM
  • [x] Writing a query that answers one question
  • [x] Correlation rules and the cost of a bad one
  • [x] Dashboards that a tired analyst can read at 3am
  • [x] Tuning: suppressing noise without suppressing signal

Practise what you just read

1. A detection rule matching a specific command line argument stops firing after the attacker recompiles their tool. What does this reveal about the rule?

Select one

  1. The rule was correctly written but the log source has stopped reporting
  2. The rule needs a higher severity so that it is evaluated more often
  3. The rule was written at procedure level, which an attacker changes cheaply
  4. The rule should be replaced with a signature from a threat intelligence feed
Show answer

C. Procedures are the cheapest thing for an attacker to change. A rule matching the requirement underneath the procedure, such as reading credential memory, survives recompilation because the attacker cannot avoid the requirement.

2. Why is tuning a noisy rule by excluding the host that generates most alerts a risky approach?

Select one

  1. The exclusion removes detection for that host, usually a busy important one
  2. Exclusions cannot be documented in most detection platforms
  3. Excluding a host causes the rule to stop evaluating for every other host
  4. The excluded host will generate errors that fill the collector's storage
Show answer

A. Tuning by exclusion silently converts a detection gap into a quiet queue, and the hosts that generate the most activity are frequently the ones that matter most. Tuning the condition rather than the scope keeps coverage while removing noise.

3. What is the most important property of a correlation rule that combines several weak signals?

Select one

  1. It must evaluate all of its inputs within the same one-minute window
  2. It must use only log sources that report in a normalised schema
  3. It must be built from at least three independent data sources
  4. Each signal must be checked, because one broken input silently weakens it
Show answer

D. A correlation rule fails quietly when one of its inputs stops arriving: the rule still runs, still evaluates, and simply never matches. Nothing distinguishes that from an absence of the behaviour unless the inputs are monitored individually.

8 more questions on this objective are part of the full course.

Practise the full question bank in the exam simulator

Hands-on labs

All hands-on labs

Part of the free CompTIA CySA+ CS0-004 course — 40 lessons and 56 hands-on labs.

This is an independent study companion for CompTIA CySA+ CS0-004 and is not produced by or endorsed by CompTIA.