A security event manager (SEM) is a programmed tool utilized on organization networks to centralize the storage and interpretation of accounting logs, or events, constructed by other software operating within the computer network.
Security Event Management Tools are a relatively recent concept, developed in 1999. The Security event management tool will make up a portion of the SIEM tool set, and is regarded as the "clever" portion of Security Information and Event Management, where as Security Information Management (SIM) tools are considered to be the dumb brother of Security Event Management Tools. SIM's tools are generally also known as Log Management tools. Log Management generally targets the collection and storage of accounting logs whilst Security event management is focused on audit logs analysis. A few vendors are experts in one sector or the other and some perform both, and have complementary products and services.
Numerous systems and programs that run on data network generate logs which are usually stored in event logs. These security logs are essentially listings of user activity that occured, with records of new audit logs being added to the end of the audit logs as they occur. Protocols, such as Syslog, SMTP and SNMP, are often used to carry these kinds of events, as they occur, to logging software which isn't on the same host where the logs are created. The better Security Event Management Tools produce a versatile variety of supported transport protocols to allow the broadest variety of log event collection.
It's good to send all accounting and audit logs to a central Security event management solution for the following reasons:
Single Loction to all network logs
The Security event management tool can provide secure, chain of custody proected storage and archival of security event logs
Powerful reporting tools could be run on the Security event management to mine the audit logs for valuable information
Audit logs could be parsed as they hit the Security event management for significance, and alerts and notifications can be instantly transmitted to your clients as needed
Correlated logs that occur on several systems could be identified which may be impossible to discover if each server had a separate log
Events that are delivered from a system to a Security event management tool remain on the Security event management whether or not the sending system fails or the security logs on it are unintentionally or maliciously deleted
In addition to storing and collecting audit logs, Security Event Management Tools distinguish itself from simpler Log Management tools by providing a deeper degree of log event analysis. This tends to include attaching contextual info, such as host info (Risk, owner, location, and so forth.), identity info (end user information relevant to accounts referenced in the log event like user name, workforce ID, supervisor identify, etc.). This contextual information can be leveraged to produce superior correlation and reporting functionality.
SEMs might also incorporate with outside remediation ticketing, and work-flow applications to help with the process of breach resolution. Better SEMs will provide a flexible, extensible set of integration capabilities to make certain the SEM will work with most customer environments.
As Security event management deployments proceed beyond collecting infrastructural audit events from hubs, switches, servers, firewalls, and so forth, the ability to properly monitor business software programs will become essential. Since the majority of software programs - specifically those developed internally or by outside software programmers - do not include thorough logging it has become difficult to include this critical data into SEM products.
SEMs in many cases are marketed to help fulfill U.S. regulatory requirements including SOX's, ISO27001 or PCI-DSS.
One of the main challenges within the SEM arena is definitely the difficulties in consistently assessing security event data. Every vendor, and even quite often unique products by one particular vendor, utilizes a different proprietary event data format and distribution procedure. Even in cases where a "standard" is employed for many part of the chain, like Syslog, the standards do not typically contain enough instruction to aid developers in the best way to generate events, administrators in the best way to collect all of them appropriately and reliably, and consumers to examine them successfully.
No comments:
Post a Comment