Events FAQ

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

What is an Event?

In QRadar, 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?

QRadar 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 QRadar maintains the count of the number of actual events. Coalescing gives QRadar 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 QRadar, such as firewalls, authentication devices, scanners, file servers, application platforms, and more. Each of these log sources types, as they are referred to in QRadar, 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 QRadar.

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 QRadar can be parsed on any of the event collectors. All auto-detected log sources in QRadar 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 QRadar 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 QRadar 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 QRadar. The following list describes each time stamp:
  • Start Time
    An event record that represents when the event is received by a QRadar 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 QRadar assign a source and destination IP address to events?

QRadar events require both a source and destination IP. QRadar 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 QRadar 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 QRadar 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 QRadar system. The IP address that QRadar 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, QRadar 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 QRadar 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.

(Back to top)