Security Evidence & Logs.

From building controls to seeing what they actually do.

Lessons 05–08 taught layered protection, endpoint and network safeguards, authentication, and data handling. Now we start Phase 04: Detect Problems. Instead of deploying another control, we'll evaluate the evidence those controls produce. That means reading what a log source observed before deciding what the evidence proves.

You do not need a SIEM account, security tenant, lab agent or enterprise software. This course uses only fictional Northstar Services records. We won't perform live queries or modify systems; the priority is practical reasoning transferable to help desk, NOC and junior SOC work.

A log is a record, not a verdict.

Security logs capture observations made by systems. Learn to read what a record actually says before deciding what happened.

An application might record that a login failed, a network device might log a denied connection, and an endpoint agent might log a quarantined file. These records describe what each component observed at a particular point in a workflow; they do not automatically describe everything the user, attacker or application did afterward.

Begin every investigation with an explicit question: What operation was attempted, what did this source observe, and what is still unknown? A blocked attempt matters, but it is not evidence of a successful compromise. An accepted event may be routine unless its context, identity and actual resource access suggest something else. Store conclusions separately from raw observations.

Read fields before reading intentions.

Time, source, identity, target, action and result form the backbone of a useful security event.

Different products use different names for these fields. A Windows security event may carry an event ID and target account; an identity service can record a sign-in result, device and application; a firewall may show source, destination, port and policy action. The source tells you what the fields mean and which system enforced the result.

IP addresses identify a network connection endpoint rather than a verified human. Hostnames can change and be reused. A device name, account label or cloud region is supporting context, not definitive attribution. Preserve an event identifier, source and raw outcome so a second analyst can reproduce the interpretation.

Time zones, clock drift and event ordering.

A timeline can be wrong even when every source log is correct in isolation. Normalize time before claiming cause and effect.

One sensor may display UTC while another exports local time with a daylight-saving offset. A third may have a clock several minutes behind. Ingested timestamps can show when an event arrived, not when it occurred. Record the timezone and whether the time comes from the device, provider or collection system.

Create a normalized UTC timeline and note uncertainty rather than reordering conflicting events to fit a preferred explanation. When timestamps disagree, look for correlation IDs, transaction IDs or other shared identifiers. Do not assume a later collected event is necessarily a later action. Request time synchronization review when drift is suspected.

Match a question to a source that can answer it.

An identity provider, endpoint agent, firewall, DNS resolver and application answer different questions. Correlation begins with knowing each viewpoint.

Identity logs can establish attempted and successful sign-ins, policy evaluations or registration changes. Endpoint telemetry may reveal process launches, blocked execution and file actions. Network and DNS records describe traffic and name resolution but rarely prove who read a document. Application audit records can show the actual protected operation if the app records it.

Use the narrowest available authoritative evidence for the claim. An EDR alert alone cannot prove data exfiltration, a firewall allow cannot prove successful account login, and a DNS query does not prove a destination connection. Missing events may reflect retention, a broken agent, filter scope, unsupported activity or simply that nothing was recorded.

Separate rejected logins from usable sessions.

Authentication events need the same care as the account protections you studied earlier. A password spray, an MFA challenge and a valid session are different stages.

Several failed attempts across many accounts can suggest password spraying, but they may also involve a misconfigured client. Successful primary credential checks do not necessarily mean MFA or conditional access succeeded. Some platforms log each stage separately, with a final sign-in result and subsequent resource or token activity.

Check the exact stage and outcome, the targeted accounts, client and app, approved users' normal behavior, session validity and any credential or MFA method changes. Do not call an attempted attack a breach. A successful authentication from a strange network merits correlation, not automatic proof the person was malicious.

An EDR alert describes a detection outcome, not all execution.

Security products may detect, prevent, quarantine or merely observe an event. These outcomes cannot be treated as interchangeable.

An endpoint agent can record that a script was blocked before execution, that a suspicious process was quarantined after launch, or that a rule matched a harmless application. The disposition and parent process, affected file, agent health, telemetry window and subsequent process events determine what the record supports.

Do not run suspicious samples, remove security protections or isolate production machines without authorization. Examine available read-only event details, check whether execution or persistence actually occurred, correlate with business change tickets and escalate when the evidence or severity warrants it. A quiet dashboard may also mean an unhealthy or disconnected agent.

DNS and network connections show paths, not intent.

