BlogIf an incident occurs in the cloud but there are no logs to see it, does data really get exfiltrated? Yes—and the effects of a breach for both an organization and their customers can be heard far and wide.
Security information event management (SIEM) tools, which aggregate log data and detect intrusions using rule-based detectors, are a comprehensive way to collect and store incident data. While initially made for on-premises environments, SIEM's robust data collection is still an attractive cloud and hybrid security solution.
The catch is that SIEM is tricky to implement properly, making it at times more aspirational than attainable. Resource limitations and skills gaps, combined with network blindspots leave room for cyberattackers to evade SIEM detections or even disable them completely, leaving no trace of an attack in an organization's logs.
The Challenges of SIEM in the Cloud
While the volume of data that SIEM can collect is appealing, what was once a spray nozzle of event data and alerts turns into a firehose in the cloud. Complex cloud environments vastly increase the number of sources a SIEM tool has to draw from. In the cloud, workloads are ephemeral, making it hard for SIEM to provide complete coverage as workloads spin up and down with a click of a button.
Complex log management challenges in the cloud also means that SIEM doesn't scale well. Risks mount when SIEM can't scale to cover an expanding cloud attack surface. SUNBURST is a perfect example of this weakness: Attackers deliberately hide among DNS noise, knowing that, because of the high traffic volumes DNS produces, configuring and managing logs that might detect the attack is near impossible, even for the most sophisticated security teams.
This all amounts to a long list of SIEM logging limitations leading to including time-consuming configuration needs, high alert volumes, false positives that drown out real alerts, and high storage and staffing requirements to manage and prioritize it all. A reliance on easily evaded rule-based detectors adds further security gaps.
SIEM Applied to Shared Responsibility
Under the shared responsibility model, organizations are responsible for securing anything they store and manage in the cloud, from databases to application software and operating systems, while the cloud provider secures the cloud itself. Just like renting office space, a landlord might offer building-wide security systems, but a tenant is still responsible for locking office doors and windows to protect what's inside.
Both cloud providers and their customers need visibility in order to defend their respective territories. Unfortunately, because of the dynamic nature of the cloud, users who rely only on SIEM will lack visibility into critical workloads, IoT devices, and miss out on much of the cloud's east-west traffic.
It's worth noting that, under shared responsibility, even if an attacker were to enter a network on the provider's side, a cloud customer is still responsible for stopping the attacker after they move laterally into their purview—making east-west visibility crucial to cloud security.
A Cautionary Breach and Response Tale
The more-is-more nature of SIEM in the cloud, coupled with the inherent limitations of log data can turn an otherwise strong security tool into a cybersecurity false prophet. A recent data exfiltration attack illustrates some of the challenges of using SIEM effectively in the cloud.
The story unfolded when, two months after a breach disclosure, Krebs on Security reported that the victim had not enabled access logging on databases at the time of the attack. This left them blind: Because they didn't have a log of who had accessed their databases, they couldn't determine if customer accounts had been compromised or not. Without a doubt, database access is something they could and should have been logging, but it highlights an important point: SIEM requires a lot of management.
To work effectively, logging must be enabled and properly configured for a long list of cloud workloads and services. Even when properly and thoroughly configured, logging comes with an inherent time lag from collection to alerting, which can often provide attackers with the crucial window necessary to achieve their objectives. While not logging database access is clearly an oversight, there are many cases where logging can fail even when security teams do their due diligence.
Defending the Cloud: A Packet Analysis Approach
Network detection and response (NDR) gives comprehensive visibility across cloud workloads without the implementation hurdles and pitfalls that are inevitable with SIEM. By passively ingesting and analyzing packets without the need to set up logging for every aspect of the network, it can do so more efficiently, effectively and in real time.
ExtraHop Reveal(x) 360 provides the unique benefits of NDR across multicloud and hybrid environments. A key component of Reveal(x) 360 is Cloud Record Store which enables immediate access to in-depth network and threat information for the past 90 days. These records are stored securely and provide analysts with the ability to quickly determine root cause and remediate vulnerabilities.
An ExtraHop Reveal(x) 360 record is a complete snapshot of an individual transaction including source, target, behavior, activity, and any data accessed. Records go beyond summary metrics to provide granular, in-depth information that exposes anomalies and enables you to determine the exact timing of important events. This provides crucial context that SecOps and SOC analysts can't get with logs alone.
Linking Detections with Records for Faster Investigation
Detection cards in Reveal(x) allow security teams to easily investigate an attack. From the detection card, viewing metrics can help determine affected systems, and when needed, in-depth transaction records reveal what's happening at the packet level. This hierarchy of information gets security teams answers fast, avoiding needle-in-the-haystack log searches.
You can test out how these detections work in an actual cloud environment on our online demo. It just so happens that the ExtraHop Threat Research team has included a data exfiltration scenario.
In the demo, Reveal(x) detects data staging—a commonly used step before data exfiltration. The Database Data Staging Detection alerts you to the action in progress.
From there, you can drill down into database records and identify exactly what type of data and how much is being exfiltrated.
Covering Your Bases
SIEM provides a necessary foundation for robust cloud security, but the complexity of setting up logging across different cloud workloads (and in cases where logging is impossible or prohibitively expensive) can result in serious visibility gaps.
NDR with packet analysis and cloud record store covers what SIEM misses for detection and investigation. Want to use packets to stop a data exfiltration attack? Learn how SaaS-based Reveal(x) 360 eliminates blind spots and detects threats in cloud environments.
