Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
flypjo Trusted Contributor.
Trusted Contributor.

Which logs to consider for SIEM?

Hello All,

Has there been any discussion here on Protect, as to what types should be forwarded from various sources?

For example, even if the source device is set for a particular logging level, what should be filtered out considering from a security/threat perspective.

Another example, I may not want the 'SELECT' statements from a monitored database but focus only on deletion/update statements.

Are there some sort of rough standards?








Unix server (os level? application level?)

Windows Event log (security/application/system)

This has to be from a primarily security standpoint.


Tags (3)
2 Replies
pbrettle Acclaimed Contributor.
Acclaimed Contributor.

Re: Which logs to consider for SIEM?

Ok, so this is a really complex subject and I will do my best to keep it simple as its nearly the end of the day and then the holidays here in the US! But there are a lot of points to get across and cover though.

Firstly, think about how you approach this and what you are trying to do. I have always been a proponent of the top down approach in these areas though. Taking the bottom up approach is usually a good way to get this wrong, not always, but it doesnt help. What do I mean?

Think of it this way - your chances of detection (and thats ultimately what we are trying to do here) are better when you try to understand what the threats and risks are and then trying to map that out with the log sources to build the picture out from there. That way you can actually understand things and address the risks. Usually, I would recommend the generic sets of data though:

1) Who - try and understand who the person is - think VPN, Windows Login, application login data

2) What - what are they trying to do - think Active Directory, authorization logs, application logs etc

3) Where - how are they using the network - think router, VPN, access, firewall or proxy data

4) How - are there any security techniques - think threat intel, IPS / IDS or other security system - how did we spot you?

If you can get these generic types of logs, you can start to build a picture of who did what, where and how did we detect them. If we get that, we can start to map out security use cases and address threats.

If you do it a bottom up approach, such as looking at the log sources and then trying to figure out what you can do, you reduce your chances of spotting things and detecting attacks. It might sound dramatic here, but if you dont get a complete picture of what is going on, you can't understand what is actually happening! While it is possible to try and work out what the use cases given a limited set of log sources, its also very limiting. You can try and understand things, but if you can't piece together the picture, you run the risk of missing attackers.

So how to solve this? Well this is the good news though. I would really recommend taking a close look at the Activate Framework. See these links:



And content here:


Activate is a lot of things to different people, but what it does provide is a set of content and a framework to work with. That means that it will provide the following:

1) A base set of content (called Foundation packages) that address specific log sources - not only just starting to build that picture, but actually document WHAT configuration you need for each log source and how to configure it - so which logs will be needed from which log source to actually do something.

2) A set of content that works together - the foundational content actually interacts together to build that picture up - so use the L1 packages together to build the indicators to feed into the L2 packages and add value and meaning! Then, if you can, take it to the next level with the L3 packages and content! Of course, you can customize all of this too!

So what am I recommending? I am saying that looking at log sources and attempting to build it up could work, but its not guaranteed. The best approach is to go top down, use Activate and start to address use cases this way. I get that this isnt always an option and in some cases, you just can't get the really useful data form the really good log sources due to politics, operational restrictions or just simply because you can't make it happen. Thats fine, but this is security and you can't compromise. I often hear of phrases like 'good enough' or 'cant do that'. Thats fine, but be aware that we wouldnt want to hear that from our bank, credit card provider or government - think of what the outcry would be if your bank didnt do any reasonable security to prevent access to your account and when you dug into it, it was all down to the fact that they couldnt be bothered, thought it was good enough and didnt put enough effort into it. This stuff is important and we can't skimp on it....

Sorry, I will get off my orange box now, but I hope it makes sense and gives you some ideas of where to go. And please, as appealing as it might seem, dont go for the easy route, go for the one that adds value.

Gayan Acclaimed Contributor.
Acclaimed Contributor.

Re: Which logs to consider for SIEM?

Hi Vidisha,

First stage is you need to identify “Requirements”. It can be any of the following high level requirements and is unique to your organization

Business / Compliance/ Regulatory / Security.

Based on that you can decide which log should goes to SIEM. On the other-hand based on standards you can select end devices that needed to be logged.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.