Understanding the QRadar Console

The Console is the brain of QRadar and is the single indispensable component of QRadar. It can collect and process data and throw alerts based on the rules. This is the primary job of the Console. Other components (described later) are mostly used to scale these functionalities in one form or another. Now, let us look at the three major services running on the Console and understand them.

Tomcat

The primary utility of this service is for displaying the User Interface (UI) of QRadar. The QRadar UI can be accessed by typing the IP address or the hostname (if it can be resolved) in the browser.

If the tomcat service is down on QRadar, you will not be able to load the QRadar UI. It maintains the user sessions, active sessions, and current users – all those who have logged in to QRadar UI. It also plays a part in authenticating users, whether it is local authentication, Lightweight Directory Access Protocol (LDAP) authentication, or any other type of authentication. It is a multithreaded service that also deals with the export of data from the QRadar UI. The status of the tomcat service can be checked using a simple command:

 systemctl status tomcat

We will cover troubleshooting tricks and tips for tomcat in the final chapter.

Important note

The Tomcat service is only available on the QRadar Console.

Hostcontext

When the hostcontext service is started, it triggers many other services with it. All the functionalities of QRadar are dependent on the hostcontext service. This service is part of all the QRadar managed hosts, unlike the tomcat service. The hostcontext service is responsible for replicating the deployment changes from the Console to other managed hosts.

The following is the list of services triggered because of hostcontext:

• ecs-ec-ingress: The specialty of this service from the following services is that even if the hostcontext service is stopped from the command line or if the hostcontext service crashes, ecs-ec-ingress keeps running and collecting events from Log Sources. If the ecs-ec-ingress service is stopped, there are two ways of starting:
  1. Restarting the hostcontext service
  2. Starting the ecs-ec-ingress service separately
• ecs-ec: The primary function of this service is to parse (map) the incoming events/flows. This service converts the events into a form that QRadar understands. The event is mapped to its event name by this service. For example, Linux OS has sent an authentication event to QRadar that there is an invalid user named testdev trying to log in via SSH.

The payload of such an event would look like this:

"Apr  10 18:26:40 servername sshd[26388]: input_userauth_request: invalid user testdev
"

QRadar needs to make sense of this payload. This is called parsing. Then, QRadar needs to map this event to an appropriate event name, which is called event mapping. The event will be parsed as follows:

• Time: 6:26:40 p.m.
• Date: 10th April
• Event Name: Authentication Failure
• Server Details: servername

So, the two important functions of ecs-ec are as follows:

• Event parsing
• Event mapping

• ecs-ep: Once the events are parsed and mapped, they need to be processed. Rules are provided as a part of the initial installation. These rules can further be customized as per the security use cases of the organization. ecs-ep is responsible for matching each incoming event against all the enabled rules. If the rule conditions are fulfilled based on the incoming event/events, offenses (security alerts) can be triggered based on the rule action and rule response (defined).

For example, we could have a rule to trigger an offense if we receive an event called Authentication Failure from Linux OS after 6 p.m. In such a case, looking at the previous event in the example, an offense will be generated.

ecs-ep is also responsible for offense management in terms of the following:

• Offense creation
• Renaming offenses
• Attaching events to triggered offenses
• Offenses in a dormant condition
• Offense closure
• Offense deletion

• QFlow: This service is responsible for collecting flows in QRadar. Flows are network packet information collected in a specific format over a period of time.
• Accumulator: This service is responsible for creating global views in QRadar, which can be used for dashboards, reports, and so on.
• Ariel proxy: This service is responsible for relaying the search queries to the appropriate managed hosts.
• Ariel query: This service queries ariel databases across all managed hosts based on the query run on the Console.

There are many other services, and we will discuss them in detail when introducing the concepts related to them.

Hostservices

This service is also part of the Console and other managed hosts. Typically, QRadar has two types of databases:

• Ariel, which is not managed by hostservices (it stores event/flow data)
• Postgres, which is managed by hostservices (it stores configuration)

An ariel database has security data that is collected, and processed by hostcontext. Postgres has the configuration details of QRadar. This is managed by the hostservices service. Postgres is a relational database management system (RDBMS) that has multiple tables containing information on QRadar deployment, configuration, and settings. The Postgres database is replicated on different managed hosts using the hostcontext service. The Postgres database can be queried, if required, using the psql command line. We will discuss this in detail when we talk about optimization and tuning QRadar.

The brain behind QRadar is the Console, and the other components act as auxiliary parts of the system helping the Console perform the functions in a better way. Before jumping on to other QRadar components, let's first discuss and understand event data and flow data.