An SOC analyst needs a portable detection for suspicious PowerShell encoded commands in Windows event logs. The rule must be reusable across the SIEM by translating it into native queries. Which artifact should the analyst author?
Select an answer to reveal the explanation.
Short Explanation
Think of Sigma like a recipe written once, then translated into your SIEM’s cooking language. You write the detection logic once, then let a converter turn it into native SIEM queries. The trap is confusing it with YARA, which hunts files and memory, not event logs.
Full Explanation
Sigma is a vendor-neutral, YAML-based rule language for describing log-based detections. A rule names the log source, selects fields, and defines conditions such as matching a PowerShell process that launches an encoded command. A Sigma backend then translates that same rule into a native SIEM query, allowing one detection to be reused across platforms. This makes Sigma appropriate for portable threat detection logic rather than host-based scanning. YARA is designed for matching byte patterns, strings, or structures in files and memory, so it does not express event-log query conditions. NetFlow describes network flow records such as source, destination, ports, and byte counts, which can support network analysis but cannot define a host log detection rule. A vulnerability scan template configures checks for weaknesses, not detection of malicious activity in log telemetry. Exam caveat: treat Sigma as a portable detection specification, not a scanner, YARA rule, or network export. Operational check: convert the rule to the target SIEM syntax and run it against known benign and malicious event samples before enabling alerting.