As the nature of SOC goes, SIEM implementation needs to cater multiple customers with preferably a single view to manage all of them. At the same time, it is extremely important to keep the customers’ data separate, so the customers don’t end up seeing each other’s information. On the other hand maintaining a separate instance per customer would not be much efficient as the number of customers is expected to grow, and SOC engineers would need to hop from one instance to another, in order to view alerts and take appropriate actions. Over time it would lead to poorer response times, and waste of resources.
This article illustrates using QRadar in a multi-tennant environment, which allows managed security service provisioning to provide security operations services to multiple client organizations from a single, shared IBM Security QRadar deployment. Using such a deployment, the SOC can service multiple customers through a single deployment, increase efficiency and have much better response times.
User Roles in a Multi-Tenant Deployment:
In such a deployment, it is vital to ensure that customers see ONLY their own data, by creating customers’ own domains, which contain their own data completely separate and hidden from all other clients. Tenant-administrator roles can be created per customer/ tenant, who can then manage parts of day-to-day tasks that require configurations only related to that particular domain. SIEM solution provider on the other hand, handles the global administration tasks, like deployments and upgrades etc.
For example, the SIEM service provider, usually has administrators who manage the entire solution. These administrators have rights to creates users for all tenants, which can in turn manage their own tenant-specific deployments (like visibility into their own network and information, updating network hierarchy within QRadar, manage log-sources etc).
Handling the Events and Flows:
When events and flows come into multi-tenant deployment, all these events and flows as gathered based on which domains they come from, so they don’t mix up. If log are received from sources where no domain is found, they are assigned to default domain.
Architecture of a Muti-Tenant SOC
Ideally (but ofcourse depending on the situation), each customer/ tenant or domain has its own Event Collector, Event Processor, and a Flow Processor. It is highly recommended to use high-availability, so that in case a QRadar instance goes down, the other picks up from there and service does not experience any downtime.
The rules we create, are ofcourse tenant-aware. This means that rules can be fine-tuned per customer.