CompTIA CySA+ (CS0-004) Training Course

Every detection you will ever write depends on a log that somebody decided to collect, forwarded through a pipeline somebody built, and retained for a period somebody chose. CySA+ tests this as an analytical skill rather than an inventory question. When a scenario tells you a technique was missed, the answer is usually not that the analyst was careless. It is that the environment was never instrumented to see it.

Visibility is a property of the architecture, not the tool

Start with a simple test: for any technique, ask which device sits on the path the technique must cross, and whether that device both records the crossing and ships the record somewhere you can query it. Three failure modes follow from that question.

• No sensor on the path. Two virtual machines in the same subnet talk to each other without traversing a firewall or an inspection point. Lateral movement between them produces no network record at all, and you are left with whatever the endpoints themselves logged.
• A sensor that records but does not forward. A local Windows Security log rolls over in four hours on a busy domain controller. The event existed. By the time you looked, it was gone.
• A sensor that forwards but does not record enough. Firewall logs that capture the five-tuple and byte counts but not the TLS Server Name Indication field tell you a host talked to an IP address, not which domain it asked for.

Segmentation cuts both ways here. Splitting a flat network into zones with inspection at the boundaries creates chokepoints where sensors are effective, which is why segmented environments produce better east-west detection than flat ones. But over-segmenting without adding sensors at the new boundaries simply moves traffic you cannot see somewhere else.

The ingestion pipeline, and where evidence goes wrong

Between the event and your query sits a pipeline with a predictable set of weak points, and CySA+ scenarios exploit all of them.

Collection is agent-based or agentless. Agents give you process-level fidelity and survive network interruptions by buffering locally; agentless collection over syslog or an API is cheaper to deploy and easier to sustain at scale, but it drops events silently when the collector is saturated. Syslog over UDP in particular has no delivery guarantee. A gap in a UDP-fed log source is not evidence that nothing happened.

Normalization and parsing map vendor-specific fields into a common schema so a query for a source address returns results from the firewall, the proxy, and the endpoint at once. When a vendor changes a log format after an upgrade, the parser breaks quietly: events still arrive, but the fields land in the wrong place or in an unparsed blob, and your existing correlation rules stop firing without generating any error. Checking whether a rule stopped matching because the behavior stopped or because the parser broke is a standard triage step.

Time is the field the entire discipline rests on. If hosts drift, your reconstruction of an incident is wrong in ways that are hard to notice, because the events are all present and merely in the wrong order. Two disciplines prevent this: synchronize every source against the same authoritative time service, and store timestamps in UTC so that daylight-saving transitions and multi-region deployments do not silently reorder a timeline. When you build a timeline during an incident, record which clock each event came from.

Retention is a budget decision with investigative consequences. Dwell time for a competent intrusion is frequently longer than a short retention window, so an environment retaining thirty days of full telemetry cannot answer the question that matters most — when did this start. The common compromise is tiered: full-fidelity data hot for a short window, reduced or summarized data such as flow records held far longer, and archives available on restore.

Sensitivity, criticality, and where to point the budget

You cannot instrument everything at maximum fidelity. Prioritization comes from the asset inventory, and it is driven by two separate properties that scenarios deliberately confuse.

• Data criticality is about the information the asset holds — regulated data, intellectual property, credentials, cardholder data.
• Operational criticality is about what breaks if the asset stops. A domain controller may hold little regulated data and still be the most consequential machine in the building.

A third property matters for detection specifically: chokepoint value. Domain controllers, identity providers, egress proxies, and jump hosts see a disproportionate share of adversary activity regardless of what they store. Instrumenting them heavily buys more detection per gigabyte than instrumenting a large number of endpoints lightly.

Turning sources into detections

A log source is not a detection. The path runs from source, to a parsed and normalized event, to a query that expresses a behavior, to an alert with a defined response. Most environments have far more sources than detections, and the honest measure of a security operations program is coverage of adversary behaviors, not the number of gigabytes ingested. Mapping the detections you actually have against a framework such as MITRE ATT&CK exposes the gap between the two, and gives you a defensible argument for the next log source you want to onboard.

Carry three habits into every scenario in this module. Ask what would have had to be logged for the described activity to be visible. Ask whether the absence of an event is evidence of absence or evidence of a gap. And ask whether the timestamps you are reasoning from came from clocks you trust.