Objective 4.9: Given a scenario, use data sources to support an investigation

Cert: CompTIA Security+ (SY0-701) Domain: 4.0 Security Operations Weight: ~28% of SY0-701 (Domain 4 total) Depth: Apply / Analyze. Match an investigation question to the data source that most directly answers it. Read a short investigation brief, name the data sources to pull, and explain what each one should confirm or refute.

What this objective tests

You should be able to name the seven log types the objective lists (firewall, application, endpoint, OS-specific security, IDS/IPS, network, metadata) and the four non-log data sources (vulnerability scans, automated reports, dashboards, packet captures). The exam puts you in the SOC Tier 2 analyst seat. You are handed a short scenario and you need to write the data-pull plan: which source first, which source confirms, which time window, which exact field. Drill the question-to-source mapping until it is reflex. This is the highest-leverage skill in Domain 4 because every later investigation skill assumes you already know where the answers live.

Key facts

The seven log types

CompTIA names seven log categories on the SY0-701 objective. Memorize the list. Memorize what each one answers. NIST SP 800-92 (Guide to Computer Security Log Management) is the canonical standard behind the practice of collecting, storing, and reading these logs.

Firewall logs

Firewall logs are the gate guard's notebook. Every allowed and denied connection at the perimeter or between segments is recorded. The standard fields are timestamp, source IP, destination IP, source port, destination port, protocol, action (allow, deny, drop), and often the rule ID that matched. Fortinet, Palo Alto, Cisco ASA, pfSense, and Meraki all write log records in roughly the same shape. They forward to a SIEM (Security Information and Event Management) over syslog, defined in RFC 5424. The investigator pulls firewall logs to confirm what crossed the boundary and when. The firewall does not see inside encrypted traffic, but it sees the conversation envelopes.

Application logs

Application logs are written by the application about its own behavior. A web app records HTTP requests with method, path, status code, response time, and sometimes the authenticated user. A database records queries, slow queries, and authentication attempts. A mail server records send and delivery events. Application logs are the right source when the question is about a transaction, a clicked link, a failed payment, or an internal error. They are often the only place a business-level event is recorded, because the firewall and the OS log do not understand what the app is doing.

Endpoint logs (EDR and Sysmon)

Endpoint logs come from the workstation or server itself. Process starts and stops, file changes, registry edits, USB device connections, and PowerShell command lines all live here. On Windows, Sysmon (System Monitor) from Microsoft Sysinternals is the standard add-on that extends the Windows Event Log with deep process, network, and file telemetry. EDR (Endpoint Detection and Response) products such as CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint layer on top of this and stream events to a cloud analytics back end. When the question is what the attacker did on the box, the endpoint log is the first source.

Key Sysmon Event IDs to recognize:

• Event ID 1: Process create. Includes the full command line and the parent process.
• Event ID 3: Network connection. Records the connecting process plus the remote IP and port.
• Event ID 7: Image loaded. Useful for catching DLL side-loading.
• Event ID 11: File create. Useful for tracking dropped files.

OS-specific security logs

The OS-specific security log is the operating system's audit trail. The three operating systems on the exam each have their own canonical source.

• Windows: the Security log in Event Viewer. Filterable by Event ID. The most-tested IDs are 4624 (successful logon), 4625 (failed logon), 4688 (process creation), 4720 (account created), 4732 (member added to security-enabled local group), and 4740 (account locked out).
• Linux: /var/log/auth.log on Debian and Ubuntu, /var/log/secure on RHEL and CentOS, and the systemd journal queried with journalctl. Records sudo, SSH, and PAM (Pluggable Authentication Module) events.
• macOS: the unified log, queried with the log command. Records authentication and security framework events.

Authentication and authorization questions go to the OS-specific security log first. This is also where lockout storms show up as Event ID 4740 on Windows.

IDS / IPS logs

IDS (Intrusion Detection System) alerts only. IPS (Intrusion Prevention System) alerts and blocks. The two leading open-source engines are Snort and Suricata. Vendor IPS appliances from Cisco, Palo Alto, and Fortinet all produce equivalent log records. Each alert names the rule that fired, the source and destination, the protocol, and a confidence rating. IDS and IPS logs are how the investigator points at suspicious traffic and times the attacker's movement across the network.

Network logs

Network logs are everything else on the wire that is not a packet capture.

