IT PATH
My Path

Log Analysis and Detection Engineering

Read raw telemetry, build reliable detections, and validate them against attacker techniques.

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

Recommended study time

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

  • Read the lesson20 min

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

  • Second pass with notes12 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

  • Analyse process, network, and authentication telemetry to reconstruct activity.
  • Write detections with clear intent, scope, and false-positive expectations.
  • Validate detections with test activity mapped to known techniques.

Start here

About 8 minutes of reading, in 10 short parts.

Detection engineering is the craft of turning a guess about attacker behaviour into a working, tested alarm. Log analysis is the skill of reading raw telemetry, such as process creation events, closely enough to reconstruct exactly what happened on a machine.

Where you meet it: A detection engineer writes and tests a new alert after a threat report describes a technique the current rule set does not cover, then watches whether it fires correctly for weeks afterward.

The lesson, part by part

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

Think of a building's smoke detectors. A cheap one just checks 'is there smoke', which also goes off from toast. A good fire safety engineer designs a detector that distinguishes cooking smoke from an actual electrical fire by looking at multiple signals together: smoke density, heat rise rate, and location. Detection engineering does the same thing for computer behaviour, combining several weak signals into one reliable alarm.

Log analysis is like being a detective reading witness statements after the fact. Each log line is one small statement — 'this program started', 'this file was created', 'this connection was made' — and the analyst's job is to line up dozens of these statements in the right order to understand the full story of what an attacker actually did.

Key ideas

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

  • Detection engineering treats each new alert as a small software project with a hypothesis, required fields, and a validation step.
  • Process telemetry with full command-line logging is the single most valuable data source for reconstructing attacker behaviour.
  • Parent-child process relationships reveal living-off-the-land abuse that a simple process name allowlist would miss entirely.
  • Every detection should map to a specific MITRE ATT&CK technique so coverage gaps are visible on a matrix, not just in a spreadsheet.
  • A rule that has never been validated against a known-positive test case may be silently broken from the day it was deployed.
  • Baseline drift means a rule that was precise a year ago can become noisy as normal business software changes.
  • Detection as code with version control and peer review reduces the risk of an untested change breaking production coverage.

Building a detection for encoded PowerShell launched from Office

A worked example, step by step.

A threat intelligence report describes a campaign using malicious macros to launch base64-encoded PowerShell that downloads a second-stage payload; the detection engineer must build and validate a rule.

  1. 01Confirm telemetry availabilityVerify that EDR agents on Windows endpoints capture process creation events with full command_line, not just process_name, since the hypothesis is untestable without that field.
  2. 02Draft rule logicWrite logic matching parent_process_name IN (WINWORD.EXE, EXCEL.EXE) AND process_name IN (powershell.exe, pwsh.exe) AND command_line CONTAINS -enc.
  3. 03Baseline checkQuery 90 days of historical process telemetry for this exact pattern and find zero legitimate hits, confirming a low expected false-positive rate.
  4. 04Emulate safelyIn an isolated lab VM, open a benign macro-enabled document that launches powershell.exe -enc <base64> and confirm the target behaviour actually occurs.
  5. 05Validate the alert firesConfirm the SIEM rule triggers within 40 seconds with parent_process_name, process_name, command_line, host, and user correctly populated.
  6. 06Map technique coverageTag the rule with T1059.001 PowerShell and T1566.001 Spearphishing Attachment so the ATT&CK matrix reflects the new coverage.
  7. 07Peer reviewSubmit the rule as a pull request with the test evidence attached; a second engineer reviews scope and exclusions before merge.
  8. 08Deploy and monitorPush to production with an owner assigned and a 30-day revalidation reminder to catch baseline drift.

Outcome: The environment gains a validated, low-noise detection for a specific documented attacker technique, with evidence proving it fires correctly rather than existing only on paper.

Log analysis and detection engineering reference

Worth keeping at hand while you work.

T1059.001
Command and Scripting Interpreter: PowerShell
T1566.001
Phishing: Spearphishing Attachment
T1218
System Binary Proxy Execution (living off the land)
T1027
Obfuscated Files or Information
Windows Event ID 4688
Process creation, requires command-line auditing enabled
Sysmon Event ID 1
Process creation with hashes and command line
Sysmon Event ID 3
Network connection
Parent-child chain
Sequence showing which process launched which
Detection as code
Managing rule logic in version control with review and tests
False-positive rate
Expected proportion of benign matches, set during baseline testing
Purple team
Exercise validating whether detections fire against live red team techniques
Certutil abuse
Living-off-the-land technique using a built-in certificate tool to download files

