CKS Monitoring, Logging and Runtime Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  evt.type=read and fd.name=/etc/shadow

  Why it's wrong here

  The read syscall operates on an already-open file descriptor, so it cannot observe the initial path resolution or permission checks performed by the kernel when the file is first opened. A failed open attempt (e.g., permission denied due to shadow mode 000) will never reach read, meaning this rule would miss the most common probing attack. Additionally, matching fd.name on read events is unreliable because Falco may not resolve the file descriptor back to a path once the file is closed or the descriptor is reused. Detection should occur at the open/openat syscall, where the path is an explicit argument and both successful and failed attempts are visible.

• ✗

  spawned_process and proc.name in (cat, less) and container

  Why it's wrong here

  This rule triggers on any containerized process named cat or less, regardless of which file is read, leading to a high false-positive rate from legitimate shell usage or log inspection. It also fails to detect attacks that use other readers such as tail, head, more, or a custom-compiled binary that directly opens /etc/shadow without spawning a known process name. The rule contains no reference to a file path, so it cannot distinguish between harmless reads of application logs and illicit access to sensitive system files. Falco is more effective when keying on syscalls like open/openat with the target path, rather than relying on process-name heuristics.

• ✗

  evt.type=execve and proc.name=cat and fd.name=/etc/shadow

  Why it's wrong here

  The execve syscall is used only when a program is loaded for execution; it does not carry an fd.name field because no file descriptor is being read or written at that moment. Even if fd.name were available, requiring proc.name=cat is far too narrow and misses accesses made by less, more, vim, or a custom script that opens /etc/shadow directly. This rule incorrectly conflates process creation with file I/O: the path-based access occurs after execve when the program calls open, and the open syscall is where the kernel first resolves the target file. A correct Falco rule should focus on evt.type=open with fd.name matching the protected path, not on execve.

• ✓

  evt.type=open and fd.name=/etc/shadow

  Why this is correct

  The open syscall is the correct hook because it is the first syscall where the target path is supplied by the caller and resolved by the kernel, making it ideal for path-based detection. With evt.type=open, fd.name matches the path exactly as passed, and the event is emitted on both successful opens and failed attempts like EACCES, so even permission-denied probing is captured. This rule does not depend on the process name, meaning it works for any utility or binary, and it also covers openat variants when Falco normalizes them appropriately. It is the most reliable and complete condition for detecting access to /etc/shadow among the given options.

Go deeper

Related to this question