• NetFlow and IPFIX (RFC 7011): summary records of network conversations. Source IP, destination IP, ports, protocol, bytes, packets, start time, end time. Answers who talked to whom and how much. Cisco NetFlow is the older standard. IPFIX is the IETF replacement.
• DNS query logs: what names were resolved. A great source for finding command-and-control beacons that resolve a domain every few minutes. Tools that produce them include Microsoft DNS server analytic logs, BIND query logs, and Cisco Umbrella.
• Proxy logs: what URLs were requested, what verdicts the proxy returned, and which categories matched. Zscaler, Cisco Umbrella, and on-prem proxies all produce them.
• Switch port logs: MAC addresses learned on each port, link state changes, and security violations.

Network logs answer the lateral movement and exfiltration questions.

Metadata as a data source

Metadata is data about data. It is the easy-to-miss seventh source in the objective. The exam tests it because real investigations turn on it more than students expect.

• File metadata: owner, group, creation time, modify time, access time, file hash (SHA-256), digital signature.
• EXIF data on images: device model, lens, software version, geolocation, timestamp. Standardized by the Japan Electronic Industries Development Association.
• Email headers: Received chain, From, Reply-To, Return-Path, Authentication-Results (SPF, DKIM, DMARC). RFC 5322 defines the message format. Header analysis exposes most spoofed senders.
• TLS certificate fields: Subject, Issuer, Subject Alternative Name (SAN), notBefore, notAfter, SHA-256 fingerprint.
• HTTP User-Agent strings and HTTP Referer header: tells the investigator what client made the request and where it came from.

NIST SP 800-101 (Guidelines on Mobile Device Forensics) covers metadata extraction for mobile devices and is the canonical reference if the case involves a phone.

Data sources beyond logs

The objective also names four non-log data sources. Investigators pull these to fill in what the logs cannot answer alone.

Vulnerability scans

Vulnerability scans tell the investigator what the system was theoretically exposed to. Nessus, Qualys, OpenVAS, and Rapid7 InsightVM all produce scan reports listing CVEs (Common Vulnerabilities and Exposures) with CVSS (Common Vulnerability Scoring System) scores. During an investigation, a recent scan report helps the investigator answer one question only: was the patch missing or was the box hardened. The scan report does not record attacker action. It reports exposure. Treat the scan as evidence about the door, not about who walked through it.

Automated reports

Automated reports are the scheduled or triggered outputs from SIEM and EDR platforms. A SIEM digest summarizing alerts by category over the last 24 hours. An EDR weekly report showing detections by host. A vuln scanner export emailed to the patch team every Monday. Investigators pull recent reports to build a baseline for what normal looked like and to find the pivot point where normal turned into incident.

Dashboards

Dashboards visualize the underlying log and event data. Splunk dashboards, Microsoft Sentinel workbooks, Elastic Kibana visualizations, and Datadog panels all let the investigator see trends fast. A spike in failed logons. A new top-talker on egress. A dip in EDR check-ins for a host that should be reporting. The dashboard is not the source of truth. The underlying log is. Always trace the chart back to the actual log entries before drawing conclusions.

Packet captures (pcap)

Packet captures record the raw bytes on the wire. Wireshark is the standard graphical tool. Tcpdump is the standard command-line tool. The current file format is pcap-ng, which supports multiple interfaces and richer metadata than the original libpcap format. Reading a pcap in Wireshark:

1. Open the .pcap or .pcapng file.
2. Filter by host with ip.addr == 10.20.30.40 or by protocol with dns or http or tls.
3. Right-click a packet and choose Follow then TCP Stream to see the full conversation reassembled.
4. Use Statistics then Conversations to summarize who talked to whom.
5. Convert epoch timestamps to local time and align with the rest of the case timeline.

Packet captures are the most expensive source to collect at scale, so they are usually targeted. Capture this host for the next hour. Capture this server's egress through the proxy for the day. Confirming whether sensitive data was actually exfiltrated, watching a command-and-control beacon, or proving that a TLS session was downgraded all need packet data.

Matching the question to the source

This is the working investigator's habit. Before pulling any data, write the question down. Then name the source that most directly answers it. Resist the urge to pull everything and grep it later. That is how investigations stall.

Time synchronization and chain of custody

Two forensic disciplines hold an investigation together. NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response) names both.

• Time synchronization. All systems must run NTP (Network Time Protocol) against the same reliable source so that log timestamps line up. Without time sync, events look out of order and correlation breaks. Standardize the time zone in the SIEM (UTC is the common choice) and convert at display time.
• Chain of custody. A documented trail of who handled each piece of evidence, when, and what they did with it. The chain starts the moment evidence is collected and never gaps. Without it, evidence is inadmissible in court and indefensible in a compliance audit.

