To SIEM or not to SIEM

In my last article I was arguing for more focus on detection and response instead of a single focus on prevention.

One of the best tools in our detection catalogue is the SIEM. I believe that the SIEM industry has matured quite a lot during the last decade and so have the partners working with SIEM. We have learned a lot and this article will focus on how you get true value from a SIEM investment.

The definition of a SIEM can be found on Wikipedia:

In the field of computer security, security information and event management (SIEM), software products and services combine security information management (SIM) and security event management (SEM). They provide real-time analysis of security alerts generated by applications and network hardware.

 

When it comes to SIEM implementations we have the following tips on getting the best value from your SIEM.

We also know that there is a lot of different SIEM vendors each with different features and add-ons, but the following is more generic.

1) Purpose of the SIEM

2) Choose your log sources carefully

3) Finetune the SIEM regularly

4) Setup dashboards and reports to your needs

5) Ensure you have the right hardware for your demands.

Purpose of the SIEM

I know that some organizations are implementing SIEMs due to a regulatory or compliance requirement, but most organizations are implementing a SIEM because they would like to improve their detection capabilities.

If you only need a SIEM due to compliance issues, then stop reading further just power it up and set a check mark in the box. No kidding aside I think that it is very important that you make up your mind on the purpose of the SIEM.

The SIEM can help you on detecting incidents in your environment but it can also help you with creating management reports. So consider wisely what the real purpose of the SIEM is. Why do you need it and then look for the vendor that supports your requirement best.

You should also ensure that you have enough staff resources to support your SIEM. If you are serious about detection and response you need to allocate the right resources. From my experience it requires a lot of resources and it is often not prioritised. The SIEM staff is often part of the normal IT operations so when a important operational event happens SIEM resources are allocated to normal IT operations and before you know you are left with no resources to operating the SIEM.

Choose your log sources carefully

Don’t just take all the logs from your infrastructure environment and throw it at the SIEM. You will drown in information, pay a fortune in storage and perhaps also a fortune in licenses for those SIEMs that have a license that depends on size of EPS or storage.

Instead find out if you need a log repository for the normal operation of infrastructure – send that to a syslog server, and then send specific logs to the SIEM. Yes that is right create two different environments – one for the normal day-to-day operation of the infrastructure and one for the security information and events.

The security environment should only receive very specific logs – eg. You might not send debug logs from your firewall but instead send logs on a different level. Especially your firewall log mode is important to determine and investigate. We have seen SIEMs that drowned in unnecessary firewall logs.

The following log sources should be included in your SIEM:

  • NGFW
  • NGIPS
  • Network traffic analytics such as Cisco Stealthwatch
  • EDR
  • Anti-virus, if that is not included in EDR
  • DNS and DHCP logs
  • Selected active directory records
  • Critical servers

Finetune the SIEM

When all the logs are flooding to the SIEM it is very important that you investigate the logs and adjust the log levels and discard non-important records. This is quite a task and, in my opinion, also one of the most overlooked activities in setting up a SIEM. It is omitted because the SIEM administrator either don’t have experience enough with the log sources and therefore prefers to keep the log in case it might be needed later or because the SIEM administrator just don’t have the time to perform this task. And yes, it can be a complicated task.

The finetuning should be done regularly – not every day but once a week or at least once a month. It is SIEM hygiene.

Also you need to train your staff so they need to identify and handle incidents. This is more generic for incident and response but if you need a SIEM to improve the detection and response capabilities in your organisation then you also need to ensure that the staff knows how to do this.

Dashboards and reports

Out of the box most SIEMs have different dashboards and reports but in our experience, you need to adjust these to your needs. It is not every organization that has a need for a PCI report. So, find out what your requirements are right now. Is it management reporting and/or a dashboard that shows incidents and events?

Hardware dimensioning

If you invest in SIEM you also need to ensure that the hardware supporting the SIEM is sufficiently spec’ed. Hardware requirements are normally specified by the vendor but it is our experience that you always need to put extra resources on top of that. If you need to be successful with the SIEM implementation you will like to have enough storage, IO, RAM and CPU.

It is my hope that these tips can assist you in your plans for installing and choosing a SIEM system.