IBM QRadar Security Information and Event Management (SIEM) helps security teams accurately detect and prioritize threats across the enterprise.
As all the QRadar related documentation is publicly available, you can read and learn everything to be able to design and install your own deployment.
You can use the product with temporary license key that provides you with access to QRadar software for five weeks.
The Community Edition empowers users, students, security professionals, and app developers to learn and experience the latest features of QRadar with no expiration or time limit.
A small piece is still missing: the Network Design of your deployment. In practice it is very important because:
- Your QRadar deployment will be part of your corporate network.
- It will collect and store your most sensitive data.
- The management network settings are “set in stone” – but at least it is a real pain to modify those once you start using your system.
Because of these, you must decide and plan the basic network settings before you start the actual installation.
Let’s see what are the possibilities on QRadar side, with my personal recommendations how to design a proper networking for your deployment.
Logical (ethernet) interfaces are defined by the underlying operating system, and you will assign IP addresses to these interfaces.
The management interface is the most important, as it will be used for accessing your deployment (via HTTPS, SSH, or the API), communication and event forwarding between your managed hosts, reaching external servers, or sending email or SNMP alerts.
From security point of view, it is highly recommended to use a firewall separated network segment solely for your SOC/SIEM/QRadar
- HA crossover
In case of a high-availability deployment, QRadar using DRBD Synchronous replication protocol, where all local write operations on the primary node are considered completed only after both the local and the remote disk write(s) have been confirmed.
Because of this, the network requirements are very strict. In addition to that this link will transfer everything you write to the disk, so it is highly recommended to use a non routable segregated network – or a crossover cable – for this traffic.
- Event/Flow collection
Applies for an All-in-One Console or Event/Flow collectors only.
These interfaces (yes, can be more than one) are the one should be connected directly to your existing network segments. It’s IP address(es) will be the ‘remote syslog’ server for your log collecting agents.
Flow and event collection should be implemented on separate interfaces.
Of course the installation allows you to just not care, and merge these logical interfaces together. Moreover, most of the ‘lazy installations’ ends up with a single interface… Which is a bad practice.
The recommendations above are based on my personal experience on the IT Security field. But even if you ignore the security part – which you should not do – there are many practical reasons to follow this design. The most important one is the fact that the management interface is kind of “set in stone” after the installation. A lot of things will depend on it, and modifying this later on a production environment is a real pain. – You have been warned!
The available physical interfaces depends on your hardware, which can be an IBM provided appliance, your own preferred boxes, or a virtual machine. The mentioned layout below is a typical IBM appliance
- 1x IMM/ILo
This is a dedicated hardware management interface. Even if your BIOS may allows it, it is not recommended to share this with any other service. This is connected to a separate computer inside your appliance, should be not interfere with your OS and applications.
- 4-8x 1Gb Ethernet
The well known standard 1Gb Ethernet ports, you can assign them to logical interfaces by your operating system.
- 2x 10GbE
High speed network interfaces, where the transport layer defined by SPF modules. Typically Ethernet over Fibre for LAN is used, so you can assign them to logical interfaces by your operating system.
High speed FC interfaces for connecting optional external storage.
Logical to Physical
Here comes the decision part, to define how to assign your physical interfaces to the logical ones. In a real world scenario it is really depends on your network design, capabilities and policies, as they have to provide the required network separation, IP addresses and the very basic services like DNS, NTP, SMTP for your QRadar deployment.
Means the very simple and basic network assignment. Which is fine for a normal server, but the typical 1Gb throughput is not always enough for the task, and even if you using a 10Gb interface it is still not redundant – which may be a requirement forced by regulations.
The Linux bonding driver provides a method for aggregating multiple network interfaces into a single logical “bonded” interface. The behaviour of the bonded interfaces depends upon the mode. Of course this needs support from your network switches. Moreover, if you use it for redundancy the whole network path must be redundant.
HA crossover link is a special assignment, as it is defined and configured by the HA installation process.
You can select multiple interfaces, and those will be “bonded” behind the scenes.
Keep in mind, that the defaults are assuming a real cross link cable. You can still define your own network details via the advanced configuration, but do not forget to set your MTU, as the default are 9000 – assuming Jumbo Frames.
Now you know the possibilities, let’s discuss with your network team and plan your final network design!
Imagine a basic network, segmented by firewall
Here are some example how you should – or should not – design you QRadar network connections.
The – not so – Bad
and The Ugly – what you should avoid.
Of course the Good, the Bad, and the Ugly designs are just for reference. You can create several acceptable permutations of these. In practice you must adapt to your netwkor capabilities and your budget. Then you can surely find a good balance.
As I’m currently working for IBM, please read my disclaimer.