This post explains how to configure a Security Information and Event Management (SIEM) solution to meet Essential Cybersecurity Controls (ECC – 2 : 2024) Control 2-12-2 for the Compliance Framework by covering which event logs to collect, how to implement actionable alerting and correlation rules, and practical tuning and retention strategies that small businesses can deploy quickly and maintain over time.
Key objectives and Compliance Framework mapping
Control 2-12-2 requires that organizations centralize relevant event logs, generate timely alerts for suspicious activity, and tune detection capabilities so alerts are meaningful and actionable. Your SIEM configuration should therefore satisfy three key objectives: (1) comprehensive log collection and integrity preservation for investigators and audit purposes; (2) detection and alerting workflows that align with organizational risk appetite and incident response procedures; and (3) regular tuning and validation so the system continues to detect relevant threats while minimizing false positives. These align directly with Compliance Framework expectations for evidence, auditable rules, and documented tuning cycles.
Essential event logs to collect
Log sources and specifics you must include
Collect high-fidelity logs from the following minimum set: Windows Security and Sysmon events (Account Logon, Account Management, Process Creation (Sysmon), Lateral Movement indicators); Linux syslog and auditd (authentication, sudo, cron, SELinux/AppArmor denials); perimeter firewall/NGFW logs (session start/stop, allowed/denied flows, NAT translations); VPN concentrator and remote access logs; cloud provider audit logs (Azure AD sign-ins, AWS CloudTrail, GCP Audit Logs); identity provider and SSO events (user creation, group changes, MFA failures); EDR telemetry for endpoint process/behavior events; and critical application audit logs (databases, file servers, email servers). For each source capture timestamps in UTC, the original event ID/type, user and host identifiers, source/destination IPs, and raw event payload for forensic needs.
Technical implementation steps
Design a collection architecture that separates collectors from indexing/analysis nodes. Use Windows Event Forwarding (WEF) or agents (e.g., Splunk UF, Elastic Beats, NXLog) for Windows hosts; configure WEF subscriptions with HTTPS/WinRM (port 5986) and set source computers to forward only Security+Sysmon channels to reduce noise. For network and appliances, forward syslog over TLS (RFC 5425) to protect logs in transit (common destination port 6514). For cloud services, use API connectors (e.g., Azure Monitor diagnostic settings -> Event Hub -> SIEM ingestion) or native SIEM cloud collectors. Normalize events at ingestion (map to common schema: timestamp, host, user, event_type, action, outcome, source_ip, dest_ip, process, file_path) and ensure consistent time synchronization (NTP/Chrony) across sources. Enable log integrity controls: write-once storage for raw events where possible, and compute SHA-256 checksums of ingested batches for chain-of-custody verification.
Storage, retention, and sizing
Define retention aligned with Compliance Framework guidance and organizational policy—commonly 90 days of hot/online search and 1 year of cold/archived logs for SMEs unless regulation requires more. Estimate storage using a simple formula: daily_bytes = Σ (events_per_source * average_event_size_bytes); monthly_capacity = daily_bytes * 30 * retention_factor. For a small business example: 50 Windows endpoints producing ~5,000 events/day at an average 800 bytes/event = 200 MB/day from endpoints; add 1 GB/day for servers, 200 MB/day for firewall and VPN logs = ~1.4 GB/day or ~42 GB/month. Size index replicas and hot/warm nodes so searches under retention windows complete within SLAs; plan retention tiering (hot for 90 days, cold compressed for 1 year) to control costs.
Correlation rules and alerting examples
Create a layered alerting strategy: priority high-confidence rules (low false-positive) that trigger immediate paging; medium-confidence rules that open tickets for analyst review; and low-confidence anomalies that feed into periodic hunting. Example rules: (A) "Multiple-source brute force": >5 failed interactive logons for the same account across ≥3 hosts within 10 minutes → high-priority alert; (B) "Privileged group change": user added to Domain Admins → immediate page + session snapshot; (C) "Unusual data exfil": outbound transfer >100 MB to an external IP never seen before in 24 hours → medium alert; (D) "Process injection from lsass.exe": process spawn events indicating credential dumping → high alert. For each rule define correlation window, suppression settings (suppress repeated identical alerts for N minutes), and an explicit runbook with triage steps, MITRE ATT&CK mapping, and evidence collection commands (e.g., live host memory snapshot or EDR query strings).
Tuning, monitoring, and operational best practices
Tune on a cadence: initial heavy tuning during the first 30–90 days, then monthly review for medium/high-volume rules and quarterly reviews for lower-volume detections. Use baselining to create dynamic thresholds—compute typical daily login volume per user and set anomalies relative to the baseline rather than fixed absolute thresholds where possible. Monitor SIEM health metrics: ingestion rate (events/sec), indexing latency, queue depths, and disk utilization; alert on ingestion drops and prolonged backlogs. Maintain change control: document rule creation and tuning in a versioned repository, and require business-approved justification for enabling noisy rules. Integrate threat intelligence feeds to enrich alerts (IP/domain reputation) and correlate IOC hits with internal telemetry.
Small-business scenario: step-by-step implementation
Example plan for a 50-user small business with Azure AD and 3 on-prem servers: 1) Inventory logs and owners (inventory spreadsheet mapping host -> log types -> owner). 2) Deploy collectors: enable Azure AD & Office365 audit logging into Event Hub, deploy one lightweight agent (Filebeat/NXLog) on servers and a WEF subscription for endpoints. 3) Configure firewall and VPN to forward syslog via TLS. 4) Ingest to SIEM with parsers for Windows event IDs, Sysmon fields, CloudTrail/Azure fields. 5) Implement a small set of 8–12 prioritized correlation rules (failed login clusters, admin group modification, large outbound transfers). 6) Configure email/ticket/SMS escalation integrating with a helpdesk (Jira/Ticketing) and set initial suppression windows. 7) Run a 30-day tuning sprint logging false-positive candidates, adjusting thresholds and removing noisy sources. 8) Document artifacts for auditors: log source inventory, retention policy, enabled rules, runbooks, and tuning records.
Risks of not implementing and compliance tips
Failing to centralize logs, alert, and tune detection creates several risks: longer detection and containment times, missing evidence required for investigations, noisy alerting that leads to alert fatigue and missed incidents, and ultimately failure to demonstrate compliance during audits. Compliance tips: map each rule to a specific Control 2-12-2 requirement and attach a short justification; keep an auditable change log of rule lifecycle activities; encrypt log transport and restrict access to raw logs; and run quarterly tabletop exercises using historical alerts and simulated incidents to validate detection and response playbooks.
Summary: To meet ECC Control 2-12-2 you must centralize and protect relevant logs, implement prioritized correlation rules with clear runbooks, and maintain an ongoing tuning program. For small businesses the most efficient path is an inventory-driven deployment using WEF/agents and cloud connectors, an initial focused rule set for high-risk use cases, retention sizing with tiered storage, and documented tuning reviews—this produces measurable detections, defensible audit evidence, and a sustainable operations model that aligns with the Compliance Framework.
