In the final weeks of March, we heard from Jose Bravo and Josh Morin, two QRadar experts that offered up insight into QRadar Network Insights (QNI). In this technical session Jose Bravo took a deep dive into network flows and went beyond the monitoring of standard netflows.
In case you missed it, you can watch a replay of the session here. We’ve also consolidated some of the FAQ from live audience members during the session. The answers are brought to you by Josh Morin and the experts in the QRadar Offering Management team. Please feel free to leave a comment or feedback below, the QRadar team would love to hear from the community.
Q: Does DNS Analyzer work with DNS Server Logs (not only from QNI)?
A: Yes. DNS Server Logs only gives you visibility into the DNS servers you manage, whereas QNI inspection will detect DNS traffic regardless of the end DNS server being communicated with. The supported sources are listed on the knowledge center here: https://www.ibm.com/support/knowledgecenter/SS42VS_7.4.0/com.ibm.qdaapp.doc/c_Qapps_QDA_prereqs.html
Q: Do QNI rules use the standard BB DNS servers fine tuning approach?
A: QNI will detect DNS traffic regardless of whether its communication is going to an approved DNS server or not. Rules could be created to compare the presence of DNS traffic communicating with servers not in the approved DNS server building block.
Q: Does QNI v7.4 need RHEL v7 license?
A: The licensing requirements are the same as any other virtual QRadar managed host. You are advised to install RHEL 7.6 first for QRadar 7.4.0 and then install QNI on top of that with a QRadar Software Node license. Full details can be found in the QNI Installation and Configuration guide: https://www.ibm.com/support/knowledgecenter/SS42VS_7.4.0/com.ibm.qradar.doc/b_qni_ig.pdf
Q: Is there a cloud version of QNI that captures traffic on the container level or deeper?
A: A software version of QNI could be manually installed in a cloud environment or VM etc. QNI supports raw traffic being sent to it in VXLAN encapsulated packets on the standard port of 4789. QNI will remove the VXLAN header and process the inner traffic as flows. VXLAN is encapsulating protocol used for mirroring traffic in the Azure Virtual TAP and AWS Traffic Mirroring environments. If you are able to configure mirroring of container traffic in VXLAN format and send it to QNI, you will be able to get that traffic inspected.
Q: How does QNI detect the Encrypted traffic?
A: When QNI observes TLS traffic it will extract information about the TLS session as well as any X509 certificate that it observes. JA3 and JA3S Hashes are also calculated on the session's ClientHello. Information from within the encrypted connection is not analyzed unless it is sent to QNI in the clear (e.g. thanks to external man-in-the-middle software, which is the preferred approach) or private keys are shared with QNI.
Q: What is the typical deployment scenario for QNI? SPAN->QNI->FlowProcessor?
A: SPAN or TAP > Collector (QNI) > Flow Processor > Console
Q: If you are currently running a QFlow Collector, does IBM recommend using QNI and the QFlow Collector together or could we remove the QFlow Collector and just use QNI
A: QNI and QFlow Collectors both inspect and give visibility into the raw packets on the network. The difference between them is the level of visibility that they are able to provide. Historically, the QFlow Collector was the only way to collect the raw traffic on the network and provide basic analysis and visibility of this traffic in QRadar. Now we have QNI, which has configurable "levels" of analysis, which means you can run in basic mode to do all the same things a QFlow Collector could do, or you can choose to go above and beyond and use the enriched or advanced settings for deeper visibility. If you choose to just use QNI you will get all of the same features and more.
Q: What are the resource requirements for virtual QNI?
A: The recommended minimum system requirements are documented here: https://www.ibm.com/support/knowledgecenter/SS42VS_7.4.0/com.ibm.qradar.doc/c_qni_virtual_app_sys_reqs.html
Q: Does QNI needs a different appliance from a typical flow collector? Or it is matter of licensing?
A: As of 7.4 we offer a software version of QNI. This would allow you to use off-the-shelf hardware. There are some advantages of using QNI-based hardware when scaling network traffic up to 10G.
Q: How does QNI deal with encrypted traffic?
A: We extract the metadata, payload and tuple information that we can from encrypted traffic. Not all encrypted traffic is useless. That being said it never hurts to have a MITM decryption appliance put in place.