SIEM and SOAR

In late November 2013, the FireEye detection tool Target had deployed flagged the malware skimming its store payment terminals. The monitoring team in Bangalore escalated to Minneapolis, where nobody acted. The result: 40 million payment cards and data on 70 million customers. The case is still the standard reminder that an alert nobody works protects nothing. A SIEM (Security Information and Event Management) collects, normalizes and correlates logs from the whole estate in real time: servers, endpoints, network gear, applications, directory, cloud. It raises alerts from correlation rules and behavioral models, which SOC analysts then triage. SOAR (Security Orchestration, Automation and Response) automates part of what follows through playbooks: context enrichment, endpoint isolation, account lockout, team notification. Both aim at MTTD and MTTR, mean time to detect and to respond, which drive the size of a loss. A badly tuned SIEM mostly produces noise, thousands of false positives a day with the real alert buried in them. For an underwriter, a SIEM: yes box on the application says little. What counts is which sources feed it (Active Directory and EDR first), how long logs are retained, who watches the console at night, and whether isolation playbooks run without waiting for human sign-off.