Via Anton Chuvakin - Eric Ogren says Let's Archive the SEM Market:
I have always regarded Security Event Management (SEM) as the most dysfunctional segment in the security industry. SEM vendors would always preach rapid response and attack prevention, even though they only examine log file entries written long after the attack has come and gone. Then they tried to promote being the independent command and control center, but of course they cannot control other vendor's products as effectively as the vendors themselves can...It has just been a brain-dead market segment.
...
SEM can be a good place to collect, filter, and manage audit logs of corporate activity. You wouldn't think of running your business without independent corporate auditing, you shouldn't think of running IT without auditing. Yes, the me-too marketers will trumpet compliance as the compelling reason to buy their product. They will be better served by thinking of themselves as IT auditing systems, of which security is just a component. This means the vendors should also be looking to collect and correlate events from business process sources such as application servers, web servers, and authentication systems. This adds data management, search, and reporting of active event archives to the real-time data collection capability. The intelligence gained would be appropriate for the C-suite. Yes, compliance is a benefit, but it is not the reason for SEM to exist.Ducks do not fly well, swim well, or walk well, but there's a place in the world for ducks. The Security Information Management (SIM) space has needed redefinition for years. It would be nice if SEM can show how security integrates with and enables open business processes. Then perhaps there can be a true SEM acquisition binge.
The way that the data is defined, collected, and managed has direct bearing on its analytic utility for security purposes. As with everything in the frequently abstract space of security definitions help companies make good decisions on where and how to invest in security tools. Survey of some key questions to look at:
Data sources
What are the data sources to be integrated?
What are the types and values of the data sources to be integratd?
What unique identifiers and keys (if any) for mapping data across sources are available?
What is the type of integration: is it a feed or is it queried?
For feeds -What is the timing of the feeds: real time stream or bulk loaded? How often are loads done?
How are errors handled either in feeds or data quality?
How is the data cleansed?
Analytics and Reporting
Who are the stakeholders for the analytics and reports?
What type of context is layered around the data? Will multiple types of technologies be included, e.g. syslog, firewall logs, and app logs?
Are the analytics intended to used for auditing, forecasting, dashboards, vertical analysis, or real time response? Many times these tools are sold to customers as having answers in all of these spaces, but the reality is that the way information is collected and managed (with the context that is built around it) means that choosing one may clash with goals of the other.
What are the goals and capabilties around combining data sources for analytics for drill down and drill across scenarios?
**
As Eric Ogren's post implies there is value in different ways of approaching this: there is value in audit and assurance data, there is value in real time analytics (for example for fraud detection), and so on; but there is not one magic report that serves all these needs. Especially, because the different types of analytics and reporting format's value is predicated on simplifying and filtering data for its own purposes. Stakeholder goal and definition will lead to the right choice of tools, formats, and scope.
Great comments! I plan to blog more on this one, but for now:
it seems more like there is not even one magic PRODUCT that serves all these needs rather than "one magic report that serves all these needs"
Posted by: Anton Chuvakin | April 26, 2006 at 07:59 PM