QRadar Integrations: High-Level Design and Architecture Overview
This post outlines the software design and architecture necessary for building a custom integration application between QRadar and a generic security sensor.
QRadar is a versatile security (SIEM) application that can be widely integrated with other applications and security sensors.
This post outlines the software design and architecture necessary for building a custom integration application between QRadar and a generic security sensor.
Integration Basics
Integrations are essential for automating tasks and other processes between your QRadar installation and apps.
Your integration can be designed to perform various functions. Some possible functionality in your integration application can include:
- Pulling data from an external sensor/API.
- Consuming syslog events pushed from an external source and transform them for use in QRadar.
- Providing a custom dashboard within QRadar.
- Providing app configuration pages.
- Raising an offense in QRadar when a specific event have been received.
Important Notes
- QRadar GUI application framework apps are stand-alone web applications that run on the Flask micro framework, and are served from the Flask web server.
- Applications can be developed using Python.
- Each application runs in a Docker container and communicates with QRadar. If an app requires internet access, a proxy support needs to be built into the app.
Building Blocks
Integrations are composed of many parts that connect your installation with the app.
| Name | Description |
|---|---|
| Manifest | Provides metadata like name, description, etc for the application. |
| Views | The entry point into the web application. |
| Static resources | HTML and Javascript for views, such as custom dashboards, config pages, etc. |
| Dependencies | Optional dependencies for the app, such as external libraries. |
| GUI Actions | Provides methods for running client-side javascript OR for making REST calls from QRadar GUI elements like buttons. |
High-Level Architecture
The following image details the typical connections between your QRadar installation, your apps and the user.
Things to note:
- Each QRadar app runs on the QRadar host (i.e., the machine on which QRadar is installed).
- Each app runs in a Docker container.
- The maximum amount of memory that an app can consume is limited to 10% of the total available system memory.
- Pages like dashboard, configuration, etc. are rendered within the QRadar GUI framework.
- The QRadar GUI framework allows us to build applications that react to specific user input, like right-clicking on an item, clicking on a toolbar button, etc.
Lifecycle of a QRadar App
A QRadar app has the following lifecycle:
- Initialization - The app is initialized by starting the flask webserver, which will in turn serve pages such as user configuration, etc.
- Incident setup - There are two ways that the app can retrieve incidents/events/logs into QRadar logs:
- Push - Clients can begin pushing events to a specified port on the QRadar machine.
- Pull - The app can periodically pull events from a user-configured server and store them in QRadar.
3. Incident processing - The app parses the event payload and transforms them into QRadar format. Created events are identified by offense rules and create offenses in QRadar.
4. Dashboard - Once the events are in QRadar, the apps dashboard will show filtered views and metrics based on these events. Each client will typically have their own dashboard with metrics that their customers are most interested in.
Note: There are other asynchronous lifecycle events that take place when the user interacts with the QRadar / dashboard UI. Some examples are:
- Custom toolbar button and right click option on custom field to:
- Open the link in a new popup window.
- Open Custom UI in a popup window to update back the status to source incidents/events/logs.
Conclusion
In conclusion, this post provides a very high level overview of the design and flow of a typical QRadar integration. Of course, knowing the design software and architecture, such as is listed here, is only part of the design process.
Each client will have specific requirements for their integration, which must be taken into account whenever work begins on an integration. Therefore, it is essential to outline the requirements of any integration before development work begins.
If you are considering any custom cybersecurity solution that focuses on the resources and needs of your organization, please send a note to connect@metronlabs.com.
