Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Event FAQ



Description: Use these frequently asked questions and answers about events to help you understand how JSA correlates user activities in log files to generate offenses.


What is an Event?

In JSA, an event is a message that is received and processed from a device on your network, and is a log of a particular action on that device. For example, an SSH login on a UNIX server, a VPN connection to a VPN device, or a firewall deny logged by your perimeter firewall are all events. These actions occur at an instance of time and are recorded in log files.

What is a unique event?

JSA identifies a unique event based on a number of properties: source IP, destination IP, destination port, protocol, username, and log source ID or event ID. In some circumstances, source port is also used.

When four events come in with the same key properties, they are coalesced into a single record for 10 seconds. When this period passes, the cycle repeats.

What is coalescing?

Coalescing is used to reduce data that is processed by the event pipeline. As data comes in and is coalesced, a large burst of events can convert hundreds of thousands of events into only a few dozen records. This action is done while JSA maintains the count of the number of actual events. Coalescing gives JSA the ability to detect, enumerate, and track an attack on a huge scale. It also protects the performance of the pipeline by reducing the workload of the system, including storage requirements for those events.

One limitation of coalescing occurs when data is being normalized. The first event in the coalesced record, which is used as the base record, is the only one that is kept in its entirety, including the payload. You can disable coalescing for devices and log sources that are used to track audit and compliance requirements in your environment. Examples of these kinds of devices might be custom applications, any customer-facing services, critical assets, or other important devices.

How do different event and log sources compare?

Many different log sources, and kinds of log sources, are supported by JSA, such as firewalls, authentication devices, scanners, file servers, application platforms, and more. Each of these log sources types, as they are referred to in JSA, provide a different perspective and type of information about your network. For example, a firewall reports the number of remote systems that are trying to get into your network. Simultaneously, a Windows or LDAP authentication server provides you with information about local staff members that are logging in to network resources. Your monitoring, audit, and security needs influence the kinds of log sources that you send to JSA.

If a load balancer is used, do events get parsed by any event collector? Do multiple log sources get created?

Any Syslog-based source that is sending data to a load balancer in front of JSA can be parsed on any of the event collectors. All auto-detected log sources in JSA can be processed by any event collector in the deployment. When auto-detection is triggered and a request to create a log source is sent to the JSA Console, the log source is created. Within a minute, all event processors and collectors are aware of this new log source, and any data that is sent to any event processor is automatically associated with that log source. Therefore, you can enable a load balancer in front of multiple event collectors and processors.

One log source is created in this scenario. Multiple create commands can be sent from multiple processors during the first few minutes that a log source is being detected, but it is only created once. When the log source manager on the JSA Console receives the create command, it creates the log source if the log source does not exist. The log source manager ignores the create request if the log source exists.

What do the time stamps in event details mean?

These time stamps can have different values, depending on where the data originated, when data arrived, and when it was written to JSA. The following list describes each time stamp:

  • Start Time - An event record that represents when the event is received by a JSA Event Collector. When events arrive in the pipeline, an object is created in memory, and the Start Time time stamp is set to that time.

  • Storage Time - The time when data is written to disk by the Ariel component at the end of processing by the event pipeline. This time stamp is useful for determining whether events are being queued in the event pipeline for performance or licensing reasons.

  • Log Source Time - The time from the event payload, usually the time in the Syslog header. However, some log sources include the time stamps in the payload such as Windows logs that have a MessageTime field in the body of the payload. If no time is available in the payload, the Log Source Time field is populated with the same value as Start Time.

How does JSA assign a source and destination IP address to events?

JSA events require both a source and destination IP. JSA uses these locations to locate an IP address:

  • From the event payload (First method) - Supported log sources (and universal log sources, if you create your own parsing regex patterns) search the payload of received events for a source and destination IP address. When located, these addresses are placed into the associated Source and Destination fields of the event records. If no IP addresses are in the payload, the other methods described next are used.

  • From the Hostname field in Syslog header (Second method) - If no IP addresses are in the event payload, the Hostname field of the Syslog header is used. The Hostname field is common for events from log sources that include only a Source address in the field, such as web service logs, which include only the remote host IP address. In these types of events, the destination IP address is populated by the Syslog header or the Hostname field of the event. If the Syslog header or Hostname field is a host name, and not an IP address, no DNS look-up is done and instead, the third method is used.

  • Source IP address of the network packet (Third method) - If no IP addresses are available in the event payload, or in the Hostname field in the Syslog header, then the network packet's source IP address is used for the IP address. If the source IP address is from the payload, then this packet IP address is used only as the Destination IP address field. In this instance, the device that sends JSA the event message was the destination address of the event. Sometimes, both source and destination IP addresses are not found in either the payload, or in the Hostname field in the Syslog header. In this case, both the source and destination IP addresses of the event are assigned the network packet IP address.

How does JSA assign IP addresses from central Syslog servers and NAT devices?

If you have an existing central Syslog service infrastructure, or you want to add a forwarding rule to this device that copies a stream of all events to the JSA system. The IP address that JSA uses is the packet IP address. If you use a central Syslog server, you might see the server's IP address in many events, and in the log source names.

To avoid this situation, configure the central Syslog server to add a prefix to a new Syslog header. This new header includes the original source IP address of the packet that was received. In this practice, common when forwarding events, JSA provides this option as part of the forwarding destinations configuration. When you add the prefix, the IP address of the original event source device is always in the Syslog header Hostname field, and JSA uses that IP address in the events. With NAT devices, you might need to go back to the log source devices and reconfigure them to use the IP address of the host in the Syslog header Hostname field, rather than a string-based host name. For example, syslog-ng services refer to this option as chain_hostname.