aiFWall Logo aiFObserve

Checkpoint And Generic AI Session Logging Guide


This guide covers:


1. How to capture Check Point session and connection logs with enough detail to convert them into IPFIX biflow-style session data.

2. How to capture equivalent data from other network security devices such as FortiGate and Cisco Secure Firewall, or from any appliance that exports CEF, LEEF, JSON, or key-value syslog.


The companion converter is checkpoint_generic_ai_to_ipfix.py.


What the converter expects


The converter maps session-oriented firewall fields into these IPFIX-style biflow columns:


  • `flowStartMilliseconds`
  • `flowEndMilliseconds`
  • `sourceIPv4Address`
  • `destinationIPv4Address`
  • `sourceTransportPort`
  • `destinationTransportPort`
  • `protocolIdentifier`
  • `packetDeltaCount`
  • `octetDeltaCount`
  • `reversePacketDeltaCount`
  • `reverseOctetDeltaCount`

For Check Point, it can ingest:


  • Log Exporter `syslog`
  • Log Exporter `CEF`
  • Log Exporter `LEEF`
  • Log Exporter `JSON`
  • key-value text exports

It also handles generic CEF/LEEF and common key-value fields used by other firewalls.


Check Point: the best way to capture session data


1. Export logs with Log Exporter


Check Point documents Log Exporter as the supported way to export logs from Management Server or Log Server over syslog, with support for multiple formats including `Syslog`, `CEF`, `LEEF`, and `JSON`.


