Evaluating Security Information Event Management (SIEM) solutions come in a lot of different flavours. The industry is not yet mature, and the competitors are pushing their own solutions, based on their background and capabilities. In general, they will all present more or less the following configuration model for the SIEM implementation.


But other then the generic model, a lot of things are different. So, in order to sift through the multitude of solutions, the buyer needs to ask the real questions. Here are some of the key questions that need to be taken into consideration:

• Is it possible to place an agent on the server machines - Certain SIEM solutions do not properly support remote collection of OS or application logs so they need a server side agent to do the job. On the other hand, most business critical systems are tightly controlled and do not allow for additional resident programs to be installed on the system for the risk of possible performance or reliability issues
• Are there any custom applications that generate logs that needs to be collected by the SIEM? - The organization may require that the SIEM also collects and parses such logs, but proper parsing ability needs to be verified with a large sample of logs during a proof of concept run.
• Is there any international standard or regulation that is mandating the SIEM solution - whatever standard needs to be met has a set of predefined controlling reports that confirm compliance to the standard. You need to confirm that the SIEM solution can produce the needed reports.
• How long will you need to keep logs and conclusions online and offline? - data retention is key to such a massive collection of information. Typically, a SIEM system needs to be able to archive all historical events to external data storage, and preferably, the archival process should include an integrity control (MD5 or SHA1 hash) that guarantee that the logs haven't been tampered with while in archive.
• What type of processing and alerting is required?-
  

Proper answers to these questions will most likely eliminate the non-acceptable solutions, and will ease the evaluation process of the qualifying shortlist.

Talkback and comments are most welcome

Related posts
Real Benefit of Security Information Event Management

Security Information Event Management is the echoing buzzword in most industries these days. Banking, Telecommunications, Power and Energy - anyone and everyone is under internal audit and regulator scrutiny to implement a Security Information Event Management system.
But most Security Information Event Management implementations are rushed and placed only to shut up the auditors and to go on as usual. Since it's a compliance requirement, the Security Information Event Management salespeople very rarely address whether the customer makes proper use of the solution, and whether this solution brings benefits to the company.



The common issue
SIEM is a Security Officer tool, but since it tightly integrates with IT equipment, the SIEM implementation is usually left to IT departments. The issue with this is that IT will approach the implementation from a purely technical aspect: how to properly connect the IT equipment to the SIEM system.

Once the SIEM system is collecting audit logs and events from all required IT elements, the job is done. At most, a retention policy and archiving is also done by IT, and the story ends there.

The real benefit
Any SIEM system is simply a large database collecting massive amounts of events. But if one does not use these events, the system is placed there just as a form, and brings only costs to the company. Here is what you'll need to set-up to achieve benefits of a SIEM system

1. Choosing what is most important to be alerted about - While some automated alerts and analysis are available within all SIEM systems, the generic alerts are rarely well matched to a company. For example, a generic alert may be triggered by consecutive failed attempts followed by a successful logon, but may not be triggered on a configuration change of a firewall. The first event was merely an employee trying to remember his password, and the config change of the firewall just opened up your network to some attack
   
2. Alerting the proper person/team - The alerting means nothing if the alert does not arrive to the proper person to react in the fastest possible time. A 'transaction log is full' means little to a network admin just as SYN flood may mean absolutely nothing to the DBA. And both will mean not too much to the head of the department, if one chooses to send all alerts to the manager.
3. Creating and using the proper reports - Some SIEM systems come bundled with reports, other sell the reports as packages. But the vanilla flavour reports may not always be useful to the organization, so the correct report definition should be prepared and implemented during the SIEM implementation. This way the company will know that these reports are to their specification, and even more, that the data needed for this report is collected by the SIEM system.

Talkback and comments are most welcome