The Top Ten Criteria for a Security Information and Event Management (SIEM) Tool

The Top Five Security Information Management Considerations

1. Ensure your log management layer is scalable. The log management layer is responsible for collecting the hoards of audit logs within your environment; it is not likely to filter any collected data. A key requirement for a Security Information Management (SIM) tool is to collect all audit log data so that a forensic investigation can be instigated if required. This layer therefore needs to scale to ensure full log collection.

2. Comprehensive Reporting. The log management layer should be able to report on activity that have been collected and identified within the accounting and audit logs. This should include running reports across up to 90 days of data. When you are collecting 10-20 million logs a day, this means the report will need to search upwards of 2 billion entries to retrieve the requested data for the report. It is also possible that you will run several reports a day.

3. Log Collection. It is important that you can collect logs from across the enterprise. The SIM layer should be a true forensic store of accounting and audit logs that allows a complete investigation, should the need arise. This means you want logs from firewalls, operating systems, applications, VPN's, Wireless Access Points etc. You therefore need to ensure that logs from all of these sources can be collected. Plain text logs stored in flat files are typically widely collected, as are Windows Event Logs. Event logs stored database's are not easily collected, so if you have any custom built or internal built applications ensure that these logs can be collected, as often these are stored in some type of database.

4. Chain of Custody. Ensure that you can validate that the logs have not been changed or modified, since they were collected from the source device. This should include collection of the logs in real-time from the original device, to ensure they are not modified before collection. This will allow for a forensically assured investigation, if required.

5. Trend Dashboards. It is important to be able see the trend of the volume of logs being collected. When collecting millions of logs a day, dash-boarding all of that data becomes pointless, as it will be a sea of information. However the size of the haystacks can tell you if there are problems. For example if you see a huge spike in failed logins, this tells you that there is something going on within the environment that is not normal.

The Top Five Security Event Management Considerations

1. Correlation. The main purpose of a SEM tool is to filter out the noise from the forensic data and flag up or alert up any suspect behaviour. It is critical therefore that your SEM can filter the rubbish down to useful information via complex correlation rules.

It is almost useless to alert on every failed login within your environment, as in large enterprises there are hundreds or thousands of these per day. However 100 failed logins within a five minute span, from an external IP address, for an administrative account should be alerted on and investigated. Your correlation engine should support easy creation of these multiple event rules.

2. Dashboards. Once you have generated a correlated alert, you want to place this information on a dashboard for easy user consumption. While it is not feasible to dashboard the forensic data that the SIM has collected, because of the sheer volume, it is recommended to dashboard the SEM alerts, as they are likely to be significantly less in number. On average you should be alerting on less than 1% of 1% of the collected logs that equates to a maximum of 200 alerts from 2 million collected audit logs. With a really strong correlation engine we would expect to eventually tune these alerts down to 2 a day, instead of 200 a day. You only want to be alerted on TRUE security or operational risks to your enterprise, not every time someone fat fingers their password.

3. Reporting. While reporting capability is critical for SIM, it is also important for SEM. The reports are not going to be as difficult to produce, for starters you are not reporting against billions of logs, more likely you are reporting against tens of thousands of alerts. But management will want to see that critical alerts have been responded to and resolved.

4. Log Normalisation. To create detailed alerts you will need to "understand" the raw logs, for example you will need to understand what part of the log string is the group name, if for example you want to alert when a user is added to an administrator group. Most vendors will create normalisation rules for the standard off the shelf applications, but you should be able to normalise your organisations custom log formats, without having to employ the vendors, likely to be expensive, professional service consultants.

5. Alert Management. As well as creating complex alerts based on correlation rules it should be possible to track the status of generated alerts. Has the Alert been resolved? What steps were taken after the alert was raised. A built in ticketing system or tight integration in to an existing ticketing system is a critical feature of a Security Event Management tool.