3 ms·
We're talking about slightly different things: you're thinking cloud vs. on-prem, while I mean no longer giving SIEM vendors a free pass for crappy parsing & cl
by lmeyerov 6y ago
We're talking about slightly different things: you're thinking cloud vs. on-prem, while I mean no longer giving SIEM vendors a free pass for crappy parsing & classification of most data and pushing that to users. Running the SIEM via a managed cloud happens to make this easier, but not actually 100% required (e.g., federated learning.)
Historically, Splunk, Elastic, and other SIEM vendors abdicated most responsibilities here despite marketing that suggest they're good at ingest/parsing/correlation across different products ("single pane of glass"). Requiring IT/security teams to do parsing + classification across an ever-changing stack of client/server apps + security tools is a lot of work given the ever-increasing list of other responsibilities they have, and a gross duplication of effort across organizations. The result has meant a lot of incompletely configured systems, a big blocker on most data & automation efforts ("garbage in / garbage out"), and burning internal team time + professional service dollars on week 1 stuff. In contrast, not so hard for a vendor to amortize parsing across all its users. (Which Microsoft and Google are pushing towards, afaict.)
And agreed, teams should be able to iterate on the interesting stuff, not reinventing the wheel on parsing winlogs/apache/netflow/zeek/palo alto/etc and normalizing them to the taxonomy of the year. To the original point about ATT&CK, teams should be training & labeling & sharing models, while ATT&CK is informal ideas (very 1970s/1980s) and manual SIGMA rules (very 1990s/2000s), yet we know that is unreliable and too much work to maintain & grow. They need to be able to quickly work w/ feature engineering teams, not work in ignorance of them nor in isolation.