DNS resolution, firewall policy and proxy telemetry are useful context, but a recorded connection is not automatically data theft.

A DNS query may come from a browser, scheduled health check, telemetry agent or unwanted program. A firewall ALLOW means a rule permitted a flow at that enforcement point. A proxy log may show a request and response status, but the content, credentials and final business effect may be outside that source's view.

Correlate name resolution with endpoint process ownership, actual network session and application or server records. Consider normal baselines and recent configuration changes. Never declare exfiltration from a hostname or unusual traffic volume alone; quantify what a source can prove and what must be confirmed at the destination.

An alert is a hypothesis worth testing.

A detection rule turns selected telemetry into a signal. That signal requires triage, not automatic acceptance as fact.

Rules may use thresholds, signatures, anomalies or correlations; each has false positives and blind spots. An alert's severity typically expresses the rule's priority or potential impact, not a statistical probability that an incident has happened. A 'critical' label may still be an outdated rule or missing context.

Read the alert's query or rule description, covered source, observation window, suppression and aggregation policy, supporting raw events and acknowledged limitations. Ask whether the matched pattern is common in normal work. Separate security impact and urgency from certainty about root cause.

Correlate independent records without forcing a story.

Evidence becomes more useful when records from separate sources describe related parts of the same action with consistent identifiers and times.

Start from the initiating event, normalize timestamps, capture identifiers and compare identity, endpoint, network and resource evidence. An identity sign-in followed by a file export can be concerning when the account, app, request and times align. But two events happening near one another are not automatically causally related.

Look for counterevidence: blocked policies, known update jobs, expected service accounts, duplicate alerts and healthy application activity. Distinguish a hypothesis from a conclusion; record which independent checks would disprove or strengthen it. If evidence contradicts your idea, revise the idea rather than discarding the evidence.

Incomplete telemetry is an explicit investigative finding.

Security investigations are constrained by what was collected, retained and visible. Missing logs must not silently become proof that nothing happened.

A workstation may be offline, a security agent could be unhealthy, cloud retention may have expired, or the analyst's query could exclude relevant accounts. Application logging might not capture file access at all. Record these coverage limits next to a finding and seek an alternative authorized source where possible.

Preserve the scope of your query, source systems, collection window, time adjustments and any data-quality warnings. Avoid copying access tokens, full credentials or confidential payloads into tickets. Where policy requires, preserve relevant event records through approved evidence-handling procedures rather than editing original logs.

Record claims, uncertainty and the next safe check.

A useful investigation note is specific enough for another technician to continue without repeating guesses or taking unsafe action.

Document the reported impact, time range and timezone, affected identity/device/service, raw event references, observed outcomes, competing explanations, confidence limits, and the next read-only verification or escalation. A good note says 'MFA denied three attempts' rather than 'attacker stole the account' when no successful sign-in was recorded.

Containment changes, token revocation, account disablement and device isolation require the appropriate authority and response process. The first objective here is evidence quality and handoff. Preserve relevant artifacts, avoid destructive tests, and escalate urgency based on business impact and credible indicators.

Investigate Northstar timelines without a live SIEM.

Practice reading fictional identity, endpoint, DNS and application events before drawing a defensible conclusion from mixed signals.

Each Northstar timeline includes source-specific observations, outcomes and clues. Inspect at least two event details, then compare competing hypotheses. Look for a source that proves the claimed activity, not merely a suspicious label. A blocked attempt and an authorized business operation may appear in the same investigation window.

The interactive Security Evidence Workbench is an offline teaching model. It does not query customer systems, execute commands or assign a statistical compromise score. Your goal is to distinguish what the known events support from what requires further confirmation, and to suggest a scoped, safe next investigative step.

Write the finding another defender can trust.

Write a short case summary that states the affected asset, event window in UTC, original source IDs, observed result, strongest supporting observations, contradictory evidence, source-coverage gaps, what has not been confirmed and the next read-only check. Use this distinction consistently: observed is not the same as suspected, and suspected is not the same as confirmed.

Lesson 09 focuses on reading and evaluating foundational evidence. The next Phase 04 module will turn those skills into alert prioritization, case triage and escalation decisions; it remains unavailable until it has been built and reviewed.

Use established guidance as your evidence handling grows.

Everything required for Lesson 09 Practice is taught here. For deeper operational implementation, use the official references after mastering the event reasoning in this lesson.