Make your SIEM Awesome!

I’ve sat in on far too many presentations lately claiming Security Information Event Management systems (SIEM ) are dead. Usually the presenter gives the spiel that it is too difficult and expensive to configure and monitor it. Then they usually go into some kind of new product that looks and sounds a lot like an ELK stack (Elastic Search, Logstash, and Kibana) with a new name.

Throw in some sentences about data lakes, machine learning,  artificial intelligence, APT, UBA, <insert buzz word here>, etc. and the presentation is over. I then rush to the nearest coffee pot and wish for my time back.

I do agree that SIEMs are not for all companies. If you do not have enough full time employees with the appropriate skills dedicated to support the system and respond to its alerts it will not serve you well. I would recommend working with an MSSP but that is another blog post.

Anyway, back to making your SIEM awesome! Once upon a time you heard from the community or your boss that you need a SIEM. You interviewed a bunch of vendors and maybe looked at some open source solutions.

Every vendor told you all you really need to do is send logs to their magical system and the SIEM’s secret sauce will do the rest of the work and you will somehow get relevant security alerts from out of the box rules. Unfortunately this is not the case.

What typically happens is organizations will send their SIEM ALL OF THE LOGS because their vendor told them to. That makes sense to an extent, the more logs you send the SIEM the more it can correlate against. However, most SIEM vendors charge by the volume of events that are being piped into the system so the more you send it, the more they can bill you.

After the organization verifies the logs are making it to the SIEM they turn on the vendor’s built in rules. This will generate a gratuitous amount of alerts. The team that is responsible for looking at these alerts quickly gets overwhelmed by the amount of alerts. They investigate a couple of them and find out its normal operations. The rules get turned off and the SIEM essentially becomes a very expensive log collector.

So how do we get useful alerts coming out of the SIEM?

The first thing that you need to do if you haven’t already is to TURN OFF all of the out of the box rules unless you have tuned them properly and they are creating actionable alerts.

Next. we need to make sure the we have the appropriate logs going into the SIEM and that they are parsed out correctly. Parsing logs will be a different post. Logs that I personally find most useful are

  • Firewall
  • DNS
  • URL Filter
  • Microsoft Windows logs (Security, System, PowerShell)
  • *Nix system
  • Antivirus Logs (host, firewall, sandboxing solutions, etc.)
  • Netflow (yes I know its not technically a log)
  • Network access control
  • VPN logs
  • Vulnerability Scanner Data
  • Any other security controls

With these log sources alone I could easily create 50+ actionable alerts within  20 working days (if that was all that I was doing of course).

Some examples alerts that you can create from these log sources include

  • Port Scanning (internal and external)
  • Possible Worm activity
  • Virus detections
  • DNS C2 traffic detected
  • DNS Data Exfil
  • Data Exfil via web protocols
  • Password Spraying detected
  • Suspicious PowerShell process launched
  • Vulnerability Scan Detected
  • IDS/IPS signature hit – Outbound
  • VPN user logged in from unexpected location
  • VPN user logged in from two different locations
  • Unauthorized Device Detected on The Network
  • Suspicious traffic on VLAN (voice, printer, SCADA, etc)
  • Proxy aware malware activity detected
  • Exploit attempt on vulnerable system
  • Public facing system found vulnerable to <this really bad exploit>
  • etc.

eventually I will create a walkthrough of how to create these use cases and more. By that I mean I will show you what fields of what logs need correlated against. There are many different types of logs and SIEMS out there so I’m not going to be able to lay out a step by step but I should be able to get you there.

So I got these alerts created and they are lighting up like a Christmas tree. How do I get these things actionable?

Once you get some alerts created they WILL NEED TUNED. There will need to be exceptions to almost every alert. Lets take the possible worm activity alert for example.

Worms will look for a vulnerable service to exploit. It will do this by scanning the environment for a particular service. So therefore a single system trying to access many computers on port 1337 looks suspicious.

However, servers that control agents may reach out to many systems at the same time. Therefore, the server communicating to its agents on a particular destination port needs to be excluded.

When making exclusions make sure you make comments in the rule and/or a spread sheet somewhere. Just like firewall rules. When it comes time to review the exceptions you will be glad you did!


In conclusion, the SIEM in still alive and you can make it awesome. They have many other useful capabilities such as automatic response to events that I simply cannot put into one post (unless that post is very long). In order to make your SIEM awesome you need to start out with

  1. Collecting relevant logs that you can generate alerts from
  2. Create alerts from those logs
  3. Tune out the non malicious events identified
  4. Respond to the alerts (investigate)
  5. Tune the rule with input from your responses
  6. Repeat steps 2-5 on a daily basis and step 1 as needed

I hope you enjoyed my post and got some useful information that you can use. Please leave me a comment and let me know what you thought!


3 Replies to “Make your SIEM Awesome!”

  1. External port scanning is unactionable. So, there is no real value. You are are connected to the Internet, you will be scanned. Fact. So, you detect a scan, big deal. What are you going to do, block the IP? Please don’t say block the IP.

    1. Hi Scvenn.

      You can pick apart almost anything and find an issue with it if you try hard enough. An example could be a information security site with an untrusted certificate :-).

      However, why would you want to allow someone to perform reconnaissance on your network? Just about every modern security tool has an API. Therefore, when a scan is detected it is trivial to block connections originating from the IP address for an hour or so.

      If the blocks and unblocks are setup to occur automatically what concerns would you have about automatically blocking connections originating from the scanning IP address?

Leave a Reply

Your email address will not be published. Required fields are marked *