Best Practice: Recommended Parsers for Windows and Linux Devices in FortiSIEM

Hi ​@Wesley Gama,

Thanks for sharing your point of view here!

In “FortiSIEM-speech”, I am a little bit confused about how you speak about “Parsers” here.

In FSM, the system gets logs (or other types of outputs) from its sources, then uses a parser to create an “Event” which then consumes space and counts towards Events Per Second (EPS).

For choosing the correct parser, FSM only needs a short part of the parser; in general it uses defined RegEx-patterns against the full log and the first parser it matches, will be the one used. If there is no match, the log will be converted to an “unknown event”.

That means:

• Talking about computing resources: You can optimize the “speed” by sorting the parsers in an order where you match as fast as possible. Obviously, most pain for computing is getting “unknown events” as every log will be checked against every parser without a match.
• Talking about EPS: Every log ingested in FSM will be an event and therefore consume EPS. Disabling a parser will not change that. To reduce EPS, you need to pre-filter the logs (Admin → Settings). The idea of filters, however, is based on already parsed events. So, here, as well, you will like to have all parsers enabled and try to prevent unknown events.

So, in general, disabling parsers would not be my first choice. I would recommend pre-filtering the logs and probably changing the order (although this might not improve a lot).

Getting back to the questions you had here:

• We usually define what to collect via Agent Templates, as we usually use Windows/Linux Agents on platforms where we like to get system information (on some systems, e.g. firewalls, you only need application logs, not system logs, so we'd not deploy an Agent).
• There is no “one fits all” solution here.
  • E.g.: In most of our customer scenarios, we have an internal segmentation firewall firewall that does DNS filtering. The firewall has information about various things like the user and only logs, if this is something we defined to be monitored or blocked. These logs have much more value than the Windows DNS logs, so we'd disable them on the Windows Agent
  • For a Domain Controller, we usually collect every Security Event we can get and also add sysmon
  • For clients, we usually rely on the information we get from the EDR, as every individual user action generates a hell of logs no one will ever be able to look at
  • For every other system, we define the main purpose and attack scenarios and only monitor the relevant logs. In 80%, this comes via syslog and has no or no proper parser and we write one
• Considering parser-tuning/writing:
  • If there is a parser and it just does not do the right things, we clone that, disable the original one, and only add the needed lines to it
  • If there is no parser (usual case), we tell the customer to trigger the logs which are relevant to him and/or our defined attack scenario, take these unknown events and build a parser out of that

I hope that helps a bit to deploy your strategies.

Best,

Christian

On a possibly related note, just to add, starting with FortiSIEM 7.5.0, there are Pre-built Agent Templates for Windows and Linux for you to work from.
https://docs.fortinet.com/document/fortisiem/7.5.0/release-notes/399872/whats-new-in-7-5-0#Enhancem

========

Pre-built Agent Templates

This release adds built-in monitoring templates for Linux and Windows Agents. Linux Agent templates can be found under Admin > Setup > Linux Agent. Windows Agent templates can be found under Admin > Setup > Windows Agent. These pre-built templates can be identified by looking under the Scope column for System.
========

I usually enable just the core Windows Security, System, Application, and PowerShell parsers, plus Linux syslog and auth logs. Keeping anything else disabled cuts noise and saves storage while keeping visibility solid.