Common misunderstandings

What most beginners get wrong here.

  • A detection rule is done once it is written and deployed.

    A rule is only trustworthy after it has been validated against a known-positive emulation confirming it actually fires.

  • Blocking on process name alone is sufficient.

    Attackers rename or use built-in binaries; parent-child relationships and command-line content are far more resilient signals.

  • A detection that worked last year still works today.

    Baseline drift from new legitimate software can make an old precise rule noisy, so periodic revalidation is required.

  • Living off the land means using custom malware disguised as a system tool.

    It specifically means abusing legitimate built-in tools like PowerShell or certutil, not disguised malware.

  • Mapping to ATT&CK is just documentation overhead.

    It reveals real coverage gaps across the matrix that a list of rule names alone would not show.

Exam traps

How the question writers try to catch you out.

  • CySA+ scenarios often give you a process tree and ask which parent-child relationship is anomalous, expecting recognition of an unusual launcher like a document app spawning a shell.
  • Expect questions that require identifying command-line encoding flags such as -enc or -EncodedCommand as an evasion indicator.
  • Exam items test whether you know a detection needs a documented false-positive expectation before it goes to production, not just correct logic.
  • Watch for distinguishing threat hunting output, which is a one-off finding, from detection engineering output, which is a durable validated rule.
  • Questions may present a rule that never fires and ask for the most likely cause; the expected answer is usually missing telemetry or a renamed field, not a bad hypothesis.
  • PenTest+ and CySA+ both expect familiarity with specific technique IDs like T1059 rather than only technique names.

Check yourself

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

  • Why is command-line logging essential for detecting encoded PowerShell?

  • What does living off the land mean?

  • Why validate a rule with an emulation before production?

  • What two ATT&CK techniques apply to a malicious macro launching encoded PowerShell?

  • What causes baseline drift?

  • What is detection as code?

Quick reference

A condensed summary of the lesson above, for revision.

What It Is

Log analysis reconstructs behaviour from process creation, command lines, parent-child relationships, network connections, and authentication events. Detection engineering turns a hypothesis about attacker behaviour into a rule with defined data sources, logic, severity, and expected false positives, mapped to a framework such as MITRE ATT&CK and validated with controlled test activity.

Why It Matters

Signature-only defence misses the majority of hands-on-keyboard activity. Behavioural detections built and tested against real techniques are what catch intrusions that antivirus does not.

How It Works

  • Endpoint sensors record process, file, registry, and network events with parent context.
  • Detections query normalised events for behavioural patterns rather than static indicators.
  • Validation executes safe emulations of a technique and confirms the alert fires.

Where You See It

  • Detection engineering teams, purple team exercises, threat hunting, and SOC rule maintenance.

Key Terms

Parent-child process
Relationship revealing suspicious execution chains.
Living off the land
Abuse of legitimate built-in tools by attackers.
ATT&CK technique
A catalogued attacker behaviour used to map coverage.
Baseline
Normal behaviour used to distinguish anomalies.
Detection as code
Managing rules in version control with review and testing.

Examples

  • A Word process spawning PowerShell with encoded arguments is a classic high-value detection.
  • Service creation by a non-administrative account is rare enough to alert on in most environments.

Common Problems

  • Rules built on fragile fields
  • No test coverage
  • Environment-specific noise
  • Missing telemetry for the technique

How It Fails

  • A schema change silently breaks a rule, and no alert draws attention to it.
  • Overly specific logic misses trivial attacker variations.
  • Detections written without baseline knowledge flood the queue on day one.

How to Troubleshoot

  1. Run the rule logic against known-positive test data.
  2. Check whether the required telemetry is actually collected on the affected hosts.
  3. Compare the alerting population against baseline expectations to find noise sources.

Practical Knowledge

  • Version-control rules with review, tests, and change history.
  • Document expected false positives so triage is not rediscovering them.

Exam Coverage

  • Log and telemetry analysis
  • Detection creation and tuning
  • Technique mapping and validation

Interview Questions

  • How would you detect credential dumping without relying on a tool name?
  • How do you know a detection still works?

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. 01Write one detection hypothesis and the exact fields needed to test it.
  2. 02Review a week of process telemetry and identify the top ten normal parent-child pairs.