Security Operations practice questions

Log integrity means getting logs off the host quickly and storing them where they cannot be changed.

An attacker with administrative rights on a host controls everything stored on it, including local logs and local copies. Near-real-time forwarding moves each event beyond the attacker's reach before it can be cleared, and immutable (write-once, retention-locked) storage protects the central copy from deletion or alteration. Larger logs, more audit categories and more frequent local copies all leave the evidence on the compromised machine.

1. Note that the attacker had admin rights on the server.
2. Rule out anything that stores logs on the same host.
3. Choose the control that moves logs off the host as they are created.
4. Choose the control that makes the stored copy unalterable.

Exam tip: Logs that never leave the host can be erased by whoever owns the host; forward them and store them immutably.

Log configuration decides which fields an event carries.

Windows process creation auditing records that a process started, but the command line is only included when the separate policy setting to include it is enabled. Script block logging is a tempting near-twin, but it covers PowerShell alone, while the requirement is every process. Log size and object-access auditing change retention and other event types, not this field.

1. Identify the missing field: process arguments.
2. Note the requirement covers every process, not just PowerShell.
3. Choose the setting that adds the command line to process creation events.
4. Reject settings that change retention or unrelated event types.

Exam tip: Command lines appear in Windows process creation events only after the include-command-line policy is enabled.

Ingestion includes parsing and normalization, not just receiving data.

A SIEM correlates on normalized fields such as source IP and user. When a new source is onboarded without a parser (or with the wrong one), its events are stored but their values stay buried in a raw message, so field-based rules never match. Time sync, transport encryption and retention all matter for logging, but none extracts fields.

1. Note that events arrive and are stored.
2. Note that the needed values sit inside one raw field.
3. Recognize that rules match on normalized fields.
4. Conclude that parsing/normalization was skipped.

Exam tip: If events arrive but rules never fire on their fields, check parsing and normalization.

Retention requirements often specify both a total period and an immediately available period.

PCI DSS, for example, requires at least 12 months of audit log history with the most recent three months immediately available. A tiered design satisfies both: recent data in fast, searchable storage and older data in cheaper archive storage that can be restored. Keeping everything hot works but costs more; deleting after three months or archiving everything each break one half of the requirement.

1. List both constraints: 12 months total and three months immediate.
2. Discard designs that break either constraint.
3. Compare the remaining designs on cost.
4. Choose the tiered design.

Exam tip: Meet retention with tiers: recent logs hot and searchable, older logs in cheaper restorable archive.

System hardening applies a secure configuration baseline to an operating system.

Hardening starts from a documented baseline. CIS Benchmarks give version-specific, consensus-developed settings (services, permissions, logging, authentication) and can be checked with automated tools. CVSS, ATT&CK and the OWASP Top 10 are all security frameworks a SOC uses, but for scoring, adversary behavior and web risk respectively.

1. Identify the need: a secure configuration baseline for one OS.
2. Match it to configuration guidance rather than risk scoring or threat models.
3. Choose the CIS Benchmark.

Exam tip: Hardening baseline for an OS = CIS Benchmark (or a vendor/government equivalent such as a STIG).

Critical files: the hosts file overrides DNS on a single machine.

Windows resolves names from the hosts file before querying DNS. Because other workstations using the same DNS and proxy work correctly, the fault is local to this machine, and a hosts entry mapping the bank's name to an attacker's IP is the classic cause. The services file sits in the same folder but maps ports to names; SAM and SYSTEM are registry hives with other jobs.

1. Note that only one machine is affected.
2. Rule out shared infrastructure (DNS, proxy).
3. Recall that the hosts file is consulted before DNS.
4. Inspect the hosts file first.

Exam tip: One host redirected while its neighbors are fine: check the hosts file before DNS.