Fortinet white logo
Fortinet white logo

FortiSIEM Reference Architecture Using ClickHouse

What Data to Collect

What Data to Collect

Every log collected by FortiSIEM has a cost to the organization, both directly in additional licensing, processing overhead and storage, and indirectly in the additional log volume that the analyst has to deal with. Organizations should carefully plan the log sources and log types that will be collected based on organizational requirements, a smaller number of relevant logs is more valuable, manageable and affordable to an organization than a sea of noise.

At a basic level, consider the value of the log source vs the cost of collecting storing and managing logs from it. There are several key devices that most organizations will benefit from integrating with FortiSIEM. These high value log sources provide general visibility of network activity from a few key locations. They are:

  • Perimeter firewall, UTM appliance, IPS and proxy

  • DNS and DHCP servers

  • Active Directory and AAA servers

  • Antivirus management center

  • Vulnerability scanner

Once the core devices are integrated, organizations can identify the next key device groups on a use-case basis:

  • Vulnerable assets such as web servers

  • High value assets, such as servers holding HR and accounts data

  • PCI-DSS networks or other high security, compliance related logging requirements

This leaves general purpose devices such as general purpose servers, edge switches etc. Organizations should consider whether the SIEM deployment scope and requirements extends to log collection from these devices, and if so exactly what logs are required - are authentication logs enough, or is more detailed logging necessary to meet the organizational monitoring needs?

An advanced SIEM deployment should also consider the specific monitoring use-cases to which the platform will be put. This is done by considering the organizational objectives; what is the organizational requirement for monitoring, is it compliance driven, organizational reputation driven, uptime driven…? Once these objectives are understood, technical use cases can be drawn up to help meet them, for example a compliance driven requirement will help dictate the scope of the deployment by the devices or log types that are in scope of the compliance standard that is in question. An uptime driven requirement will help dictate the scope by identifying the core devices that deliver the critical services, and the potential attacks that can be launched against these. Detailed use-case planning is outside of the scope of this document. However, there are several 3rd party books available on the subject.

What Data to Collect

What Data to Collect

Every log collected by FortiSIEM has a cost to the organization, both directly in additional licensing, processing overhead and storage, and indirectly in the additional log volume that the analyst has to deal with. Organizations should carefully plan the log sources and log types that will be collected based on organizational requirements, a smaller number of relevant logs is more valuable, manageable and affordable to an organization than a sea of noise.

At a basic level, consider the value of the log source vs the cost of collecting storing and managing logs from it. There are several key devices that most organizations will benefit from integrating with FortiSIEM. These high value log sources provide general visibility of network activity from a few key locations. They are:

  • Perimeter firewall, UTM appliance, IPS and proxy

  • DNS and DHCP servers

  • Active Directory and AAA servers

  • Antivirus management center

  • Vulnerability scanner

Once the core devices are integrated, organizations can identify the next key device groups on a use-case basis:

  • Vulnerable assets such as web servers

  • High value assets, such as servers holding HR and accounts data

  • PCI-DSS networks or other high security, compliance related logging requirements

This leaves general purpose devices such as general purpose servers, edge switches etc. Organizations should consider whether the SIEM deployment scope and requirements extends to log collection from these devices, and if so exactly what logs are required - are authentication logs enough, or is more detailed logging necessary to meet the organizational monitoring needs?

An advanced SIEM deployment should also consider the specific monitoring use-cases to which the platform will be put. This is done by considering the organizational objectives; what is the organizational requirement for monitoring, is it compliance driven, organizational reputation driven, uptime driven…? Once these objectives are understood, technical use cases can be drawn up to help meet them, for example a compliance driven requirement will help dictate the scope of the deployment by the devices or log types that are in scope of the compliance standard that is in question. An uptime driven requirement will help dictate the scope by identifying the core devices that deliver the critical services, and the potential attacks that can be launched against these. Detailed use-case planning is outside of the scope of this document. However, there are several 3rd party books available on the subject.