QRadar is one of the most prominent security and information event management (SIEM) space players. In 2011, IBM announced the acquisition of Q1 Labs and rebranded it into what it is today: IBM QRadar.
We break up IBM QRadar SIEM into its high-level components and dive into what they are and how they are helpful to you. The point of this article isn’t to spew off buzzy tech words but instead to explain QRadar’s key components and how to use them.
So, whether you’re new to cyber security or a seasoned veteran, we hope you get a lot of value and QRadar SIEM training from the product features in this post.
Contents
- 1 What are the components of IBM QRadar SIEM?
- 2 What are the Benefits and Limitations of QRadar?
What are the components of IBM QRadar SIEM?
IBM QRadar is a complex security information and event management solution. Like most SIEMs, QRadar has log correlation and alerting. But with each SIEM, these tend to come in different flavors. This guide will explain its features on a high level with pictures and examples, leaving you with the information needed to consider a trial or POC.
What are QRadar Rules and How Do They Work?
Out of the box, there are hundreds of available QRadar rules. Rules are also published in QRadar content packs available on the app store.
You create rules by using Boolean logic condition combinations of existing rule tests.
In QRadar, there are four different types of rules. We’ll explain all four:
- Event Rule
- Flow Rule
- Common Rule
- Offense Rule
Event Rules
As the name suggests, the input to event rules will be an event. Filters are used to chain conditions that must be satisfied for the rule to trigger.
The top box contains the condition logic you will use to match certain activities. Below this is the rule logic. The priority of logic will happen top-down. In this example, the QRadar rule will look at all events happening in real-time where the source port is 22, and the source IP is 0.0.0.0.
Flow Rules
Flow rules are designed to monitor packets of data called flow records. Typically, these are captured via switches or other network devices. You’ll also notice the available filters will be unique for flow rules.
Common Rules
Common rules look at events as well as flow records. That means only filters available for event and flow rules will be available for common rules. This means any filters available for events but not flow rules will NOT be available for common rules.
For example, when editing a common rule, search for event payload as a filter. Since event payloads aren’t available in flow rules, they won’t be available in common rules.
Offense Rules
Now, this is interesting. Unlike event rules, which look at events, or flow rules, which look at flows, offense rules look at offenses.
Let’s say you want to trigger an email alert whenever offenses are generated after business hours or on weekends. In that case, you would create a regular event/flow/common rule and an offense rule. The offense rule will look at the specific conditions based on an offense and trigger a rule response.
QRadar Rule Response
All rules will have a rule response. This is what a sample QRadar rule response looks like:
When triggered, rules deploy actions. In the rule wizard, you can change the:
- Severity
- Credibility
- Relevance
You can also:
- Dispatch a new event
- Send an email
- Add event fields to a reference set
- Trigger automated actions
QRadar QIDs
The IBM QRadar identifier (QID) assigns identifiers to events from external devices like Windows endpoints or firewall logs. There are thousands of these identifiers for nearly every device.
For example, QID 3250008 is a Juniper Firewall Permit event. Each QID includes a name, description, severity, and low-level category.
| Name | Firewall Permit |
| QID | 3250008 |
| Description | Firewall Permit |
| Severity | 1 |
| Low Level Category | Firewall Permit |
Since QRadar has a unique QID for every event, it can parse payloads more effectively out of the box. An analog to QIDs in Splunk would be data models.
With the combination of QIDs and the native DSM editor, you won’t have to build complex regular expressions to parse payload fields. Use the DSM editor to extract fields, define custom properties, categorize events, and define new QIDs.
What’s the Difference Between Creating Offenses from the QID Over the Event ID?
QIDs are related explicitly to QRadar mapping. It is indexed by default and will be faster than Event IDs when processing and searching log sources.
How to find a QID?
There are multiple ways of mapping a QID back to an event name.
User Interface
- Click the Log Activity tab.
- Click the Pause icon.
- Double-click on an event to view the detailed Event Information page.
- Click the Map Event button.
- A searchable user interface of QIDs is displayed.
Back-End
- Using SSH, log into QRadar using root.
- Type: ./opt/qradar/bin/idlist.sh -e qid
- A list of all QIDs will be printed on the screen.
- Press Space to page through the list of QIDs.
- To search the list, type /search_term and press Enter. E.g. /malware
- Press q to exit.
Reference Data Collections in QRadar
| Types of Collection | Description | How to Use | Examples |
|---|---|---|---|
| Reference Set | A collection of unique values. | Use a reference set to compare a property value against a list, such as IP addresses or usernames. | To correlate user activity on your network, create a reference map that uses the LoginID parameter as a key, and the Username as a value. |
| Reference Map | A collection of data that maps a unique key to a value. | Use a reference map to verify a unique combination of two property values. | Use a reference map of sets to verify a combination of two property values against a list. |
| Reference Map of Sets | A collection of data that maps a key to multiple values. Every key is unique and maps to one reference set. | To test for authorized access to a PCI server, create a map of sets that uses a custom event property for PCI ID as the key and the Username parameter as the value. Use the map of sets to populate a list of authorized users. | A collection of data that maps one key to another is then mapped to a single value. Every key is unique and maps to one reference map. |
| Reference Map of Maps | A collection of data that maps one key to another is then mapped to a single value. The second key is assigned to a data type. | Use a reference map of maps to verify a combination of three property values. | To test for network bandwidth violations, create a map of maps that uses the Source IP parameter as the first key, the Application parameter as the second key, and the Total Bytes parameter as the value. |
| Reference Table | Create a reference table that stores Username as the first key, Source IP as the second key with an assigned cidr data type, and Source Port as the value. | Use a reference table to verify a combination of three property values when one of the properties is a specific data type. | Create a reference table that stores Username as the first key, Source IP as the second key with an assigned cidr data type, and Source Port as the value |
What are Reference Sets?
Think of QRadar Reference Sets as a list of values. Typically, you populate them with your known internal and external asset information like DNS and IP addresses to white-list specific traffic and segregate alerting rules.
You can also populate reference sets with Threat Intelligence to use in Event Rules. The reference sets provide a way for analysts to define their own rules and set up searches that will identify events that match the elements in the reference set.
What is the Max Recommended Element Count for Reference Sets?
While the answer depends on system specifics, no ‘max recommended’ number exists. However, we have observed the threshold between 100,000 and 300,000 element counts through various performance-related cases with IBM.
One method to prevent a limit from happening is to set a Time-to-Live (TTL) on large reference sets. This will expire older data. When values in the reference set reach a set age via TTL, QRadar can automatically remove the values.
Set TTL on Reference Sets
- Log into QRadar as Administrator.
- Click the Admin tab.
- Click the Reference Set Management.
- Locate the large reference set.
- Click Edit.
- Configure the Time to Live of elements.
Building Blocks Explained
Building blocks are commonly used to build complex logic tests used in rules. They are often configured to test groups of IP addresses, privileged usernames, or collections of event names.
A building block is a collection of tests that don’t result in an immediate action. Think of it like a collection of IP addresses of all your DNS servers. You probably want to build some correlation rules to monitor activity from your DNS servers. A building block of your DNS servers will make it easy to use inside correlation rules.
Building blocks also eliminates the traditional need to combine correlation rules, thus eliminating any rule combination limit.
Think of building blocks not only as a set of information but also as a function. Rules in your QRadar instance will call and invoke these building blocks.
Alerting rules use building blocks to trigger actions. However, building blocks themselves have no actions associated with them.
Why use a building block vs. a reference set? Why not use a reference set if you’re adding IP addresses or ports to a list?
Good question.
You can use reference sets for the above. But, the advantage that building blocks have is they can use CIDR ranges.
QRadar SIEM Offenses
You’re probably familiar with building alerts in SIEMs. They are typically created with underlying correlation rules that match conditions. When a match is found, an alert is created.
Turns out, IBM calls these offenses.
Not only do offenses analyze the events for correlation, but they also consider the asset information and known vulnerabilities. These variables form the magnitude based on the number of events, severity, relevance, and credibility.
We know what you’re thinking. And it’s probably true. The UI looks like it’s from the early 2000s!
As we said, it’s true that IBM QRadar SIEM looks outdated, but that doesn’t affect how it detects threats. It’s pretty good at being a SIEM. Once you get past the antiquated appearance and dive into its workings, you’ll have a fine SIEM running that doesn’t require too much expertise.
Event and Log Searching
The native searching language within QRadar is called advanced querying language (AQL). This is extremely like SQL syntax. Check it out for yourself:
SELECT * FROM events WHERE sourceip = ‘192.168.1.1’ AND destinationip = ‘198.51.1.1’ last 3 DAYS
What’s the bottom line? Is this an effective querying language?
Short answer: yes. We’ve found that out of all the SIEMs, QRadar is one of the easiest to onboard new employees. Since it’s based on a common querying language format, analysts can be up and running performing searches within the first week on the job.
Not only is it simple, but you can save AQL searches for future use and even run them in automated reports to be sent out on a scheduled basis.
What are the Benefits and Limitations of QRadar?
Benefits of QRadar for your SOC
Easy to learn: As we mentioned earlier, QRadar is easy due to its familiar query language, AQL. Also, since it is one of the most popular SIEMs, hiring employees to manage it will be easy.
Integrations: A lot of other vendor products integrate with QRadar. Of the security orchestration automation response (SOAR) tools, XSOAR, Splunk SOAR, Swimlane, and IBM SOAR are verified to integrate with QRadar.
Flexible search and reporting: Say you want to report the number of phishing emails blocked monthly to be sent to your audit team. Within 5 minutes, an analyst can have this set up and firing. Since everything is based on AQL, you can reuse quite a lot within QRadar for multiple purposes.
Limitations of QRadar for your SOC
Pricing: The events per second (EPS) license, like Splunk, will make you cry. We are sure you understand the IBM way, and we are here to tell you they stuck to it with QRadar. When bringing in additional logs, you must be careful and plan for extra EPS.
Support: IBM support is known for slow response times. Although it’s one of IBM’s flagship products in the security world, they tend to remove focus once the SIEM is up and running.
Scalability: IBM QRadar SIEM can face scaling challenges. If managing an on-site instance, be prepared to add additional storage on a scheduled basis. Considering IBM’s pricing model, it’s likely that you’ll continue to be adding log sources.