Today I was reading about the new QRadar integration with the IBM BigData solution. Instead of writing down here, I decided to share with you guys a very nice video that summarize the benefits of this integration.
(Part 1) QRadar Basics and Big Data
(Part 2) QRadar BigData Extension:
I hope you guys enjoy the videos. You can also check more from the author in his youtube channel.
One of the main questions when designing the architecture of a QRadar environment is using a centralized (with or without clustering) or a distributed deployment. It means, should we create a cluster of QRadar in a specific network or should we distribute our collectors across the networks? As usual, the answer is: Depends.
The following pictures summarize the benefits and cons of the both cases.
In the Centralized scenario, all the servers and collectors are in the same network. It makes the deployment and management way easier since we have just one point of maintenance and one point to “care about”, and it is very important especially when we have a geographically spread environment. But having all the SIEM solution in one network means that all the environment will need to connect to the cluster. In other words, the firewalls will allow traffic between the QRadar cluster and any server. Considering that some collection methods involves windows authentications, it means that if someone get access to the QRadar cluster network, the person will have access to any device on the network. Another bad point of this kind of deployment is the network failure tolerance. Lets say that the router in the border of the QRadar network goes down, all the log collection will be lost.
The distributed collection usually takes more time (and money) to implement and requires more time/resources to maintain, since the appliances will be distributed physically and logically. But the advantages are clear. With a distributed deployment the main QRadar console will have access only to its’ collectors, and nothing more. It means that if someone get access to the main SIEM network, the person will be able only to send packets to very specific IPs (collectors), and since the QRadar collectors are completely hardened, the security risk involved on this deployment is very low. Another benefit of the distributed deployment is the network failure tolerance. Considering the same case of a broken router in the QRadar console network, in this case the collectors will not have connection with the main console and will buffer the logs. After the network connectivity being restored, the logs will be synchronized with the main console.
As you guys noticed, the Distributed deployment can bring some good advantages compared with the Centralized one. But each company is a different case. Is up to you as an architect decide which deployment will fit your client need.
Do you have any suggestion or comment? Drop us a line in the comments!
Hi guys, today I’d like to present you another very useful command which you can use on a daily basics. Sometimes there is a need of coping a file to your all managed hosts. There is a very easy way to do this by using:
/opt/qradar/support/all_servers.sh -p file
… this will copy the “file” to the /tmp directory of all appliances.
After the file transfer, you can use the tips on this post to run commands all across your environment regarding with the new files.
One example of using this command, is transferring your security policies to all the environment and after deploying the configuration using the all_servers script.
Do you have any use cases for this feature? Drop us a line in the comments!
IBM recently released the new “IBM Security QRadar Certified Deployment Professional” or also called ” IBM Security QRadar SIEM V7.1 Implementation”. For the most of the people certifications are just accomplishments to attach on their CV, but the real value of the certification is not the paper itself, but is the study to get the certification. Even people that work years with the product, when studying to the certification discover new features or new ways to work with the solution, and being certified (after the proper study) gives you the necessary confidence that at least you already saw all the features of the product and you are able to use the tool in its best way.
The new certification (code C2150-196) consists in a 90-minutes test containing 64 questions involving all the phases of the project. From installing the hardware to tuning the rules. As mentioned in the first paragraph, studying and getting certified will give you a broader vision about the product, not only the tasks that you are used. The test passing score is 70%, a high score compared to another certifications from IBM, and as it involves all phases of the project, you should dedicate part of you time to study the tool.
The best way to prepare yourself to the certification is exploring the tool. Don’t try to go to the certification having never even logged on QRadar. Another good source of information, is the study guide from IBM that you can find on this link. It basically provides you with all the topics of the certification.
A personal tip to you is focus in the following categories: Difference between the versions (SIEM, LogManager, etc); theory behind the offences (how it is generates, how to configure the rules, etc); Interface usage (where can you find the features, how to do things in the interface, etc); and Solution Architecture (Components).
Another suggestion for people who have budget for it, go for the IBM classes. I went to two QRadar courses (2 years ago) and both were very helpful and practical. The courses were filled with useful exercises and hands-on activities. The bad point is the prices, but usually the companies pays for the training. To learn more about the IBM QRadar course, check this link out.
After studying the study guide (or attending the official training), exploring the tool and practicing the theory, you will be good to go for the certification. To get more information about how to schedule your certification visit the official IBM learning center.
Sometimes is necessary to audit the configurations of the QRadar and find the people involved on the changes in the system. Those changes can be verified inside the “events” tab of QRadar (and filtering by the events from the QRadar device). Another quick way to find the audit information about the QRadar is checking it own logs. For example, to check the history of accounts added on the system, there is a quick command that you can execute to check who and when added new account. To get this information just execute the following command :
[root@MY_RADAR]# cat /var/log/audit/audit.log | grep ‘AccountAdded’ | less
You will get log lines such as the example below :
Jun 12 14:34:37 127.0.0.1 X&Y (7638) /console/JSON-RPC/QRadar.saveUser QRadar.saveUser | [Configuration] [UserAccount] [AccountAdded] ID: 24 | Username: ABC | Email: ABC@DEF | Description: | Role ID: 2 | Security Profile ID: 1
By analyzing the log line, we can verify that X&Y added new account ABC with the e-mail address of ABC@DEF at Jun the 12th at 14:43.
By the original QRadar configuration, all the appliances comes with a pre-configured firewall rules in the OS. For testing purposes we can simple deactivate the firewall using the command “service iptables stop” (to stop the firewall) and “service iptables start” (to turn it back). But sometimes we need to update the firewall configuration aiming permanent changes.
In order to change firewall rules on your appliance you need to follow the below steps:
- Connect through SSH to the appliance that you want to make modifications;
- Login using ‘root’ account;
- Edit one of the following files:
- Add your firewall rules in the file, for example:
- -A INPUT -i eth0 -s x.x.x.x -j ACCEPT
- Save the file with the ‘ :wq ‘;
- Run /opt/qradar/bin/iptables_update.pl so your changes take effect;
With those steps your firewall configuration is now changed and will persist even in rebooting cases.
Continuing the post about running commands across the environment, today we’d like to present you another very useful and powerful command. Gathering information about the appliances and servers can be a painful task, but QRadar can provide us with some good scripts to make this task easy and automated. For example, if you execute on your QRadar Console:
[root@MY_RADAR]# /opt/qradar/bin/myver -v
…you’ll get a lot of information about you appliance like :
- Appliance type,
- Core version of the system,
- Patch number,
- Is the QRM enabled,
- Is the appliance you ran this command is a console,
- What’s the IP address,
- What’s the kernel architecture,
- Information about CPU, Operating System and if this is HA host or not.
And here’s the tricky part: to get this information from all your QRadar servers and appliances, you can combine it with the “/opt/qradar/support/all_servers.sh” command, presented in the another post, and gather this valuable information from all your managed hosts. For example, we can run this command across all the servers and input the result in a text file:
[root@MY_RADAR]# /opt/qradar/support/all_servers.sh “/opt/qradar/bin/myver -v” > /root/info.txt
As you can see, with just one line we can gather information of all our servers and generate a raw report of our QRadar environment. Simple, isn’t it?