IBM Security QRadar

When using QRadar to monitor network traffic for suspicious activity, one valuable piece of information is the flows’ “application”. This deepens your view into a conversation, as you begin to piece together what was happening on your network. With the most basic QRadar flow deployment, hundreds of applications are identified. Enhancing this with QRadar Network Insights brings this number into the thousands. 

Besides detecting hundreds of applications, you can also define and customize applications in QRadar. Whether you want to focus on an application and receive information more specific than only “HTTPWeb”, or you want to introduce a new application mapping for your own enterprise application, you can use QRadar to customize this application detection. This article will provide instructions on how to create your own new application definition, then outline two different approaches for implementing your own classification.

Defining a new application

The master list of all applications that are used for classification of flows within QRadar is contained within the apps.conf file. This file can be found on the QRadar Console at the following path:

The format of the file is fairly simple:

This file uses hash-separation to configure up to five levels of application grouping, followed by a unique application ID. The range 15,000 to 20,000 is reserved for custom application definitions.

To add your own application, edit this file and add a new line in the same format:

CorporateApplications#Wiki####15000

Once that file is saved, you’ll be able to deploy the changes from the Admin tab in the console. Your new application definition is now able to be used.

Detecting custom user applications

The first way to customize this detection is through the user application mapping file. This approach applies to all flows regardless of where they came from because it utilizes the 4-tuple below for each flow: source IP, source port, destination IP and destination port.

The user application mapping file is empty by default and can be found at the following path on a console:

The format of this file is as follows:

So, in what scenario would you want to modify this file? Suppose you have a series of flows in your system that are being classified as HTML traffic. You want this definition to be more specific to describe the service that is running this traffic.

By hovering over the application name, you can see the ID that is associated with this flow:

With some business knowledge of the destination server, you know there is a WebSphere server listening on port 9080 for your custom web application. 

To use QRadar to identify these flows correctly, change the following two config files:

1. Edit the /store/configservices/staging/globalconfig/apps.conf file to add a new application within the 15,000 to 20,000 range:
       HttpWeb#WebSphere####15000

2. Edit the /store/configservices/staging/globalconfig/user_application_mapping.conf file to define the rule for application classification:
       15000 17131264 *:* 10.100.30.206:9080 WebSphere

3. Deploy the changes through the Admin tab on the console. 

Once this has been deployed, all new flows matching the rule defined in the user application mapping file will feature the updated application ID and application name:

Detecting applications using payload signatures

Sometimes classifying flows based on the 4-tuple is not enough. This is where the application signatures file comes in. This file adds protocol as well as the source and destination payloads into the mix.

The XML file has a number of signatures already built into it and can be found on a console at the following path:

/store/configservices/staging/globalconfig/signatures.xml

The structure is fairly self-explanatory, with the key items to pay attention to highlighted below:

This signature is designed to identify HTTPS traffic - which is application ID 1011 within QRadar. HTTPS traffic always has 0x1603 as the first two bytes of the payload, so this rule checks to see if our incoming flow payload starts with this hexadecimal value.

Adding your own rules to this file could be useful if QRadar doesn’t already identify some flows on your network. As an example, the processing of VXLAN encapsulated flows is not currently supported by QRadar. In fact, the flows display as an “other” or unknown application:

We can introduce VXLAN traffic identification by adding a custom signature rule. The VXLAN protocol is well defined – it normally runs on UDP port 4769, and the first four bytes of payload are 0x08000000. The steps required to configure this to a QRadar application signature are as follows:

1. Edit the /store/configservices/staging/globalconfig/apps.conf file to add a new application within the 15,000 to 20,000 range:
   
   Protocols#VXLAN####15001

2. Edit the /store/configservices/staging/globalconfig/signatures.xml file to add a new signature for VXLAN traffic:

   <signature>
    <appid>15001</appid>
    <appname>VXLAN</appname>
    <groupname>Protocols</groupname>
    <colour>#ff0000</colour>
    <description>VXLAN traffic</description>
    <revision>1</revision>
    <protocol>UDP</protocol>
    <srcip>any</srcip>
    <srcport>any</srcport>
    <dstip>any</dstip>
    <dstport>any</dstport>
    <commondstport>4789</commondstport>
    <srccontent offset="0" depth="4">|08 00 00 00|</srccontent>
    <weight>60</weight>
    <sigid>1000</sigid>
</signature>
    

3. Deploy the changes through the Admin tab on the console. 

Once this has been deployed, all new flows matching this signature will be classified correctly:

Summary

In addition to application detection capabilities, users can apply QRadar’s functionality to customize and create new application mappings. This article outlines two ways you can leverage this – customizing application detection to be tailored to your enterprise, and introducing brand new application definitions using the user application mapping and application signatures configuration files. 

Check out Jose Bravo’s video series on customizing application detection for QRadar Flows.