Security+ Investigation Evidence: Logs, Timelines and Custody

A firewall shows a connection. An identity provider records a successful authentication. An endpoint sensor reports that a process opened a file. None of those records alone proves who deliberately took an action, whether data were stolen or what an organization’s next response must be. Security investigations work by connecting sources, testing competing explanations and preserving the material needed to challenge the conclusion later.

CompTIA Security+ Objective 4.9 asks candidates to use data sources that support investigation. That differs from building a SIEM product, writing an entire incident-response plan or memorizing a list of log types. The useful skill is selecting which evidence answers a specific unanswered question, understanding its limitations, and keeping enough provenance that a reviewer can trace the result.

Follow the evidence

Frame the investigation
Choose evidence sources
Case: suspicious privilege grant
Preserve custody and integrity
Avoid attribution shortcuts
Handoff and safe response
Practice the evidence decision

Start with the question, not the largest log file

An investigation can waste hours collecting network packets when the immediate question is who approved a cloud role change. Begin with one testable hypothesis: “An unauthorized principal modified this application’s permissions between 09:00 and 09:20.” Identify the system that makes that decision, the fields needed to test it, and what alternative explanations would look like. Keep the time range broad enough to capture a possible preceding event, while avoiding indiscriminate collection of unrelated personal records.

NIST SP 800-86 discusses forensic collection across files, operating systems, networks and applications from an IT response perspective. It was published in 2006 and is not legal advice or a complete present-day investigation protocol; technical platforms and jurisdictional handling duties require current local procedures. Current NIST SP 800-61 Revision 3 places incident response within broader cybersecurity risk management rather than treating evidence collection as a disconnected emergency task.

The objective is a defensible explanation, not simply proof that a tool generated an alert. Identify facts, inference and uncertainty separately throughout the case.

Each source answers a different question

Source	Usually establishes	Important limitation
Identity-provider event	Account, authentication method, session/context	Credentials or tokens can be used by someone other than the account owner
Cloud control-plane audit	Principal, action, resource, response	May not describe actual downstream data access
Endpoint process telemetry	Program parent, command-line context, file activity	Depends on sensor coverage and retention
DNS/network flow	Resolved names, addresses, ports, timing	Does not automatically identify a human or prove application-layer content
Application audit trail	Business action, account and affected object	May depend on service logging configuration and local clock

Logs must be normalized carefully. Two systems reporting “09:12” may be in different time zones or have unsynchronized clocks. Convert times to an explicitly recorded standard, preserve the original event timestamp and its time-zone context, and track clock uncertainty if the source is unreliable. A perfectly ordered timeline assembled from wrong time assumptions can be worse than no timeline.

The SIEM and log-source triage article discusses telemetry collection and correlation. A SIEM search result is often an investigative starting point, not the authoritative raw original. Record which query, index, filter, source and retention window produced the event. If a log was altered by ingestion or field extraction, retain a way to inspect the raw event when needed.

Worked case: an unexpected cloud privilege grant

At 09:11, a university’s cloud audit records that an application service principal granted a broad reader role to a contractor identity. At 09:15, an alert reports a download from a protected storage container. A help-desk ticket from the contractor requests access, but its approval field is blank. The first decision should be to establish whether the grant was legitimate, not to declare the contractor malicious or announce a confirmed breach.

Investigators preserve the role-change audit event, the originating service identity, its relevant session or key use, the storage access record and the change/ticket timeline. They identify whether the application service principal was authorized to grant roles. They also check whether a scheduled deployment used the principal, whether the contractor actually retrieved sensitive objects, and whether logs show only listing metadata instead of file downloads. Each answer narrows the case.

The privilege change could result from misconfigured automation, an abused service credential or a deliberate unauthorized action. The observed fact is that the permission change occurred; the actor’s motive remains uncertain until other evidence supports it. Response may require coordinated revocation of an unnecessary grant even while attribution is unresolved.

Protect evidence integrity and document its handling

Chain of custody is not a fancy name for an evidence folder. It records who collected an item, when, how it was obtained, where it was stored, who accessed it, and which transformations were performed. If an exported log was filtered, document the source and query. If a forensic image was created, record its device identity, capture method and validation hash where technically appropriate. A hash can detect changes to a captured file; it does not independently prove that the original log contents were complete or authentic.

Use least-privilege access and preservation procedures suited to the organization. Volatile data can disappear after a restart; collecting it may itself alter system state. A rushed full-disk capture on an actively compromised machine can interfere with containment and business continuity. Incident responders must balance safety, legal authority, system criticality and forensic value. The correct choice depends on the state of the incident and who has authorization.

Be careful about privacy. A memory or disk image can contain authentication secrets and personal records irrelevant to the investigation. Controlled storage, access review, retention and legal guidance should accompany collection. The fact that evidence may be useful does not authorize unrestricted duplication or disclosure.

Do not turn an account name into human attribution

Suppose identity logs show a user called “s.jones” accessed a service from an unusual location. That does not prove Jones personally operated the session. A stolen token, compromised device, delegated service, VPN or known travel pattern could explain it. Correlate source device, authentication factor, application authorization, client IP, session token evidence and device activity before drawing a personal conclusion. If proof is lacking, say so.

Absence of an alert is also not proof that nothing happened. Sensors may have been disabled, the event may fall outside retention, or the behavior may have been permitted by an overbroad policy. Record relevant visibility gaps so the final report does not appear more certain than the sources warrant.

Make findings actionable without overstating certainty

A useful case handoff includes the investigated question, observed events, sources, clock assumptions, confidence, competing explanations, affected systems, containment actions and unresolved evidence needs. Separate a recommended protective action from claims about attacker identity. A security lead can revoke an unjustified privileged grant and require reauthorization before every attribution question is answered.

The broader incident response process covers preparation, detection, containment, recovery and lessons learned. Investigation feeds those decisions; it does not replace service restoration or management communications. A well-written timeline should enable the next responder to understand what is known without repeating the entire collection.

Use practice questions to test your next-evidence judgment

For a source-selection question, ask what fact is missing. If a firewall flow identifies a source address but not the employee, use authorized identity/session mapping rather than pretending the firewall names the user. If a cloud audit proves a permission grant but not a data transfer, inspect data-plane object access records rather than citing the control-plane event as evidence of exfiltration.

The SY0-701 investigation-data practice questions explore such distinctions. After choosing a source, state its likely blind spot and one independent corroborating source. This is a stronger test of understanding than memorizing that “SIEM has logs.” When reviewing a CompTIA SY0-701 Practice Test scenario, distinguish evidence of an account action from a justified claim about the human actor; selecting the right log cannot by itself settle attribution.

A final five-point report check can be expressed in plain language: What happened? Which original records support it? Which actions were inferred rather than observed? Who handled and could verify the evidence? What protective step is justified before confidence improves? Those questions make investigations more reliable and more useful to decision makers.

Sources: CompTIA SY0-701 Objective 4.9, NIST SP 800-86 (historical forensic integration guidance) and current NIST SP 800-61 Revision 3 (2025 response risk-management guidance). Organization-specific privacy and evidentiary obligations require authorized professional review.