Architecture of IBM QRadar (SIEM)
QRadar comprises of several components and you need to know their functions before deploying it in your infrastructure. QRadar has a modular architecture, which indictaes that the tool is made up of seperate components that are connected together, but are not dependent on each other. We can scale its deployment to add on more devices, endpoints and machines in the infrastructure. We can also add integrated modules to your QRadar platform, such as QRadar Risk Manager, QRadar Vulnerability Manager, and QRadar Incident Forensics.
The QRadar consists of 3 layers and applies to any QRadar deployment irrespective of its structure, size and complexity.
What do these three layers do?
Data Collection
This is the first layer where all the events or flows are collected from the network. The data is parsed and normalized before it is passed to the processing layer. Parsing is performed to convert raw data into readable format. This action is performed through Device Support Model (DSM Editor), by the use of DSM Editor you can parse your data to any format. The primary function of QRadar (SIEM) is focused on event data collection and flow collection. Traffic and communication information are shown under flow sources. Flow collector passively collects traffic flows from the network through ports or network traps. QRadar is also capable of collecting external flow-based data sources such as NetFlow with the help of QRadar QFlow Collector. Event Data: These comprises of events which occur within the user’s environment at any any given point of time such as logins, firewall configuration, USB connectivity, email. Flow Data: Is the network activity information or session information between two hosts on a network which is then translated by QRadar into ‘flow records’. Raw data of two hosts communicating on network is transformed into bytes, packet counts, IP address and ports. The main feature of QRadar Incident Forensics is that it helps with full packet capture besides collecting flow data.
Data Processing
Once data is collected in the first layer, it is passed onto the second layer. This layer is responsible to generate offenses and alerts by processing the event data and flow data. These data are run through Custom Rules Engine (CRE), these rules are created by the user on the console are matched with events. The user needs to set specific actions or reponses and if the conditions match the evnts, the action willl be taken. This is done by CRE. The matched events are not sent directly to the console by the CRE, they are sent to Magistrate on the console. This is responsible to create and manage offenses on the console. Flow Processor is a device that can scale your QRadar deployment to manage higher FPM rates.
Data Node: Is an applicance that can be added to event and flow processors to increase storage capacity and improve search performance. These can be added at any time and the QRadar deployment can have unlimited number of Data Nodes. Each Data Node can be connected to only one processor, but a processor can support multiple data nodes. Also the QRadar automatically redistributes the data to balance the storage in the deployment.
Data Searches
Finally! The last layer on the QRadar architecture. The QRadar console provides product interface, event and flow views, reports and administrative functions. This also allows analyts to take action. Vulnerability Scanner: The responsibility is to perform vulnerability scanning and upload them to the console. In distributed environments, QRadar Console is used primarily as user interface where users can use it for searches, reports, alerts and investigations.
That’s a wrap for today. I will catch you folks on the next blog, where I talk about configuring Flare VM and REMnux for Malware Analysis.
