IBM QRadar

Best practices and IBM recommendations about the use of QRadar solution with Office 365 and Azure

 

Things to know when designing your Virtual Network in Azure

 

1. Decide on QRadar deployment strategy – selecting a primary home for QRadar

QRadar offers impressive deployment flexibility which enables customers to choose the ideal model to meet their diverse business and security needs. There are 4 primary deployment models that customers can implement to secure resources across the enterprise, including Azure environments:

• On Premises
• Hybrid
• Cloud
• SaaS

 

On Premises

QRadar SIEM deployments on-premises are able to collect event and flow logs from Azure applications and services like Azure Event Hubs, Storage and Compute. With the QRadar Console and Event Processors located in a customer or partner managed datacenter, this deployment can collect security data without external installs.

 

Hybrid

QRadar also has the ability to extend its deployment footprint into the cloud enabling customers to install virtual QRadar appliances in Azure or other cloud platforms. The Azure Marketplace provides a single-click install method for QRadar customers to bring their own license and deploy QRadar appliances in Azure.

 

A common scenario is a customer choosing to deploy a single Managed Host appliance, like an Event Collector, in an Azure region to collect service, application, and infrastructure logs. Those logs are compressed, parsed, and coalesced at the source before transferring the data out of Azure and on premises.

There are many different available options for customers to deploy QRadar appliances both on premises and in the cloud for efficient collection of events and network traffic flows from Azure.

 

Cloud

QRadar can be virtually deployed on virtual machines running on IaaS cloud platforms like Azure. Cloud-first businesses are able to run an entire QRadar deployment in the cloud or across multiple clouds in an efficient way to provide security across a diverse enterprise. Customers can choose a primary cloud environment to run and manage a Console and commission Processors, Collectors, and Data Nodes around the center.

 

SaaS – QRadar on Cloud

QRadar on Cloud delivers the advanced security analytics capabilities of QRadar as a service, hosted on the IBM Cloud. While a dedicated IBM DevOps team operates and manages the Console and Processors, customers are able to either collect Azure logs via REST API or choose to deploy Data Gateway appliances in Azure to collect from external cloud environments. Data Gateway appliances are a supported QRadar Managed Host that can be deployed in Azure via the QRadar listings on the Azure Marketplace.

 

2. Designing your Virtual Network in Azure

When designing your virtual networks, we suggest that you position your QRadar Data Nodes and Event Processors in same subnet as your Console. The goal here is to reduce the layers between QRadar appliances to decrease latencies and operational complexities in your Azure environment.

 

3. Multiple Virtual Networks in Azure

If you choose to create more than one virtual network in Azure and deploy multiple QRadar Event Collectors in these subnets, we suggest that you implement VPC Peering as the connection path between the ECs.

A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. Instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, or with a VPC in another Azure account. Inter-region VPC peering connections are supported in Azure

 

VXLAN support for Network Interface traffic is a great new feature in QRadar 7.3.2 Patch 3. This feature allows deep visibility into your Azure environments with Azure vTap. Leveraging these integrations allows you to detect and stop advanced threats in the cloud – with unparalleled visibility into the raw traffic going to and from your instances, without the need to deploy additional hardware. Quickly configure Azure vTap and then perform threat hunting in your cloud traffic using QRadar.

 

Network Traffic Analysis in the Cloud - Azure vTap

Azure vTap is the first native network TAP functionalities available in Azure public cloud. This solution performs a deep copy of the inbound and outbound VM network traffic. This traffic can then be mirrored to any QRadar endpoint with flow processing capabilities, such as a Data Gateway or All-In-One console.

 This deep visibility allows you to write rules and generate offenses on any traffic coming and going from your cloud instance. You now have the ability to detect a whole range of previously invisible threat vectors – such as APT beaconing, network scans, port scans, DDoS attacks, large file transfers and more.

 

Configuring vTap in Azure:

Below is an example deployment making use of a QRadar Data Gateway and leveraging this capability in Azure:

 

In order to enable Azure vTap preview functionality, you will first need to request access to the preview feature by following the instructions at the Microsoft Azure website: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-tap-overview.

Once receiving confirmation from Azure, you will need to follow the following instructions to enable the virtual network TAP: https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-tap-virtual-network-cli.

 

At step 4, ensure that the configured virtual network interface is that of your QRadar console or data gateway endpoint.

Read this great blog by Holly Wright on how to configure QRadar to collect network traffic from Azure and AWS.

Deep Network Visibility into Azure cloud instances with QRadar Blog

 

Install WinCollect on QRadar deployments in Azure
In Azure hosted QRadar, the WinCollect icon would still be available and you can use managed as long as you have direct line of sight to the QRadar appliance and port 8413 isn't blocked by some resource group/security profile in Azure then yes they can run in managed.

I would guess that due to NAT or other cloud networks/port issues that you would be best off with going standalone. However, I'm not sure if these XP/Win7 boxes are in the cloud as well or external. You might need to clarify the location of the remote polling targets, are they also in Azure? My thoughts here is that if these are collecting a set type of event data that you would go standalone and allow these to forward in. This answer comes down to more infrastructure questions (network issues, locations, visibility) than actual collection. I believe that most large rollouts use standalone and some form of set collection that can come in via Syslog or TLS Syslog from the WinCollect agent or they post an Event Collector or Data Gateway in specific areas were infrastructure and networks cause issues with collection to act as a local collection point.

A lot of users find that going Microsoft Windows Event Forwarding (WEF) is an easy solution as it can be managed via Group Policy. It is a good idea to consider. I think WEF is supported on XP SP2, but not sure what point of sale OS levels we are talking about here without more specific info. WEF and local WinCollect agents are the easiest large implementation you can have as you can change XML configs and push changes easily without impacting WinCollect collection.

Optionally, if line of sight and ports are not an issue, you could go managed. However, with that size of deployment we find that customers typically prefer using standalone and SCCM for management. Things are easier now that IBM has released the Log Source Management app, but I think it comes down to available tools and how your team prefers to work. You can go WEF, managed, or standalone and the tools you have might drive this factor. We often tell users to mix/match collection in an 80/20 rollout if they can. No one ever seems to have a large network where one solution would fix. So, cover most of your network using the easiest collection, then cover the gaps with selected agent rollouts in standalone or managed, pending network (NAT, ports, line of sight) issues.


Microsoft Office 365 Management Activity API

QRadar leverages the Microsoft Office 365 Management Activity API to consume Azure Active Directory, Exchange, SharePoint, Service Communication, General Auditing and DLP events. This means, if a customer has subscriptions to those content types, they will receive audit events for those content types.

• Audit.AzureActiveDirectory
• Audit.Exchange
• Audit.SharePoint
• Audit.General (includes all other workloads not included in the previous content types)
• DLP.All (DLP events only for all workloads)

Microsoft's documentation provides a complete list of events from Office 365:
https://docs.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema .  

Read this great blog by Sophia McCarthy on building Pulse Dashboards with Office 365 security data
Microsoft Office 365 Dashboard using QRadar Pulse App

Coming Soon

Microsoft Azure
Graph Security API Alerts
Azure Services via Graph Security API

• Azure Security Center
• Microsoft Cloud Application Security
• Active Directory Identity Protection
• Azure Insights
• Azure Advanced Threat Protection
• Windows Defender Advanced Threat Protection
• Azure Sentinel
• Azure Information Protection

Active Directory via Event Hubs (early access available)
Windows DSM (support for native cloud agent collection for Windows/Linux VMs)
Event Hubs - Proxy Support


Contact
Patrick Routh
Offering Manager - QRadar Cloud Security
prouth@us.ibm.com