Sources:


  • [Check Point Log Exporter (R81.10)](https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_LoggingAndMonitoring_AdminGuide/Topics-LMG/Log-Exporter.htm)
  • [Log Exporter Introduction](https://sc1.checkpoint.com/documents/Log_Exporter/EN/Content/Topics/Introduction.htm)

CLI example from Check Point documentation:



cp_log_export add name ai_sessions target-server <SIEM-IP> target-port 514 protocol tcp format syslog --apply-now

The R80.40 administration guide documents the `cp_log_export add` syntax and notes that default export is clear text unless TLS is configured.


Source:


  • [R80.40 Logging and Monitoring Administration Guide PDF](https://sc1.checkpoint.com/documents/R80.40/WebAdminGuides/EN/CP_R80.40_LoggingAndMonitoring_AdminGuide/CP_R80.40_LoggingAndMonitoring_AdminGuide.pdf)

2. Prefer JSON or syslog/generic for highest field fidelity


For the converter, the most useful Check Point fields are:


  • `src`, `dst`
  • `spt`, `dpt`
  • `proto`
  • `bytes`, `packets`
  • `client_outbound_bytes`, `server_outbound_bytes`
  • `client_outbound_packets`, `server_outbound_packets`
  • `creation_time`, `last_hit_time`, `duration`
  • `app`, `matched_category`, `service_id`
  • `rule_name`, `rule_action`
  • `src_user`
  • `loguid`
  • `hll_key`

Two Check Point details matter a lot here:


1. Check Point says update logs can change byte and severity fields over time, and related logs share the same `loguid`.

2. Check Point says multiple connection logs that belong to one user session can share the same `hll_key`.


The converter groups records by `hll_key` first, then `loguid`, so it can collapse update chains into a single biflow-style row.


Source:


  • [Log Exporter Appendix](https://sc1.checkpoint.com/documents/Log_Exporter/EN/Content/Topics/Appendix.htm?TocPath=Appendix%7C_____0)

3. Enable Application Control and URL Filtering


To isolate AI sessions, Check Point’s application-awareness features are the most useful signal. Check Point documents that you must:


1. Enable `Application Control` and, if needed, `URL Filtering` in the Access Control layer.

2. Enable the corresponding Software Blades on the Security Gateway.

3. Configure rules for specific applications or categories.


Source:


  • [Creating Application Control and URL Filtering Rules](https://sc1.checkpoint.com/documents/R82.10/WebAdminGuides/EN/CP_R82.10_SecurityManagement_AdminGuide/Content/Topics-SECMG/Creating-Application-Control-and-URL-Filtering-Rules.htm)

4. Use Detailed Log or Extended Log on the relevant rules


For AI-session capture, use `Detailed Log` or `Extended Log` instead of minimal logging on the Access Control rules that allow web and AI traffic. Check Point’s current docs explicitly call for `Detailed Log or Extended Log` in the track settings for MCP detection, and session-log documentation says:


  • `Connections` appear when `Per connection` is selected.
  • `URLs` appear when `Extended Log` is selected.
  • `Files` also appear with `Extended Log`.

That means:


1. Use `Detailed Log` or `Extended Log` on application-aware rules when you want richer session context.

2. Use `Per connection` when you want each constituent connection, not just the rolled-up session.

3. Keep session logs enabled if you want user activity grouped by application/site.


Sources:


  • [Creating Application Control and URL Filtering Rules](https://sc1.checkpoint.com/documents/R82.10/WebAdminGuides/EN/CP_R82.10_SecurityManagement_AdminGuide/Content/Topics-SECMG/Creating-Application-Control-and-URL-Filtering-Rules.htm)
  • [Log Sessions](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_LoggingAndMonitoring_AdminGuide/Content/Topics-LMG/Log-Sessions.htm)

5. Enable HTTPS Inspection when AI traffic is encrypted


Check Point documents that HTTPS Inspection is required for deeper application and URL visibility on encrypted traffic. Without it, the gateway cannot inspect HTTPS-encapsulated application traffic in the same way. The docs also note that:


  • The HTTPS Inspection policy works with Application Control and URL Filtering.
  • The logs include an `HTTP Inspection Action` field with values such as `inspect` or `bypass`.

Sources:


  • [HTTPS Inspection](https://sc1.checkpoint.com/documents/R80.40/WebAdminGuides/EN/CP_R80.40_SecurityManagement_AdminGuide/Topics-SECMG/HTTPS-Inspection.htm)

6. Use session logs for user-activity rollups


Check Point’s `type:Session` logs roll multiple activities for a user session into one session record. The docs state that a session log includes all user activity at a site or with an application in one session log, and by default a session is cut after three hours unless you change the timeout.


This is especially useful for browser-based AI tools such as ChatGPT, Gemini, Claude, and Copilot, where multiple HTTP requests may belong to one logical user session.


Source:


  • [Log Sessions](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_LoggingAndMonitoring_AdminGuide/Content/Topics-LMG/Log-Sessions.htm)

7. AI-specific policy targeting


Check Point’s current rule guide now includes `Model Context Protocol (MCP)` detection as an application you can explicitly match in policy, and it says to use `Detailed Log` or `Extended Log` plus HTTPS Inspection when MCP traffic is over HTTPS.


That is directly relevant for AI observability because MCP is increasingly used by AI assistants and agent frameworks.


Source:


  • [Creating Application Control and URL Filtering Rules](https://sc1.checkpoint.com/documents/R82.10/WebAdminGuides/EN/CP_R82.10_SecurityManagement_AdminGuide/Content/Topics-SECMG/Creating-Application-Control-and-URL-Filtering-Rules.htm)

FortiGate


Fortinet’s log message reference shows that Traffic logs can include:


  • `sessionid`
  • `proto`
  • `sentbyte` and `rcvdbyte`
  • `sentpkt` and `rcvdpkt`
  • `duration`
  • `policyname`
  • `appid`
  • `applist`
  • `saasname`

Fortinet also documents that Application Control rules can use `Monitor`, which passes the traffic and generates a log message.


Sources:


  • [FortiGate traffic allow log fields](https://docs.fortinet.com/document/fortigate/7.4.11/fortios-log-message-reference/2/2-log-id-traffic-allow)
  • [FortiGate traffic end-forward log fields](https://docs.fortinet.com/document/fortigate/7.4.1/fortios-log-message-reference/13/13-log-id-traffic-end-forward)
  • [Basic category filters and overrides](https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/19814/basic-category-filters-and-overrides)

For AI-session capture on FortiGate:


1. Enable traffic logging on the allow policies that permit outbound SaaS and AI traffic.

2. Attach Application Control profiles to those policies.

3. Use SSL inspection if you need application and URL visibility inside encrypted sessions.

4. Export logs in syslog, CEF, or JSON-compatible format.


Cisco Secure Firewall


Cisco documents that connection events contain session data such as:


  • source and destination IPs
  • application information
  • URLs and users when available
  • total bytes transmitted by session initiator and responder

Cisco also documents:


  • beginning-of-connection logging
  • end-of-connection logging
  • logging on access control, SSL, and Security Intelligence paths
  • Encrypted Visibility Engine (EVE) for identifying applications from TLS client hello fingerprints without full decryption

Sources:


  • [Connection Logging](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/admin/760/management-center-admin-76/events-connect-logging.html)
  • [Connection and Security-Related Connection Events](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/admin/760/management-center-admin-76/events-connection-secint.html)
  • [Encrypted Visibility Engine](https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/760/management-center-device-config-76/encrypted-traffic-eve.html)

For AI-session capture on Cisco Secure Firewall:


1. Enable end-of-connection logging on the access-control rules that allow outbound web and AI traffic.

2. Add beginning-of-connection logging only where early visibility is worth the extra event volume.

3. Enable EVE for TLS-based AI application identification when full decryption is not possible.

4. If allowed by policy, enable TLS decryption for richer application and URL visibility.

5. Export connection events to syslog or SIEM in a structured format.


Generic requirements for any firewall, proxy, or SSE appliance


If you are collecting logs from other devices, the minimum useful fields for biflow conversion are:


  • session or connection identifier
  • start time
  • end time or last-seen time
  • source IP and destination IP
  • source port and destination port
  • protocol
  • client-to-server bytes and packets
  • server-to-client bytes and packets
  • application name or category
  • rule or policy name
  • user name if available
  • URL, SNI, or domain if available

If the device cannot export explicit directional byte counters, total bytes alone are weaker for biflow reconstruction.


Running the converter


Check Point key-value syslog:



python .\checkpoint_generic_ai_to_ipfix.py .\checkpoint.log

Check Point JSON export:



python .\checkpoint_generic_ai_to_ipfix.py .\checkpoint.json

Generic CEF or LEEF:



python .\checkpoint_generic_ai_to_ipfix.py .\security-device.log --keyword "vertex ai" --keyword "azure-openai"

Keep all sessions, not just AI sessions:



python .\checkpoint_generic_ai_to_ipfix.py .\security-device.log --include-non-ai

Important limitations


  • Check Point update logs may represent evolving byte counts over time, so grouping by `hll_key` and `loguid` is important.
  • Session logging and extended logging can materially increase log volume.
  • HTTPS-encrypted traffic often needs decryption or at least TLS/SNI-based identification to classify AI applications well.
  • The generic part of the converter relies on common field names and structured formats such as CEF, LEEF, JSON, and key-value syslog. Vendor-specific custom formats may need extra field aliases.