IBM Security QRadar

 View Only

All about Routing Rules in IBM QRadar

By Bubai Maity posted Tue July 06, 2021 09:16 AM

  

All about Routing Rules in IBM QRadar:


Routing Rule is one of the advanced and differentiative features in IBM QRadar SIEM. Using routing rules we can ignore or forward events based on your requirement. They work similar to your normal QRadar rules. In IBM QRadar, Routing Rules determine whether events and flows are forwarded to a remote destination or processed locally.

Events enter the event pipeline of IBM QRadar using the ecs-ec-ingress collection service. After this, the events are parsed using the ecs-ec process and then the normalized data is sent to the next phase in the pipeline which is ecs-ep. This ecs-ep process is responsible for running the rules on these events as well as for streaming and storing the events.

Routing Rule comes in after this ecs-ec process on the Event Pipeline.

You can use Routing Rules to forward specific events/flows to a secondary system that can be a QRadar system or any other as a backup solution or even a test/DR environment.

These routing rules define what events and whether to send them (and where) or drop them or not run rules on them.


In Routing Rules, you can select four different options which determine what is to be done with the events or flows which match the Routing Rule in question. These are: 

  • Forward
  • Drop
  • Bypass correlation
  • Log Only 


Let’s say you want to store the events (which match a routing rule) on the local QRadar box as well as forward the events/flows to another deployment. In this case, you can choose the Forward option in the Routing rule that will forward the data to a forwarded destination as well as it will store the data in the local QRadar deployment Ariel DB.

If you select the Drop option to drop unwanted events then the events/flows which match this routing rule are not stored in the backend Ariel DB of IBM QRadar. Also, you will have License Give back (which we discuss in detail later in this post). In this case, since the events are dropped before the ecs-ep, the dropped events are not seen by the Custom Rule Engine (CRE) of QRadar.

If you select the Bypass Correlation option then those events/flows which match the specific Routing Rule will be stored on the local Ariel DB, however CRE rules will not run on them. For example, if you have events which are generating false positive and you do not want the CRE to run on them, then you can select this option.

There is another option in Routing rule, which is Log Only. This option is applicable only for Events. If you select this option, then the events are stored in the backend Ariel DB and are flagged as log only. These events will bypass the CRE. However, unlike the “Bypass Correlation” option discussed previously, these events will not be available for historical correlation and some of the IBM QRadar Apps which use accumulated data will not process these events. However, they will be searchable and EPS license will not be counted against such events.

Routing Rules can be created from under the Admin Tab -> Routing Rules option as show in the below screenshot:

  


Forwarding Events/Flows in IBM QRadar using Routing Rules:
 

As discussed previously, you can use Routing Rules to forward events/Flows. For a Routing Rule to forward data, you need to first setup the Forwarding Destinations. There are two modes in which data can be forwarded using Routing Rules:

  1. Online:

In Online mode, forwarding is done in real-time. The ecs-ec process is responsible for forwarding the data from the QRadar event pipeline. In online mode, there is a potential loss of data if the forwarding destination is not reachable. When the forwarding destination is not reachable, any data that is sent to the remote system is lost. A copy of these events would be stored in the local Ariel DB unless you have selected to “Drop” the events as well together with “Forward”.

However, if you select DROP together with the “Forward” option, then the event pipeline drops the matching data at the “Event Forwarding / Routing” stage, which is the last step in ecs-ec. Dropped data in such cases will not be processed by the CRE which means no rules will run on such events.
  

  1. Offline:

In Offline mode, all data is first stored in the database and then sent to the forwarding destination. This mode ensures that no data is lost; however, delays in data forwarding can occur.

QRadar forwards data in near-realtime (not real-time like the Online option discussed previously). It will keep track of which data it has sent and in case the destination is not reachable, it will buffer the data locally. Once the destination is reachable again, it will start sending the data from where it had stopped.

Unlike the “Online” mode, in “Offline” mode, the data is not streamed. It is forwarded via storage. When you select the “Offline” option then a process called the “Offline Forwarder” is responsible for working with Ariel reader to retrieve events from the disk after it is written to storage and decide what data should be forwarded.

