During a Linux incident, auditd shows one execve record for /usr/bin/curl, but you need the full parent-to-child command lineage across a containerized host. Which telemetry should you request to reconstruct the execution chain?
Select an answer to reveal the explanation.
Short Explanation
Think of execve audit records like a chain of custody for process births: they show who ran what and who spawned it. NetFlow or auth logs can tell you about traffic or login, but they won't prove a parent process launched the next command. You want the execution chain itself, not a side-channel hint.
Full Explanation
The auditd execve record is the right telemetry for reconstructing command lineage because it captures process-execution events, including the executable path, arguments, process identifiers, and the parent process relationship that lets you build a parent-to-child chain. In Linux incident response, execve is the system call invoked when a process executes a program, so audit records generated at that point provide a forensic trail from an initial shell or script to subsequent binaries. Network connection metadata can show communication between hosts or containers, but it does not reveal which process made the connection or what command line produced it. File-write events may indicate persistence or staging artifacts, yet they describe filesystem changes rather than the sequence of process launches. Authentication events can identify a login session or account used, but they do not establish the internal process tree after the session began. Exam caveat: when the stem asks for lineage, execution chain, or command ancestry, choose process-execution telemetry over network, file, or authentication sources. Operational check: query the audit subsystem for execve records around the alert window, correlate pid/ppid fields, and pivot outward to map the full suspicious process tree.