“Out of the Box” SIEM? Never…

A reflexion about the multiple SIEM (“Security Information and Event Management“) products available on the market… I’m currently working with a customer on a big SIEM implementation in an environment that must be PCI compliant and integrates a multitude of devices coming from non-heterogenous security vendors (big-players). Security visualization being one of my favorite topics, people often ask me what the “best-SIEM-solution-ever” or I’m contacted by vendors who announce new products with new features more and more performant and easy to use. A classic argument used by niche players ((c) Garner ;-)) is  the extreme complexity of their competitors. They claim to have an “out-of-the-box” solution: No need to write complex rules, reports are available through a click & run interface, etc. Really?

Let me demonstrate that a good SIEM must be one deployed for your devices and applications by you and for your  business! Most SIEM vendors propose useful “compliance” packages. You must be [PCI|SOX|HIPAA|ISOxxxxx] compliant ? There is a corresponding (and expensive) package which includes all the required stuff to generated reports “just by pressing a button“. Have a look at the screenshot below:

This is a query coming from a PCI compliance package installed in a well-known SIEM environment. This query is part of the PCI requirement #1 – Firewall Configuration – and should return disallowed traffic from DMZ to untrusted hosts (example: a server in the DMZ trying to connect directly to the Internet). Translated in full English, the query select events:

• IF the target is not :
  • known as a regular destination from the DMZ
  • OR known as a trusted target
  • OR known as a “cardholder” target
• AND IF the destination port is not known as allowed (via an Active List)
• AND IF the traffic is not coming from a VPN device
• AND IF the traffic is not coming from a SIEM device
• AND IF the source is flagged as an attacker from the DMZ

Don’t take too much time to understand the rule syntax, it’s not the goal here. The problem that we detected was the following: the report generated too much noise. There was a lot of false positives like:

Source (DMZ)    Target      Destination Port
192.168.x.x       x.x.x.x     123

This event is a DMZ host (192.168.x.x) trying to communicate with a NTP server (x.x.x.x). Based on the query describe above, a solution could be to tag the NTP server IP address as “trusted” but we don’t control the IP addresses behind the FQDN and the same IP address could be the destination of other communications.  Another solution could be to add the NTP port (123) into the list of trusted ports in the DMZ. This is not a solution: By trusting the port, it could be used by another server for other communications and not be listed in the PCI report.

Our solution was to replace the active list containing the trusted ports by a new one with two fields: the DMZ source and the destination port. This way, we can define precisely who is allowed to use which protocol.

Another example: some PCI reports returned no results at all while we knew that some events were generated! In this case the problem was located at the events normalization level. The reports used the field “Attacker Asset ID” but this field was not used by some collectors. Only “Device Asset ID” was available. Solution? Again we had to change the queries and look for “Attacker Asset ID” OR “Device Asset ID“.

Those are two good examples to prove that there is NO SIEM solution that could be implementd out-of-the-box! Don’t trust vendors. Choose the solution that will match most of your requirements but expect to take time to deploy it!