Best Practices for Cato Event Log Storage and Ingestion

This article explains the recommended best practices for optimizing event log storage and SIEM ingestion processes.

Overview

Storing all your event logs in a third-party service and ingesting them into a SIEM without discriminating between valuable logs and unnecessary ones can lead to issues such as unnecessary storage and SIEM costs, alert fatigue, and SIEM performance degradation. This article describes recommended best practices for Cato customers to optimize both the event log storage and the SIEM ingestion processes and avoid these issues.

The recommended best practices involve two main workflows:

  • Compressing events to reduce storage requirements

  • Eliminating events of limited value when ingesting into a SIEM

In addition to these workflows, we also present some general logging best practices for Cato accounts.

Compressing Events for Storage Optimization

To optimize the amount of storage required for Cato event logs, you can compress the event data during the export process and reduce the required storage up to 95% by enabling gzip compression when making API requests.

For more information about working with the Cato API, see Getting Started with the Cato API.

For an example Python script for eventsFeed that makes API requests with compression enabled, see Example Scripts: Using the Cato API with Python.

If you store events but don’t ingest them into a SIEM, since the compression rate is very high there is little advantage in reducing the number of events by eliminating certain types of events of low value. However, if you also ingest the event logs into a SIEM, it is important to optimize that process and ingest only valuable events, as described in the workflow below.

Eliminating Unnecessary Events

This section presents a suggested workflow for analyzing your events and deciding how to reduce their number.

  1. Eliminate events according to Event Type - In the Events page, use the Popular Fields panel to view the number of events for each Event Type. In most cases, the vast majority of generated events are Security events. If you don’t have a need to log Security events, you can filter them out of your eventsFeed query or your events log integration and avoid ingesting them to your SIEM. Eliminating other Event Types is not likely to have a significant impact on the total number.

    Event_Logging_BP_-_Event_Type.png

  2. Eliminate events according to Sub-Type - If you need to log Security events, you still may be able to eliminate specific Sub-Types of Security events that are unnecessary for your needs. For many accounts, the Internet and WAN Firewall events represent the vast majority of Security events. If you’re only interested in other types of Security events, you can significantly reduce the number of ingested events by filtering out the firewall events from your eventsFeed query or your events log integration and avoiding ingesting them to your SIEM

    Event_Logging_BP_-_Sub-Type_2.png

  3. Eliminate events according to Application - Assuming you need to log firewall events, a significant proportion of those events may be generated by application traffic that you don’t need to log. For example, DNS events often represent a large number of firewall events and may have limited usefulness for you. In the Available Fields section, analyze the number of events for each Application and identify traffic that you don’t need to log. Then create firewall rules with the Allow action and no Event to eliminate generation of events for these applications. We recommend creating a Custom Application defined with the Destination IPs for DNS servers for which you don’t require tracking with events. You can then create a single firewall rule to allow that Custom Application.

    Event_Logging_BP_-_Application.png

    Other examples of applications and services you may want to allow without event generation include:

    • Common network monitoring protocols such as ICMP and SNMP

    • Applications with large numbers of events that are known as safe traffic, such as Windows Update, Microsoft Teams, and Zoom

General Logging Best Practices for Cato Accounts

  • In the Administration > API & Integrations page, enable integration with Cato events. Even if your account doesn’t currently maintain an events integration, this enables Cato to help you troubleshoot issues by analyzing the data in your account events feed. The data won’t be available for troubleshooting without enabling this feature.

    Event_Logging_BP_-_Enable_Integration.png

  • Configure an XDR Response Policy to generate events for XDR Stories that will be included in your events feed. By default, no XDR story events are generated, events are only generated according to configured rules. For more about creating XDR Response Policy rules and the XDR event fields, see Creating the Response Policy for XDR Stories.

  • Note that there may be a minor discrepancy between the total number of events shown on the Events page and the actual number of events sent to storage or a SIEM. This can happen because the number shown can be rounded up, or because sometimes multiple events are combined into a single exported event log. This happens when the same event occurred more than once over the time span of one minute. For more information, see Analyzing Events in Your Network.

    Event_Logging_BP_-_Total_Events.png

Was this article helpful?

0 out of 0 found this helpful

0 comments

Add your comment