QRadar is one of the biggest players in the security and information event management (SIEM) space. In 2011, IBM announced acquisition of Q1 Labs and rebranded it into what it is know as today: IBM QRadar.
We break up IBM QRadar SIEM into its high-level components and dive into what they are and how they are useful to you. The point of this article isn’t to spew off buzzy tech words but instead is to explain QRadar’s key components and how to actually 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
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 the information needed to consider a trial or POC.
Key features and Options
What are Rules and how do they Work?
You create rules by using Boolean logic condition combinations of existing rule tests. 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 them inside correlation rules.
Building blocks also eliminates the traditional need of combining correlation rules thus eliminates any rule combination limit.
Sounds confusing, I know. But don’t worry, we will go more in-depth into building blocks.
This is what a sample QRadar rule wizard looks like:
The top box contains the condition logic you will use to match on certain activities. Below this is the rule logic. The priority of logic will happen top down. In this example, it applies a list on the event. Then, it checks the QID. If the QID is a match the next AND condition is ran. This rule triggers an action if the IP address is in the ‘IP addresses’ reference set.
You use the last box to group and categorize your rules.
When triggered, the rule deploys an action. 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
A big limitation of the QRadar rule wizard is that it can be extremely confusing when grouping events into one single offense or attempting to have events associated with their own unique offense.
So, what are QIDs?
Good question. The IBM QRadar Identifier (QID) matches events from external devices like firewalls windows machines to QIDs. There are hundreds of thousands of these identifiers for just about every device. QRadar excels here compared to other vendors. Since QRadar has its own identifier for just about every type of foreign event, it can parse the payloads more effectively out of the box.
What does this mean for you?
You won’t have to build regular expressions to parse the fields you want. For the most part, QRadar does this for you with the combination of QIDs and its native parser called the DSM editor.
Use the DSM editor to extract fields, define custom properties, categorize events, and even define new QIDs.
Reference Sets
Think of a QRadar reference set as a glorified list of key value pairs. Typically, you populate them with all of your known internally and externally owned asset information like IP addresses.
A use for a reference set is to whitelist certain traffic. Another common use is to have rule actions add or remove entries from the reference set.
When integrating with QRadar, the reference set will be the common factor across most vendor platforms. Here’s an example:
You might have a SOAR tool that’s enriches incidents and performs dynamic blocking. Well, after you block the indicator you need to tune QRadar so it doesn’t alert on it again, right?
Accomplish this with a reference set. The first step is to block the IP address or URL and the second step is to add it to a reference set called ‘Blocked IP addresses’ or ‘Blocked URLs’ which the rule referenced in the first place.
Building Blocks Explained
Building blocks are commonly used to build complex logic tests which are used in rules. They are often configured to test groups of IP addresses, privileged usernames, or collections of event names.
Think of building blocks not only as a set of information, but as a function as well. These building blocks will be called and invoked by rules in your QRadar instance.
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? If you’re adding IP addresses or ports to a list, why not use a reference set?
Good question.
Now, 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 he events for correlation, but they also consider the asset information and known vulnerabilities. These variables form what’s called the magnitude which is 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!
Like we said, it’s true that IBM QRadar SIEM looks outdated, but that doesn’t affect how it detect threats. In fact, 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 that QRadar is one of the easiest to onboard new employees to. 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 SIEM?
Benefits of QRadar SIEM
Easy to learn: Like 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 every month 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 re-use quite a lot within QRadar for multiple purposes.
Limitations of QRadar SIEM
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. You need to be extra careful and plan for extra EPS when bringing in additional logs.
Support: IBM support is known for slow response times. Although it’s one of IBM’s flagship products in the security world, they tend 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.