This process checks for a connection to the destination at start-up keeps a track of the last data sent (using bookmarks) and forwards the data to the remote destination. This data is around a minute behind since Ariel writes data in a minute interval onto disk. As data is forwarded, a “bookmark” is created in /store/offline forwarder for either event or flow data to show the timestamp and next file that needs to be read based on the last event that was successfully forwarded to the destination. If for some reason the bookmark files are missing, Ariel Reader will create a new starting point 2 minutes behind the current timestamp to use as a start time for forwarding data.


How to create a routing rule to forward data:

  1. Login to GUI as admin user. Click Admin.
  2. In the System Configuration section, click Routing Rules.
  3. On the toolbar, click Add.
  4. In the Routing Rule window, type a name and description for your routing rule.
  5. In the Mode field, select one of the following options: Online or Offline.
  6. In the Forwarding Event Collectoror Forwarding Event Processor list, select the event collector/processor from which you want to forward data.

                    Note: Forwarding Event Collector:

                              This option displays when you select the Online option. This specifies the Event Collector from which you want this routing rule to forward data

    Note: Online/Realtime forwarding is not impacted by any Rate Limit or Scheduling configurations that might be configured on a Store and Forward (15xx) Event Collectors.

                    Note: Forwarding Event Processor:

                              This option is displayed when you select the Offline option. This specifies the Event Processor from which you want this routing rule to forward the data.

    Note: This option is not available if you select Drop from Routing Options pane.

      7. In the Data Source field, select the type of data that you want to route: Events or Flows.

         
             The labels for the next section will change according to your selection.

      8. Specify which events or flows to forward by applying the required filters:
            i) To forward all incoming data, select the Match All Incoming Events or Match All Incoming Flows check box. Note: If you select this check box, you cannot add a filter.

            ii) To forward some events or flows, specify the filter criteria, and then click Add Filter.

           9. Specify the routing options to apply to the forwarded data:

                 i) This is optional, if you want to edit, add or delete a forwarding destination, click the Manage Destinations

                 ii) To forward log data that matches the specified filters, select the Forward check box and then select the check box for each forwarding destination.

                    Note: If you select the Forward check box, you can select only one of these checkboxes: DropBypass Correlation, or Log Only. You can combine multiple options together which we will discuss in detail in the later part of this post.

          10. Click Save.

     

    Scenarios for using routing rules:

    Routing rules bring unique capabilities to IBM QRadar. You can create routing rules based on your different requirements. However, do keep in mind that if a specific data matches multiple routing rules, then the ‘safest’ option is applied. We will discuss this in detail in the later part of this post.

    Here we talk about some of the use-cases where a combination of Routing Rule options can be used:

    • Forward and Drop:

     You just want to forward events online to another destination and do not want those events to be stored on the backend local Ariel DB. In this case you can select this combination option.  Any events that are dropped are credited back 100% to the license in the next second. These events are ignored by the local CRE.


    On the Source deployment (where you have created these Routing Rules), these events will not be seen since you have selected the Forward and Drop option combination: 

    On the Forwarded Destination, these events will be visible:

     

    In the backend log file, you will see entries like below:

     Apr 29 22:30:09 ::ffff: x.x.x.x [ecs-ec.ecs-ec] [[type=com.ibm.si.ec.filters.ForwardingFilter][parent=bm-733-aio.in.ibm.com:ecs-ec/EC/Processor2]] com.ibm.si.ec.filters.ForwardingFilter: [INFO] [NOT:0000006000][x.x.x.x/- -] [-/- -] (Total Events Seen: 50392709), (Total Events Dropped: 99482), (Total Events Forwarded: 122899), (Total Events Not Correlated: 23417)

    • Forward and Bypass Correlation:

    You want to forward the data to another destination. However, you also want these events to be stored on the local QRadar Ariel DB but do not want the local CRE to process those events. In this case, you can choose this combination option.


    After creating the routing rule which such a combination, you will see the Total Events Not Correlated count increasing in the backend log file:

    Before configuring the Forward and Bypass Correlation Routing Rule:
    Apr 29 22:30:09 ::ffff:x.x.x.x [ecs-ec.ecs-ec] [[type=com.ibm.si.ec.filters.ForwardingFilter][parent=bm-733-aio.in.ibm.com:ecs-ec/EC/Processor2]] com.ibm.si.ec.filters.ForwardingFilter: [INFO] [NOT:0000006000][x.x.x.x/- -] [-/- -] (Total Events Seen: 50392709), (Total Events Dropped: 99482), (Total Events Forwarded: 122899), (Total Events Not Correlated: 23417)

     

    After configuring the Forward and Bypass Correlation Routing Rule:

    Apr 29 22:35:09 ::ffff:x.x.x.x [ecs-ec.ecs-ec] [[type=com.ibm.si.ec.filters.ForwardingFilter][parent=bm-733-aio.in.ibm.com:ecs-ec/EC/Processor2]] com.ibm.si.ec.filters.ForwardingFilter: [INFO] [NOT:0000006000][x.x.x.x/- -] [-/- -] (Total Events Seen: 50449230), (Total Events Dropped: 99482), (Total Events Forwarded: 179420), (Total Events Not Correlated: 79938)

    • Forward and Log Only (Exclude Analytics):

     You can select this option if you want to forward the events to a specific destination as well as want to store the events locally without the CRE running on these events. Together with this, you do not want these events to be counted against your EPS license as well as do not want to run a historical correlation on these events. In such a case, you can create a Routing rule with this combination.

    Note: You need to provide your consent while selecting the “Log Only (Exclude Analytics) option:

     


     

    Precedence in case of Routing Rules:

    In Routing Rules there are multiple options that you can select. You have the option of selecting different combinations as well which we discussed earlier. In scenarios where the data matches multiple Routing Rules, the “safer” option is selected. This “safer” option is selected based on precedence.

    Do note that the “Drop”, “Bypass Correlation” and “Log Only (Exclude Analytics)” options are mutually exclusive/ Only one of these options can be selected at any time.

    We can arrange the options based on the precedence. Precedence is determined by the impact that the Routing rule option has. This precedence is followed when QRadar selects the “safer” option when data matches multiple Routing Rules. Below is this precedence order that is followed by QRadar. It is arranged from the least impactful to the most impactful.

    1. Forward - Data Forwards from one QRadar to another using the first option. It is also stored in the local QRadar database and is also processed by the CRE.
    2. Forward + Log Only (Exclude Analytics) - Events are forwarded to the specified forwarding destination. Events are stored and flagged in the local QRadar database as Log Only and CRE is bypassed. These events are not available for historical correlation and they do not count against the EPS license.
    3. Forward + Bypass Correlation - Data is forwarded to the specified forwarding destination. Data is also stored in the database, but it is not processed by the CRE.
    4. Forward + Drop - Data is forwarded to the specified forwarding destination. Data is not stored in the database and is not processed by the CRE. Since the “Drop” option is also selected here, the number of events Dropped, an equivalent EPS value is credited back to the EPS license in the next second.
    5. Log Only (Exclude Analytics) - Events are stored and flagged in the database as Log Only and CRE rules are not executed on them. These events are not available for historical correlation and they are not counted against your EPS license. This option is not available for flows or if you select the Offline option. The Log Only option requires an entitlement for QRadar Data Store. The events do not contribute to offenses and they are ignored when historical correlation runs. Some apps will also ignore such Log Only events.
    6. Bypass Correlation - Data bypasses CRE but it is stored in the database. This option is not available if you select the Offline option. You can use the events in analytic apps and for historical correlation.
    7. Drop - Data is dropped. The data is not stored in the database and is not processed by the CRE. This option is not available if you select the Offline option. Any events that are dropped, an equivalent EPS value is credited back to your EPS license in the next second.

    As you can understand from the above order of precedence, forwarding an event is the least impactful as the event is forwarded to a destination. However, Drop is the most impactful since the event is lost forever.

    Precedence examples when multiple Routing Rules match the same data:

    When creating different Routing rules, there is a chance that the same event might match multiple Routing Rules each with a different set of actions/options. In such a scenario, QRadar will check for the least impactful one and execute those options. For example, let’s say an event matches two routing rules. One of the Routing rule is Forward together with Drop option while the other Routing Rule is Forward with Bypass Correlation as its option. Below are the screenshots of how these two Routing Rules will look like (For simplicity sake, we have selected the “Match All Incoming Events” option under the “Filters” section in the below screenshots):

    Forward with Drop:

    Forward with Bypass Correlation:


    In this case, QRadar will select the Routing rule with the least destructive option (decided as per the precedence discussed previously) and execute that action. In this case, it will select the forward with bypass correlation Routing rule rather than the other one and will forward the events matching it while also bypassing correlation.


    Let’s talk about another example where you have the same event matching two different Routing Rules. The first one has the Forward with Drop option selected whereas the second Routing rule has just the Bypass Correlation selected. Below are the screenshots of how these two Routing Rules will look like (For simplicity sake, we have selected the “Match All Incoming Events” option under the “Filters” section in the below screenshots):

    Forward with Drop:

     

    Bypass correlation:

     

    In this case, QRadar will select the Routing rule where the option of Forwarding has been selected. Hence it will select the Forward with the Drop option rather than selecting the Routing rule with just the Bypass Correlation option. This is determined by the precedence that we had discussed in detail previously.

    License Giveback:

    One of the main use-case of Routing Rules is to remove unwanted events from the License count. Let’s say you have a log source which are sending some specific type of events that you do not want to use in correlation and do not want it to be counted against your License. In this case, you can create a Routing Rule for such events and then use the “Drop”. Using this option, not only will those events which match this routing rule get dropped and not get stored in the Ariel Database but also based on the number of events that are being dropped per second by this routing rule an equivalent EPS value will be added to your license/EPS that has been allocated to that specific Event Processor. This is known as License Giveback.

    For example, let’s assume you have 5000 EPS license assigned to an Event Processor. Now, on this Event Processor you create a routing rule to drop events. This routing rule starts dropping 100 EPS. Due to the License Giveback, during the next second, 100 EPS license will be added to your existing EPS license which was 5000 EPS. This means that if in the present second 100 EPS was dropped due to this routing rule, in the next second, your license will be 5000 EPS (original license value) + License Giveback value (100 EPS) = 5100 EPS.

    In this way, we can say that the events which you are dropping using the “Drop” option in the routing rule, they will not be calculated against the license. However, an important point to keep in mind is that the License Giveback occurs in the next second and not in the same second when the events were dropped.

    This License Giveback using the “Drop” option is different from the “Log Only” option discussed previously.  The Log Only (Exclude Analytics) option specifies that events are stored and flagged in the database as Log Only and bypasses CRE. These events are not available for historical correlation and are credited back 100% to the license.

    You can combine the Forward and Log Only (Exclude Analytics) options. Events are forwarded to the specified forwarding destination in online mode. Events are stored and flagged in the database as Log Only and bypass CRE. These events are not available for historical correlation and are credited back 100% to the license. This option is not available in offline mode. This feature is part of the IBM QRadar Data Store offering which normalizes and stores both security and operational log data for future analysis and review. This offering supports the storage of an unlimited number of logs without counting against your organization’s Events Per Second QRadar SIEM license and enables your organization to build custom apps and reports based on this stored data to gain deeper insights into your environments.

    Using the Log Only (Exclude Analytics) option requires entitlement for QRadar Data Store but is not currently enforced. In the future, when entitlement is enforced, access to the collected event data will be restricted to properly licensed systems. When the license is applied and the Log Only (Exclude Analytics) option is selected, events that match the routing rule will be stored to disk and will be available to view and for searches. The events bypass the custom rule engine and no real-time correlation or analytics occur. The events can't contribute to offenses and are ignored when historical correlation runs. Some apps will also ignore Log Only events.


    Summery

    Routing Rules can be interesting to use and gives you more power in determining what you want to do with the Events and Flows that are being picked up and processed by your IBM QRadar deployment. In fact, some of the large integrations of IBM QRadar with Big Data solutions are done using Routing Rules. There are other different use cases as well which are not covered in this post and can be implemented using Routing Rules. You can use this post as a starting point to understand the intricacies of using Routing Rules.

    If at any point in time, you have any questions, have any comments or want to discuss this further, feel free to get in touch with us and we would be more than happy to answer any of your queries:

    Aniruddha Guha (Ani) – anguha12@in.ibm.com

    Bubai Maity (Bubai) – bubmait1@in.ibm.com

    Boudhayan Chakrabarty (Bob) – bochakra@in.ibm.com 

     

    Special thanks to Ashish Kothekar (ashish.kothekar@in.ibm.com) for reviewing our Blog.

    0 comments
    98 views

    Permalink