---
title: "SIEM"
canonical: "https://docs.aryaka.com/space/KNOW/1272872973/SIEM"
format: markdown
---
Security information and event management  (SIEM) is security software that enables organizations to aggregate, normalize, and analyze security data from various sources across their IT environment. It provides real-time visibility, threat detection, and incident response capabilities, making it a foundational component of modern security operations. MyAryaka provides functionality to export logs in real-time as they are generated on the sites connected to the Aryaka network. This enables seamless integration with external SIEM platforms for centralized visibility, threat detection, and compliance reporting. The Aryaka data path features multiple insertion models through which your sites connect to the Aryaka Cloud. These models provide the foundation for how log generation and streaming are enabled. For sites with an ANAP deployed on-premises, data path modules run locally on the ANAP. For sites without an ANAP, Aryaka dynamically creates a virtual instance for the site on the nearest POP. This virtual site establishes connectivity to this instance using a   static virtual tunnel interface (SVTI) on IKEv1 or IKEv2. The logs generated within the data path originate from multiple modules operating at different stages of packet processing. At the core of the architecture are the following two primary modules: Pre-SSL Post-SSL  These modules are responsible for handling distinct phases of traffic inspection and processing, each contributing to different sets of log events. The data path containing these modules is positioned either on the ANAP (if the site has an ANAP) or at the nearest POP (for sites without an ANAP), depending on the site's connection model to the Aryaka Cloud. These modules—and how they contribute to security inspection—are described in the sections that follow. Pre-SSL module The Pre-SSL module requires an additional license be added to your Aryaka subscription. It includes a set of security engines that you can enable based on your requirements. These engines can be selectively activated to enforce specific security controls based on the type of enforcement you intend to apply to a given site. In the case of HTTPS traffic, the Pre-SSL module analyzes connections in their encrypted (pre-SSL) state. It can only access metadata that does  not  require decryption—such as source and destination IPs and ports. If the connection includes domain information, the module can also retrieve the domain name, its web category, and reputation score—particularly for HTTP traffic. Every connection originating from either the LAN or WAN is first evaluated by the enabled security engines in a defined sequence within the Pre-SSL module. If a security engine is not licensed or has been explicitly disabled, the connection bypasses that engine and proceeds to the next available engine in the configured sequence. This results in some logs  not  including certain security engine-specific information. The evaluation sequence of the security engines involved varies based on the direction of traffic. See  Monitor security  for details about security engine sequencing in both inbound and outbound directions. Post-SSL module The Post-SSL module inspects traffic  after  it has been decrypted in the data path. For HTTPS connections, the Pre-SSL module views the flow as a single connection—typically identified by a 5-tuple. The Post-SSL module recognizes individual HTTP requests within that connection, and treats them as multiple requests and transactions rather than a single continuous connection. Note:  The Post-SSL module is only engaged for traffic that originates from the LAN  after  the Pre-SSL module has evaluated the connection. The following graphic shows four HTTP requests under the same Pre-SSL connection contain the same 5-tuple information (the source IP address (SIP), the destination IP address (DIP), the source port (SPORT), the destination port (DPORT), and the protocol (PROTO)) as the single HTTPS connection. Note that the URI part of the URL could be different in all four requests depending on the user activity on that connection. Log types Aryaka generates multiple types of logs—not only from the Pre-SSL and Post-SSL modules, but also from other components that may not be directly involved in the data path. These log types are described in the sections that follow. Security logs Security logs are generated by both the Pre-SSL and Post-SSL modules for every connection or request that traverses the data path. The Pre-SSL module, which only has visibility into the initial encrypted state of the connection, generates a single log record per connection. The Post-SSL module, which operates on decrypted traffic, has full visibility into individual HTTP requests and therefore generates one log record per request. This results in a significantly higher volume of log records from the Post-SSL module for any given HTTPS connection. Each log record captures metadata, including information about the security engines that were engaged during the processing of the connection or request. One of the critical pieces of information logged is  classification data . If a domain name is available at the Pre-SSL stage, it is sent to a classification engine that returns its web category and reputation score. This information is then embedded in the Pre-SSL log record. Post-SSL logs benefit from access to the full URL of each HTTP request. This enables the classification engine to perform a more granular evaluation, returning the category and reputation score for the complete URL, which is then recorded in each Post-SSL log entry. Security verdicts from various detection engines are also captured in these logs. IPS engines may be triggered at either the Pre-SSL or Post-SSL stage based on traffic patterns and rule configuration. If an IPS engine issues a verdict—such as detecting a signature match—that verdict is logged along with the relevant connection or request. See the  IPS  topic for details about the Aryaka IPS offering, which uses signature-based detection to monitor network traffic for potential security incidents. Additionally, Anti-Malware engines can be engaged based on rules defined in the Anti-Malware rule table. When a file transfer is matched for inspection, a verdict is generated indicating whether the file is clean or malicious. This result is then written into the log record for the corresponding HTTP request responsible for initiating the file download. See the  Anti-Malware  topic for details about the Aryaka Anti-Malware offering, which protects your sites and remote users from malware, viruses, and file-based threats.  Ultimately, these logs form a comprehensive audit trail of how encrypted and decrypted traffic was analyzed, classified, and acted upon by different components in the data path, providing detailed visibility for threat detection, forensics, and rule enforcement. The log structure uses a JSON format that is compliant with the OCSF framework. See  Security log attributes for SIEM integration  for more information about the security logs sent to SIEM. Security logs are only generated when a connection or request is closed. Active sessions do  not  appear in the logs until they are terminated. Flow logs Flow logs are generated exclusively by the Pre-SSL module. Since they are created before decryption, these logs capture only details such as the 5-tuple and traffic statistics. A flow log is generated at the start and end of each connection, and additionally, one log is produced every minute for active connections. These periodic logs include byte counts for transmit and receive, and reflect the delta in traffic statistics over each one-minute interval. These logs are in the Aryaka native JSON format. To learn more about flow logs format, see  Flow log attributes for SIEM integration . IPS logs Although there are three IPS engines that can be engaged in the Pre-SSL and Post-SSL modules when applicable, a single set of IPS logs is generated upon signature match based on the configured IPS rules. Aryaka uses Suricata as the underlying IPS classification engine. The IPS logs are produced in the Suricata Native Event Log format. The logs generated by Suricata in the Aryaka data path are transferred through the SIEM connection without modification. The log record however does include details about which specific IPS engine triggered the log generation, which can be useful for writing efficient parsers. To learn more about IPS log format, see  IPS . Private Access logs Private Access logs are generated by the Private Access gateway servers deployed in each POP. These gateways handle user connections using the NCP VPN client for remote access. Aryaka streams logs related to user connect and disconnect events, login errors (for example, invalid credentials or VPN client IP pool exhaustion, which occurs when there are no available IPs for clients after successful authentication), as generated by these gateway servers. These logs are not generated by a component directly within the Aryaka data path. Instead, they are produced by the gateway component that facilitates remote user access to Aryaka. Once connected, the client's traffic is then routed into the Aryaka data path. These logs use the Aryaka native JSON format. To learn more about the private access log format, see  Private Access log attributes for SIEM integration . Log streaming pipeline The architecture for delivering Aryaka Unified SASE as a Service over its globally distributed SD-WAN network, typically involves customer sites that are spread across regions be connected to Aryaka using multiple POPs. These connections can either use on-site ANAP devices or direct tunnel insertion. Depending on the insertion model, logs are generated either on the ANAP or at the corresponding POP. These logs are securely aggregated at the centralized Aryaka data lake located on our POP in San Jose, CA. They are stored there for advanced processing and analytics to power observability features in MyAryaka. When a SIEM endpoint is configured in MyAryaka, logs are streamed in real time directly from this centralized location—regardless of the endpoint’s location. Whether the SIEM is hosted in the cloud using a public IP or URL, or deployed on-premises at a connected site from any location anywhere in the world, the log stream always originates from Aryaka’s central log forwarding infrastructure in San Jose. Logs can only be streamed in real time through the SIEM pipeline. Historical logs are  not  available to stream to the configured SIEM endpoint. Multi-tenant log processing and delivery architecture The Aryaka logging pipeline is architected for multi-tenancy, ensuring strict data isolation for all tenants. Incoming event streams from the Aryaka Log Foundry are separated from a multiplexed stream by a dedicated Demux service, which assigns logs to customer-specific segments based on internal identifiers. Each segment is provisioned with redundant partitions, which allows horizontal scale-out and fault tolerance. The downstream Aryaka log forwarding service consumes these streams and performs data transformation and delivery to your SIEM collector. The system also incorporates backpressure handling, disk-based failover buffering, and auto-scaling log forwarders to ensure reliable ingestion under varying load conditions and transient failures. Log transport methods On the edge, Aryaka provides the following two methods to connect to the SIEM endpoint: HTTPS—Can be used if the SIEM endpoint is hosted in the cloud with a publicly accessible URL. You can manage this configuration by logging into MyAryaka and doing the required configuration. Network port—Applicable when the SIEM endpoint is hosted on-premises within a site connected to Aryaka. In this case, Aryaka Support must be contacted to perform the necessary backend configuration. This involves establishing secure last-mile connectivity from Aryaka’s central log forwarder in San Jose to a designated ingress point specific to the customer within the Aryaka Core, using a dedicated Layer 2 link. From there, a path is established internally through the Aryaka core to the target site, enabling the log forwarder to directly reach the SIEM endpoint on its private IP address. The Aryaka source IP (provided by the Aryaka support team) attempts to reach the private IP of your SIEM endpoint. This traffic arrives over the ANAP’s LAN interface if an ANAP is deployed on-site, or through the POP tunnel if not. Ensure your network permits access from this source IP to the SIEM endpoint for successful log delivery. Note that on the MyAryaka SIEM configuration page (at Config > Security > SIEM), the SIEM endpoint is listed as a private IP that is likely unfamiliar to you. This is because it is an Aryaka Support internal IP. Aryaka log forwarders send logs to this Aryaka internal IP, which then translates them to your actual SIEM endpoint IP as the traffic traverses Aryaka’s core infrastructure. The end-to-end address translation from the log forwarder to the actual SIEM endpoint—including an internal Aryaka IP used as the destination by the log forwarder—is illustrated in the following graphic: Note that the Aryaka SIEM Endpoint IP shown in the graphic is what you see configured in MyAryaka in such cases. This IP may vary across different SIEM configurations set up using the network port method, but it always represents the internal destination used by the Aryaka log forwarder. In this topic Related topics Configure SIEM integration Flow log attributes for SIEM integration Security log attributes for SIEM integration   Private Access log attributes for SIEM integration