My next class:
Reverse-Engineering Malware: Advanced Code AnalysisOnline | Greenwich Mean TimeOct 28th - Nov 1st 2024

SIEM is not a product, its a process...

Published: 2015-11-20. Last Updated: 2015-11-20 11:19:22 UTC
by Xavier Mertens (Version: 1)
5 comment(s)

This famous Bruce’s quote is so true that we can re-use it to focus on specific topics like SIEM (“Security Information and Event Management”). Many organizations already deployed solutions to process their logs and to generate (useful - I hope) alerts. The market is full of solutions that can perform more or less a good job. But the ROI of your tool will be directly related to the processes that you implement next to the hardware and software components. I’ll give you two examples.

The first one is the implementation of a mandatory strong change management procedure. Recently, I faced this story at a customer. I call this the “green status” effect: If the security monitoring tool does not report alerts and and you assume that everything seems running fine, you'll fail! Because your SIEM quality is directly depending on the quality of the data send to it. Within the customer infrastructure, some critical devices were moved to a new VLAN (new IP addresses assigned to them) but the configuration of the collector was not changed to reflect this important change. Events being sent to a rsyslog instance and split based on the source IP address, the new events were not properly collected. They lost many alerts!

The second example focus on assets management. Many SIEM vendors propose compliancy packages (PCI, HIPAAS, SOX - name your favorite one). The marketing message behind those packages is “be compliant out of the box”. Really? Have a look at the following correlation rule extracted from a PCI compliancy package from a well-known SIEM solution (translated in human readable format):

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

Based on this rule, we must:

  • Define trusted hosts
  • Define “cardholder” hosts
  • Define the list of allowed ports
  • Categorize the VPN, SIEM devices

This means that to make this rule effective, there is a huge classification job to perform to fill the SIEM with relevant data (again!). Deploying a SIEM is not just a one shot process. You’ve to carefully implement procedures!

  • New devices must be provisioned in the SIEM configuration
  • Changes must be reflected in the SIEM configuration. 
  • Implement controls to detect unusual behavior (waiting for alerts is not enough)

Happy logging!

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

Keywords:
5 comment(s)
My next class:
Reverse-Engineering Malware: Advanced Code AnalysisOnline | Greenwich Mean TimeOct 28th - Nov 1st 2024

Comments

Great post Xavier! The timing of this post can't be better for us, as we're currently shopping for a SIEM solution.
How valuable is for a SIEM solution to be able to capture & use network traffic, in addition to the logs, in order to increase the intelligence & improving the alerts?
Same question on the value of the threat intelligence; adding it to the SIEM mix to make alerts more relevant.
If you had to pick one of those additional capabilities, which one would you pick?
FPC is always nice. If it's too hard (usually just for storage reasons), go at least for netflow! It's a real value to know who talked to who.
DNS traffic is a key element too. I'd suggest to start the implementation with use cases. Ask yourself "what could make me happy?" or "what could solve my daily job?" and focus on those alerts/reports. Of course, added some threat intelligence is also a big plus.

/x
There are some good solutions out there for FPC. Wildpackets (now Savvius) came out with Vigil earlier this year that allows for long term capture of packets related to IDS/IPS events. Found that to be very helpful in regards to conserving storage space by keeping only relevant packets.
We are sliding out of the SIEM topic but have a look at Moloch (http://molo.ch) for free and scalable FPC solution...
I am *SICK* of SIEM vendors which advertise their products as miraculous! Good post, we need more of these to open our dumb managements' eyes.
-Marlon.

Diary Archives