Security Event Management (SEM) with CEP (Part 4) - The 5 Principles of SEM
In
Part 2 and
Part 3 of
Security Event Management (SEM) with CEP, we reviewed trends in cybersecurity and the motivation for SEM and CEP. That introduction leads us to a brief post on the high-level functional requirements of SEM.
In a nutshell, according to the literature and the marketplace, SEM functionality is based on these 5 principles:
- Log collection from heterogeneous devices - the capability to read, parse, normalize, and gather security events from a variety of heterogeneous event sources;
- Situation detection - the capacity to detect and refine threat-related situations automatically and priorities based on an automatic impact assessment, optimizing staff performance to focus on preventing the most important threats;
- Threat prevention and remediation - generate alerts and automated responses based upon high probability threat scenarios and manage the life cycle of the threat;
- Report generation - automate reports that support post-threat investigation, regulatory compliance and update visualizations and dashboards; and,
- Scalable, distributed architecture - the architecture must manage millions of logs per day, distribute the processing load, and with service-oriented services for transformation, event tracking, correlation, updates, remediation and visualizations.
These 5 functional requirements, or principles, are easy to write down in bullet format, but very difficult to achieve in practice. In fact, just about every SEM implementation in the marketplace today falls far short of realizing the stated goals of SEM. In my next post in this series,
Security Event Management (SEM) with CEP (Part 5), I will elaborate on of why the promise of SEM is elusive and unachievable by most, if not all, current SEM vendor implementations.
Copyright © 2007 by
Tim Bass, All Rights Reserved.
