SIEM: The good and the bad - Part I

I work in the computer security industry and one of my specialities is integrating and deploying security products. I have deployed on several occasions and in large environments; proxies, anti-virus, firewalls, SSL VPN, intrusion detection systems, anti-spam and finally Security Information and Event Management (SIEM). The company which I currently work for happens to be the biggest value added reseller in Canada dedicated in IT security and I have noticed an increase interest towards SIEM technology this year. I believe it will be a very popular product for the mid to large enterprise especially in the retailer and heath care market. I believe SIEM's will be as comme as firewalls within 5 years. The usual deal can range from 60k to 1+mil and the driving factors are mostly PCI compliancy and getting hacked - no kidding. So I have decided to write a few posts on the subject.

What is a SIEM:

A SIEM is a software that takes in any type of log over various channels. 95% of the time the channel is the Syslog protocol. Once we are able to gather logs from various sources, we are able to provide automated alerts based on correlation rules. A correlation rule could be; fire brute force attempt alert if you detect 100 failed logins within 5 minutes from the same source IP to any of my sources. Log sources can be any device that can send syslog or generate some kind of log locally which we can acquire via an agent or simply sftp/scp. For example, I have gathered the following logs from various vendors during my deployments.

• Windows servers
• *nix servers
• Database servers (Oracle, DB2 MSSQL)
• Custom applications
• Web Server (Apache, IIS)
• IDP/IPS (Cisco IPS/Intrushield/Snort)
• Ciscoworks/ACS/IOS
• Firewalls (ASA, Checkpoint, iptables)

How does it work:

1. An event comes in the SIEM solution via a channel such as Syslog
2. An internal parser is used to understand and extract the information from the logs such as the IP addresses, usernames etc.
3. The event is than normalized - so instead of being a windows event signalling a failed authentication it is simply referred to as failed authentication within the system. So if we also get a failed authentication on a Unix log, it will also be normalized as failed authentication. The normalization process is what allows the system to correlate events between different products.
4. Once the event is normalized it goes through the correlation rule engine and the correlation engine fires up an alert if it detects a pattern.

Obviously this is a very high level overview of the process but it should give you a good understanding of how correlation is made possible through normalization.

Stay tuned for part II where I will cover the usefulness of correlating flows with events.

Phil