Dec 2, 2021
90 Views
0 0

Understanding Multi-Tenant Deployments Within the SIEM Platform

Written by

The Home of the Security Bloggers Network
Home » Cybersecurity » Cloud Security » Understanding Multi-Tenant Deployments Within the SIEM Platform
The idea of multi-tenant infrastructure and deployments is not new in the cybersecurity landscape. For years, Cisco and Palo Alto firewalls and Citrix and F5 load balancers have supported the idea of a tenant-based deployment.  The idea of supporting tenants goes well beyond service provider models supporting several public clients in a shared infrastructure model. Many MSSP’s have deployed shared multi-tenancy to gain a greater financial scale and make the operations of the platform much simpler. However, like all good new ideas, security of most of these platforms becomes obsolete due to the lack of security segment per tenant.
Many corporations, school districts, and counties are becoming “service providers” within their domain. Many of these organizations are challenged with updated funding sources that impact their service delivery. Multi-tenancy has become necessary to gain some economy of scale while creating a next-generation services platform. Part of the multi-tenancy should entail several key factors for success:
These success factors need an effective measurement tool to ensure this new business process realizes the true gain of the investment itself.
For years, traditional security information and event management (SIEM) platforms helped clients with log management, reporting, and compliance audit frameworks. In the next generation SIEM, the merriness of the endpoint, network data, and cloud-based applications syslogs and alerts are part of the daily security operations workstreams. When a corporation decides to acquire a new company, part of the cost of onboarding is the requirement of data and security visibility. SIEM technologies can quickly ingress the data syslog via API, NetFlow, or connector agents.
Teams often wonder, should the newly collected data merge with existing data or is this a strong business case for multi-tenancy?
The journey for multi-tenancy starts with the business need for separation of data, reporting, cost, and compliance. Each of these areas is driving forces behind the segmentation. Due to ever increasing global compliance landscape, many business groups within a parent company may have separate mandates. Many departments may have a longer date retention requirement or possibly even a mandate to host them specifically in a country or GEO-Region dedicated by GDPR. CIO’s and CISO’s also need to have the means to segment compliance reporting by business group. For example, some of the business groups that accept credit cards need accurate PCI reporting and compliance framework while another section of the organization may handle employee health information governed by HIPAA. Using a next generation SIEM like LogRhythm, IT and information security departments can segment out the various log sources, retention requirements, reporting, and dashboard visibility by roles bases access-control and data segment.
Within the LogRhythm SIEM, corporations can deploy a multi-tenancy instance and they create sub- instances. Below is a screen capture showing an example of a Federal Government organization (Federal) and the sub-instances representing the various branches of the military. In each of the sub-instances, the client can segment out log capture, dashboards, alerts, and reporting. The SIEM will also make the job of charge back much easier by running monthly messages per second consumption and storage utilization reports.
Figure 1. Deployment Manager in LogRhythm Console
The “cloud” gained business and technology success years ago based on the promise that moving this new platform IT departments would be able to deploy applications faster while also reducing operation and start costs. Some of these initial promises were realized, while others were grossly under-estimated. The underlining miscalculation fell squaring on the cost of storage and post cloud data extraction fees. Clients that moved their workloads to the cloud in hopes of saving money relied heavily on the cloud provides the cost of consumption, bandwidth, and storage. In time, these costs like any utility began to rise. The sheer return of investment by moving to the cloud in many cases became more expensive than staying on-premises. With software as a service (SaaS)-based applications, those costs to the client also are heavily impacted by the cost of storage as well. When a SaaS provider quotes the client, part of their blending costs also accounts for their cloud costs. When a service provider like Amazon or Google raise their prices to the SaaS providers, those costs trickle down to the client base.
Cloud-based SIEM deployments today feature both a single-tenant and multi-tenant design. LogRhythm’s LR Cloud offering today leverages a client single-instance Google Cloud offering while other vendors may offer a less costly multi-tenancy shared model. The core differences between the two models are security and privacy. In a shared multi-tenancy model, both the data plane and control planes could be shared physically with other tenants. Many multi-tenancy platforms do offer data segment and encryption at rest as part of their services offering. In the single-instance cloud model, the client enjoys having their own data/control planes.
Within these instances of deployment do support multi-tenancy. However, depending on the deployment and vendor, the data itself may depend on a single store. Within a single store, all data resides on the same physical array while the data is partitioned off logically. If the client chooses to activate the multi-tenancy architecture, the client can use role-based access control (RBAC) for restricting access to the data sets, even though the content relies on the same store.
Like any utility, the back-end costs drive the front consumer fees. The decision not to support true data segment is due to the sheer cost and operations for the cloud service. If a client’s SaaS offering was nothing more than a sheer copy of an on-premises deployment, there would be no compelling reason for a client to move to the cloud outside of maybe reducing internal IT operations. The cloud offerings grew based on an “ease of use and lower cost” than on-premises.  That has turned out to be a debatable discussion by many. So, the idea of dividing the cost by department based on consumption began an important strategy for many companies.
If an IT department could “extend” their current cloud deployment by enabling multi-tenancy in lieu of standing up a brand-new instance by department, this could help organizations realize a greater return on the cloud investment.
Cloud service offerings are not designed to be one size fits all. Using multi-tenancy with your SIEM allows and extendibility of the platform while expediting the onboarding of new employees, departments and acquired companies. LogRhythm supports the multi-instance deployment with both the on-premises and LR Cloud offerings. Clients quickly can enable the sub-instance and begin to on-board new RBAC controls and segmented log sources. While one size does not fit all, multi-tenancy does provide options to help reduce cost and quickly meet new business objectives. Schedule a custom demo with one of our product experts to see how the LogRhythm can help support your specific use cases.
The post Understanding Multi-Tenant Deployments Within the SIEM Platform appeared first on LogRhythm.
*** This is a Security Bloggers Network syndicated blog from LogRhythm authored by Angela Romero. Read the original post at: https://logrhythm.com/blog/understanding-multi-tenant-deployments-within-the-siem-platform/

More Webinars

source

Article Categories:
Cloud Security

Comments are closed.