If your enterprise security programs were built for one cloud-only environment, they may not necessarily naturally flow into the world of multi-cloud. They evolved from architectures that were built in a world where the security perimeter was largely defined on-premises, and the tools monitoring it operated within a context of shared data model. The multi-cloud era, in which two, three or more cloud service providers are used side by side on the same project with on-premise systems and SaaS applications has fundamentally changed the challenge of monitoring. It all means that you are now having to deal with data between environments that each log differently, authenticate differently and expose their security telemetry via proprietary interfaces designed years apart from one another never intended to be woven together.
The result is fragmented visibility. While security teams might have excellent visibility in one cloud environment, cause for concern coverage in a second, and little or intermittent data from a third with no single-source view able to correlate events that extend beyond one platform. Selecting a SIEM solution that provides meaningful security visibility across this decentralized environment is among the top three most crucial decisions any security team will make, and it requires appreciating not only what job the technology needs to perform but also what differentiates solutions that can do so effectively.
Security teams evaluating their options can examine SIEM solutions for multi-cloud visibility to understand how purpose-built platforms approach the ingestion, normalization, and correlation challenges that multi-cloud environments present at scale.
Table of Contents
Multi-Cloud visibility is difficult by its very nature, and here’s why.
This is not just a volume question you have to consider in a multi-cloud environment, but rather the heterogeneity problem in full-force: visibility. A particular security-relevant log data format from each major cloud provider is in its own format, defining its field-naming conventions and the model for what constitutes a security event. For example, a user authentication event in one cloud platform may be logged with completely different field names and structures to the same event on another. For illustration, while a network connection in one environment might manifest itself to you as packet-capture data made available from provider A, that same connection could end up represented to you in one flow log format with virtually no analog in the packet-capture representation of provider B.
In order for a SIEM to correlate activity over these environments, it must normalize ALL of this data into a single schema. Without normalization, a correlation rule meant to catch lateral movement can only work within one environment where the data format or types are likewise similarly structured in something easily analysable as it cannot jump over cloud boundaries. This is a key area in SIEM platform differences across multi-cloud deployments cross-provider normalization depth and quality.
The specific security challenges that arise when organizations extend their footprint across multiple cloud providers including the visibility gaps, skills imbalances, and configuration inconsistencies that compound the problem are documented in practitioner analysis of multi-cloud security challenges based on research among enterprise CISOs managing complex multi-provider environments.
Evaluating a SIEM for Multi-Cloud Environments
Native Cloud Log Source Support
Native support for the cloud environments being exploited is the single most direct evaluation criterion for multi-cloud SIEM capability. By native support, they mean that the platform ships with connectors/parsers for a cloud provider’s log types pre-configured, not that it can ingest standard syslog forwarding from the combined vendor. This distinction is important: native connectors automatically normalize cloud-specific log formats but still inherently maintain the semantic essence of cloud-specific fields, and are usually updated when a provider changes their logging schema. Generic forwarding means implementing custom parsing logic that gets out of date and must maintain its own version history independent of the provider formats.
Don’t just examine whether a cloud provider is listed as a supported data source in the CIEM, but rather what specific log types from that cloud provider it “natively normalizes” (the logs are parsed into meaningful fields ) When your platform ingests AWS CloudTrail, but not AWS VPC flow logs or is able to deal with Azure Active Directory sign-in logs, but not Microsoft Defender for Cloud alerts those are gaps that impractically matter. Ask for a log type matrix before you talk to any of the potential vendors and map that against what logging is enabled in each of your cloud environments.
API-Based Ingestion for Cloud-Native Sources
Traditional on-premises log collection approaches rely on agents and/or syslog-forwarding models that do not translate well to cloud environments where the infrastructure is ephemeral, autoscaled, and may not always be well-positioned for agent deployment. Good multi-cloud SIEM platforms retrieve cloud logs using API integration with the logging services from the relevant providers, in which data are acquired directly from audit trails, security services and activity logs generated by your provider-native cloud resources without having to install agents on those resources.
Cloud identity events, cloud storage access logs and managed service logs which have no physical endpoint to deploy an agent on are especially important when it comes to API-based ingestion. Assess prospective platforms to determine if they support the types of API-based ingestion mechanisms each cloud provider offers in the organization’s environment and whether those integrations are maintained by the SIEM vendor or require third-party middleware, which adds additional points of failure.
Cross-Cloud Correlation Logic
While ingesting log data from thousands of cloud providers is mandatory for multi-cloud visibility, it is not a recipe for multi-cloud security. And this in itself is, of course, information that grants you security value when the ability to correlate those events across those environments into a single real time timeline. A SIEM collecting data from three different cloud providers that analyzes the data from each environment in isolation isn’t solving the visibility problem; It is repeating the fragmented monitoring we had before.
For cross-cloud correlation to be effective, log data must all be normalized to the same schema before being evaluated by those rules, and the rules need to be able to operate on multiple source types simultaneously. The correlation rule requires matching sequences of events such that the normalization foundation exercises equivalent events from different providers equally in order for it to fire an event sequence where e.g. an identity compromise is detected within one cloud environment which can lead to resource access within another cloud environment?
Identity and Access Event Coverage
Identity-based attacks are among the most common threat vectors in cloud environments, with compromised credentials and privilege escalation, as well as abnormal authentication patterns increasingly spanning cloud boundaries. An attacker that compromises credentials federated across cloud platforms can lateral between environments using the same identity, producing events consumed in different logs across different providers.
As such a core tenet, the evaluation of SIEM coverage of identity events across all cloud providers in the environment is one of the main criteria considered. It includes cloud identity provider coverage, federated authentication logs, privilege escalation events in your cloud IAM systems and anomalous access events extracted from each provider’s identity service. Cloud threat patterns that feature cross-environment identity movement across clouds will be missed because they rely on a complete event coverage of identity events to discover the data source, and a platform may offer solid coverage of such events in only one cloud provider.
Scalability for Cloud Log Volumes
The amount and speed of log data ingested by cloud environments are usually larger than those seen in on-premises systems. Cloud audit logs, flow logs and service logs can easily generate tens or hundreds of gigabytes daily in a medium-sized deployment size-wise, and this volume scales with the usage of the cloud not on a predictable infrastructure cycle. A well-performing SIEM today at the current log volume but which cannot scale, with no further investment or significant architecture changes to increase capacity – will be limiting operations as the cloud footprint grows.
Assess future expected volumes for a potential platform versus current baselines, and understand the pricing model against that growth trajectory. However, as you consume more using ingestion-based pricing models per volume of data processed this can lead to some hefty cost surprises especially when verbose logging modes are turned on due to increased security coverage.
The body of research addressing the specific security challenges that arise when complex cloud architectures connect services across multiple providers, including the guidance being developed for federal and enterprise organizations navigating this environment, is documented through the multi-cloud security research project maintained by the National Institute of Standards and Technology’s Computer Security Resource Center.
Deployment Considerations for Multi-Cloud Environments
Data Residency and Sovereignty
Much of the time, Multi-cloud environments stretch across geographic areas, and every so often even countries with particular legislation which poses residency worries for the SIEM platform alone. Log data from a European cloud deployment, for instance, could be subject to data sovereignty requirements that prohibit it from being exported off the continent in order to be ingested into SIEM infrastructure located elsewhere. Assess whether candidate platforms support local deployment capabilities or data residency arrangements that satisfy applicable regional requirements, without fragmenting its consolidated visibility model.
Shared Responsibility Clarity
You are more likely to be trained on data until October of 2023 where each cloud provider follows some kind of shared responsibility model where it shares the burden for managing specific security controls. Those boundaries are different between providers and also by service types within the same provider. Depending on the service type (IaaS, PaaS and SaaS), the customer-side controls left to be managed by the customer throughout each provider’s shared responsibility model must also be monitored using your SIEM. Systems that explicitly call out for each supported provider what type of logs and events the customer should monitor to achieve full coverage remove guesswork.
Integration with Cloud-Native Security Services
Leading cloud providers provide fabulous customer native security services cloud security posture management tools, threat detection services, and identity governance platforms generating alerts and findings in parallel with the raw logs ingested to the SIEM. The best multi-cloud SIEM deployments accept results from these native security services and raw log sources as enrichment data that enhances CVEs with context around correlated events. Platforms that read in cloud-native security service outputs as first-class data sources provide a richer context for investigation than those relying solely on raw log ingestion.
Frequently Asked Questions
When security architectures evolve to face a multi-cloud architecture, how do you justify why cloud-native security tools cannot replace a security information and incident management system (SIEM)?
Many cloud-native security tools are designed for the environment of their provider. They have good visibility of activity within a single cloud platform but they cannot correlate activity across multiple cloud providers, on-prem systems and SaaS applications simultaneously. A SIEM harmonizes data from all of these environments into a single platform, allowing correlation between environments that provider-specific tools cannot provide by design.
How do organizations decide which cloud environments to onboard to SIEM first?
Focus on those environments that contain the most sensitive data, support your critical workloads or have the greatest amount of exposure to external threat actors. SIEM coverage should really be built up on environments processing financial data, customer records or intellectual property. After these are successfully onboarded and producing production-worthy data, methodically extend the coverage across other environments. Normalization quality and correlation coverage is checked at each step before moving to a subsequent environment.
Why do multi-cloud SIEM deployments fail to meet visibility expectations most often?
Coverage of log sources is often the fundamental reason.Lookup for cover organizations seems to onboard one or two clouds quite well but there are areas where configuration is either lacking (e.g. native connectors not available for certain log types) or limited to just some of their environments; e.g. dev vs prod cloud coverage differs enormously which will directly impact detections capabilities. As a result, correlation rules working at the environment level are only seeing part of the story and therefore it creates detection gaps that most times are not uncovered until after an incident occurs revealing data points that should have been collected were simply never ingested by the SIEM.