MITRE ATT&CK and detection data sources

MITRE ATT&CK lists detection data sources next to every technique. Process monitoring, command-line monitoring, network connection creation, authentication logs, file creation, file modification. Investigators use the ATT&CK data-source list as a planning checklist: for this technique, which sources should I have collected. The framework is free, public, and vendor-neutral. It is the shared vocabulary modern SOC teams use when handing off cases between Tier 1, Tier 2, and forensics.

Common gotchas

• Treating the vulnerability scan as evidence of attacker action. The scan reports exposure. It does not prove anyone walked through the unlocked door. Pair it with the EDR or the OS log for confirmation.
• Trusting the dashboard over the raw log. The dashboard is the scout. The log is the source of truth. Always confirm a dashboard spike against the underlying event records before reporting a finding.
• Forgetting metadata. Email headers, EXIF, file hashes, and certificate fields answer questions the obvious source cannot. The objective lists metadata as one of the seven log types for a reason.
• Skipping the time-window question. Pulling a year of firewall logs to find one event is how investigations bog down. Pick the smallest window that contains the suspected event, then expand only if needed.
• Ignoring time synchronization. Without NTP discipline, log correlation breaks. Two systems off by 30 minutes turn a clear attack chain into a mystery.
• Pulling packet captures by default. Pcaps are expensive to collect and to store. Target them. A targeted 1-hour capture of one suspicious host usually beats a 24-hour capture of the whole perimeter.
• Confusing IDS with IPS. IDS detects and alerts only. IPS detects and blocks. The log records are similar, but the response is different and the exam tests the distinction.
• Mixing application logs with OS logs. The application log is what the app saw. The OS log is what the operating system saw. The same event sometimes appears in both with different fields. Pull both when the case spans the app and the host.
• Ignoring missing logs. A gap in the timeline is never harmless. Either logging broke without anyone noticing or an attacker cleared entries to cover tracks. Always investigate a gap.

Real-world context

In a SOC Tier 1 seat, this objective is the daily reflex. The analyst opens a ticket that says "user reported suspicious email at 09:42." The first reach is to email metadata: pull the headers, check Received chain, check Authentication-Results for SPF, DKIM, DMARC verdicts. If the headers look spoofed, the next reach is the email gateway log to confirm whether anyone else received the same message. If a user clicked the link, the next reach is the proxy log (network log) to see where the click landed, then the endpoint log to see what the browser process spawned. The whole investigation rides on knowing which source answers which question, in what order, in what time window.

In a Tier 2 seat, the same vocabulary expands. The Tier 2 analyst walks longer investigations: lateral movement across multiple hosts, exfiltration timelines that span days, insider abuse cases that require dashboards plus targeted packet captures plus chain-of-custody preservation. A pcap-ng capture from one suspicious host's egress port, indexed against the firewall log, scoped to a 60-minute window, plus the EDR process tree from the same host, is a standard Tier 2 dataset. The discipline is to name the question before pulling the source, then corroborate every finding with a confirming source.

In a forensics or e-discovery seat, every step is graded against the next audit or the next courtroom. NTP synchronization is the foundation that makes log correlation defensible. Chain of custody is what keeps the evidence admissible. Write blockers, verified SHA-256 hashes, and sealed originals are not paperwork; they are the difference between a case that holds up and a case that gets thrown out. Cyber insurance carriers and regulators (HIPAA, PCI DSS, SEC cyber disclosure) all assume the investigator can produce these artifacts on request.

Sources

• CompTIA Security+ SY0-701 Exam Objectives, Section 4.9
• NIST SP 800-92 Guide to Computer Security Log Management
• NIST SP 800-86 Guide to Integrating Forensic Techniques into Incident Response
• NIST SP 800-101 Guidelines on Mobile Device Forensics
• NIST SP 800-94 Guide to Intrusion Detection and Prevention Systems (IDPS)
• NIST SP 800-137 Information Security Continuous Monitoring (ISCM)
• RFC 5424 The Syslog Protocol
• RFC 5322 Internet Message Format (email headers)
• RFC 7011 Specification of the IP Flow Information Export (IPFIX) Protocol
• MITRE ATT&CK Framework, attack.mitre.org (detection data sources per technique)
• Microsoft Sysinternals Sysmon documentation
• Wireshark User's Guide (pcap and pcap-ng analysis)