SIEM is not a product, its a process...
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
Reverse-Engineering Malware: Malware Analysis Tools and Techniques | Frankfurt | Dec 9th - Dec 14th 2024 |
Comments
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?
Anonymous
Nov 20th 2015
9 years ago
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
Anonymous
Nov 20th 2015
9 years ago
Anonymous
Nov 20th 2015
9 years ago
Anonymous
Nov 21st 2015
9 years ago
-Marlon.
Anonymous
Nov 23rd 2015
9 years ago