2.2.2. Windows Security Events via AMA and Windows Event Forwarding

💡 First Principle: Windows writes security events to a local log on every machine. You can either reach into each machine with an agent (AMA collects locally and ships to the workspace) or first gather events onto a central collector with Windows' own forwarding (WEF) and ship from there. Both work; they trade agent footprint against central infrastructure, and they land in different tables.

Windows Security Events via AMA installs AMA on each target machine and uses a DCR to define what to collect. The connector offers predefined event sets:

• All security events collects everything in the Security log (highest cost, highest fidelity).
• Common collects a curated set suited to audit trails and most detections.
• Minimal collects a small set focused on high-value events (for example, successful and failed logons and process creation) for cost-sensitive deployments.
• Custom uses XPath queries to collect exactly the event IDs and channels you specify, which is how you add non-Security channels or filter tightly.

A DCR scopes both which machines (its associated resources) and which events. You can create several DCRs, for example a richer event set for domain controllers and a minimal one for member servers, and associate each with the right machines. Events land in the SecurityEvent table.

Windows Event Forwarding (WEF) is built into Windows. Source machines push selected events, defined by subscriptions usually distributed through Group Policy, to a Windows Event Collector (WEC) server, where they accumulate in the ForwardedEvents channel. You then install AMA only on the collector and use the Windows Forwarded Events connector, which ingests into the WindowsEvent table.

Choose by constraints. Per-host AMA gives each machine independent, DCR-filtered collection and suits servers you already manage through Azure or Arc. WEF suits large fleets where installing and maintaining an agent everywhere isn't acceptable, or where an existing WEF infrastructure already centralizes events; the trade is a collector that must be sized and kept highly available, and a subscription design that controls what's forwarded.

⚠️ Exam Trap: WEF data does not land in SecurityEvent. A query or analytics rule written against SecurityEvent won't see events that arrived through the Windows Forwarded Events connector; those are in WindowsEvent. Match the table to the ingestion path.

Reflection Question: A company has 20,000 workstations, a strict "no new agents" policy for endpoints, and a mature WEF deployment. Which connector fits, which table will analysts query, and what new single point of failure must the design account for?