P0LR Espresso - Pulling Shots of Cloud Live Response & Advanced Analysis

P0LR Espresso - Pulling Shots of Cloud Live Response & Advanced Analysis

Speakers: Art Ukshini, Detection Engineer, Permiso Security

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=xW9jKUuy3aE

Overview

In the rapidly evolving landscape of cloud security, defenders face a formidable challenge: the sheer diversity and fragmentation of logs across multiple cloud providers. Art Ukshini's talk, "P0LR Espresso - Pulling Shots of Cloud Live Response & Advanced Analysis," addresses this critical pain point head-on. The presentation introduces Polar Espresso, an open-source Python framework designed to normalize disparate cloud logs, offering a unified view for enhanced threat hunting, incident response, and detection engineering.

Ukshini, a Detection Engineer at Permiso Security, articulates how the current multi-cloud environment forces security teams to contend with "logs speaking different languages," leading to significant inefficiencies and increased investigation times. Polar Espresso aims to bridge this gap by providing a common linguistic framework for cloud activity, allowing defenders to focus on attacker behaviors rather than vendor-specific log formats. This tool is a crucial step towards streamlining security operations in complex cloud infrastructures, enabling faster and more effective responses to threats.

The talk underscores the necessity of a standardized approach to cloud log analysis, particularly as organizations increasingly adopt multi-cloud strategies. By offering a practical solution to log normalization, Polar Espresso empowers security professionals to overcome the inherent complexities of diverse logging mechanisms, ultimately enhancing their ability to detect, analyze, and respond to malicious activities across their entire cloud footprint.

Background

▶ Watch: Introduction to Polar Espresso and the cloud logging problem (0:00)

The proliferation of cloud services from vendors like AWS, GCP, Azure, Octa, and GitHub has revolutionized IT infrastructure, offering unparalleled scalability and flexibility. However, this multi-cloud adoption has introduced a significant operational hurdle for security teams: log diversity. Each cloud provider employs its own unique schema for logging events, utilizing distinct field names, object structures, and data representations for identical concepts such as an IP address, an identity, or an action performed.

This inherent log diversity creates a fragmented defensive posture. Threat hunters and incident responders are forced to "reinvent the wheel" for every log source. Investigating a compromised identity, for instance, requires understanding how AWS logs principalID and ARN, how Azure references a caller, and how GCP encapsulates identity information within productPayload.authenticationInfo.principalEmail. This necessitates constant mental translation and specialized query knowledge for each platform, leading to query fatigue and significantly longer investigation times. The speaker likens this to driving a manual car, constantly shifting gears between different cloud environments, sometimes even having to "switch in reverse."

Furthermore, detection engineering is severely hampered. Creating effective security detections often means building vendor-bound detections, where a rule designed for AWS cannot be directly applied to GCP or Azure, even if it targets the same malicious behavior (e.g., a known malicious IP address or a suspicious user agent). This results in repetitive detection development, maintenance overhead, and a higher probability of missing threats that span multiple cloud environments due to "lost in translation" issues. Attackers exploit this fragmentation, hoping defenders get lost in the noise, making lateral movement across cloud platforms harder to detect. The core problem, as Ukshini highlights, is not a lack of data, but that defenders are "forced to chase vendor specific field names... instead of attacker behaviors."

Key Findings

▶ Watch: Logs speak different languages: identity lost in translation (6:00)

The central problem identified and addressed by Art Ukshini is the fragmentation of cloud logs across different vendors, which leads to significant challenges in threat hunting, incident response, and detection engineering. This fragmentation manifests as logs speaking "different languages," where the same identity, IP address, or action is represented by unique field names and hierarchical structures in AWS, Azure, GCP, Octa, and GitHub. This "lost in translation" scenario results in slower investigations, repetitive detection rule creation, and a focus on log formats rather than actual attacker behaviors.

The key finding is that a unified, normalized approach to cloud logging is essential for effective security operations in a multi-cloud environment. By standardizing core event fields, defenders can overcome the current vendor-specific hurdles. Art Ukshini's primary contribution is the development of Polar Espresso, an open-source Python framework that acts as this crucial translator. It normalizes disparate cloud logs into a common schema, enabling universal IOCs, streamlined threat hunting, and a clearer understanding of identity activity across all supported integrations. Polar Espresso's ability to "brew" logs from various sources and present them in a consistent format fundamentally shifts the defender's focus from log parsing to behavioral analysis, significantly enhancing the efficiency and efficacy of cloud security operations.

Technical Deep Dive

▶ Watch: Impact: longer investigation time, query fatigue, manual IR (7:00)

The technical challenge addressed by Polar Espresso stems directly from the disparate logging conventions of major cloud providers. Art Ukshini meticulously illustrates this by comparing how AWS, Azure, GCP, GitHub, and Octa log fundamental event attributes.

For instance, consider the event name (the action performed):

• AWS: eventName
• Azure: operationName.value
• GCP: productPayload.methodName
• GitHub: action
• Octa: eventType

Similarly, tracking the source IP address reveals a similar divergence:

• AWS: sourceIpAddress
• Azure: clientIpAddress
• GCP: productPayload.requestMetadata.callerIp (requiring multiple object traversals)
• GitHub: actorIP
• Octa: ipAddress

The identity performing an action is also inconsistently represented:

• AWS: principalId or ARN
• Azure: caller
• GCP: productPayload.authenticationInfo.principalEmail
• GitHub: actor
• Octa: alternateId

These variations mean that a simple KQL query or Splunk search for an IP address would require entirely different syntax and field paths for each cloud provider, leading to "overloaded queries" and manual normalization efforts.

Polar Espresso is designed to eliminate this pain. It's an open-source, modular, and extensible Python framework. Its core functionality is normalization, which translates these vendor-specific field names into a common, consistent set of terms.

Key normalized fields include:

• Event Action: Replaces eventName, operationName.value, productPayload.methodName, action, eventType. This term accurately reflects an action being performed by an identity.
• Actor IP: Unifies sourceIpAddress, clientIpAddress, productPayload.requestMetadata.callerIp, actorIP, ipAddress. The choice of "actor IP" specifically differentiates it from a potential "target IP" in certain log contexts.
• Actor Mail: Standardizes identity fields like principalID, caller, productPayload.authenticationInfo.principalEmail, actor, alternateId.
• Service: Consolidates eventSource, resourceProvider, serviceName.

The tool currently supports AWS, GCP, and Azure integrations, with plans to add Octa and GitHub in future versions. The process of adding new integrations involves analyzing their respective log formats to identify common ground for normalization. The modular architecture is a critical design choice, allowing new integrations and custom field normalizations to be added without disrupting existing functionalities. This adaptability means defenders can tailor the tool to their specific investigation needs, choosing which field names to prioritize for visibility.

Logs are ingested into Polar Espresso as local JSON files. The tool can process individual files or entire folders containing multiple JSON files from different cloud platforms, even handling minor JSON errors. This offline processing capability makes it a robust solution for ad-hoc analysis and incident response without requiring direct API connections to cloud providers for log retrieval, although the speaker acknowledges this is a future consideration for broader enterprise adoption. By providing this "common language" for logs, Polar Espresso enables universal IOC creation and detection rules, fundamentally transforming how security teams interact with multi-cloud data.

Demo / Proof of Concept

▶ Watch: The ultimate goal: detect behavior, not log format (8:50)

The demonstration of Polar Espresso showcased its intuitive graphical user interface (GUI) and core functionalities, illustrating how the tool transforms fragmented cloud logs into actionable, unified insights.

Upon launching, users can "brew" logs by selecting individual JSON files or entire folders containing logs from supported integrations (AWS, GCP, Azure). The tool then loads these diverse logs, indicating the total number of events ingested. The main interface is divided into three key sections:

1. Event List (Detailed View): This central pane presents all loaded events with their unified field names. Instead of eventName or methodName, users see eventAction. Similarly, sourceIpAddress becomes actorIP, and principalID is actorMail. Other standardized fields include integration (identifying the original cloud source), sourceFile, eventTime, user_agent, service, resource, and IOC hits. This unified view eliminates the need for manual translation or understanding vendor-specific schemas, providing immediate clarity. Users can scroll through events and, by right-clicking, access IOCs tied to specific events.

1. Identity Activity Analysis (Bottom Pane): This section offers various analytical groupings and visualizations:

• Group by IP Address: Displays event count, first/last seen timestamps, unique actors, unique actions, and associated integrations for each IP. This allows quick identification of suspicious IPs and their activities across the cloud estate.
• Group by User: Provides similar statistics for each user, including event count, first/last seen, unique IPs used, and unique actions performed. This is crucial for investigating compromised identities or insider threats.
• Group by Action: Shows how many times a specific action was performed, its first/last seen, unique IPs, and unique actors involved. This helps in understanding common or anomalous behaviors.
• Identity Activity Timeline: A visual timeline displaying spikes in identity activity over time, aiding in the rapid detection of unusual behavioral patterns.

1. IOCs (Left Pane): This is where Indicators of Compromise are managed and displayed. The demo highlighted several features:

• IOC Creation: Users can define custom IOCs, choosing between integration-specific (e.g., for AWS only) or universal (applying across all supported cloud platforms). IOCs can be simple (e.g., targeting a specific IP address) or advanced, combining multiple fields and conditions (e.g., actorMail is "system anonymous" AND eventAction is "Kubernetes post" AND eventResponseCode is "0" for a successful, and therefore malicious, action).
• IOC Details: Clicking on an IOC reveals a statistical overview, including the total number of events, distinct users, IP addresses, actions, and services that triggered it. It also shows the first and last time the IOC was triggered, along with a list of all events tied to it, providing immediate context for alerts.

Additionally, the tool includes a search feature that allows users to quickly search for specific identities, IP addresses, or actions across all loaded logs. Searching for "system anonymous," for example, instantly displays all related details: associated IP addresses, actions performed, and services involved, similar to the IOC detailed view but focused on a specific entity. This capability streamlines the process of tracking known malicious entities or investigating specific anomalies.

The demo effectively showcased Polar Espresso's ability to transform raw, disparate cloud logs into a unified, searchable, and analyzable format, significantly reducing the cognitive load on defenders and accelerating the incident response process.

Defensive Implications

▶ Watch: Attackers exploit log diversity for lateral movement (9:20)

Polar Espresso offers profound defensive implications, fundamentally shifting the paradigm of cloud security operations from reactive, vendor-specific analysis to proactive, behavior-centric threat hunting.

Firstly, the core benefit of log normalization directly addresses the problem of query fatigue and fragmented investigations. Defenders no longer need to learn and adapt to multiple cloud providers' unique field names and log structures. Instead, they interact with a consistent set of fields like eventAction, actorIP, and actorMail. This standardization drastically reduces the time spent on data translation and parsing, allowing security analysts to focus their efforts on understanding the behavior of an attacker or a suspicious identity, rather than the intricacies of log formats. This leads to faster scoping, containment, and overall response times during an incident.

Secondly, the ability to create universal Indicators of Compromise (IOCs) and detection rules is a game-changer for detection engineering. Instead of developing and maintaining separate detection logic for each cloud platform for the same threat (e.g., a specific malicious IP or user agent), security teams can now build a single, lightweight rule that applies across AWS, GCP, and Azure. This not only reduces the development burden but also enhances detection coverage, minimizing the risk of a threat actor evading detection by moving laterally between different cloud environments. More advanced IOCs, combining multiple normalized fields (e.g., actorIP + eventAction + eventResponseCode), enable highly specific and accurate threat identification.

Thirdly, Polar Espresso empowers proactive threat hunting. By providing unified views of identity activity, grouped by IP, user, or action, and visualized through timelines, defenders can quickly spot anomalies, pivot between related events, and trace an attacker's steps across the entire multi-cloud estate. The search functionality for identities, IPs, and actions further facilitates rapid investigation of suspicious entities, providing comprehensive activity breakdowns. This capability is particularly valuable for identifying compromised identities and understanding their full scope of impact across integrated services.

Finally, the tool's modular and extensible architecture means that it can adapt to evolving organizational needs and new cloud integrations. Defenders can customize which fields are normalized and even add support for new log sources, ensuring the tool remains relevant as their cloud footprint grows. By turning "vendor chaos into behavioral clarity," Polar Espresso allows security teams to build a more resilient and responsive defense against the complex threats targeting modern cloud infrastructures.

Key Takeaways

• Log Normalization is Crucial: The primary challenge in multi-cloud security is the diverse and fragmented nature of logs across different vendors. Polar Espresso addresses this by normalizing key event fields (e.g., eventAction, actorIP, actorMail) into a common language, eliminating the need for manual translation.
• Faster, Unified Investigations: By providing a consistent view of cloud activity, Polar Espresso enables threat hunters and incident responders to investigate across AWS, GCP, and Azure without having to adapt to vendor-specific log formats, significantly reducing investigation time and query fatigue.
• Universal Detections and IOCs: The tool allows for the creation of lightweight, universal detection rules and Indicators of Compromise (IOCs) that work across multiple cloud integrations. This reduces repetitive detection engineering efforts and enhances threat coverage.
• Behavioral Clarity Over Log Format: Polar Espresso shifts the focus of security analysis from parsing complex, vendor-specific log formats to understanding actual attacker behaviors and identity activity patterns across the entire cloud environment.
• Empowered Threat Hunting: With features like identity activity timelines, grouping by IP/user/action, and comprehensive search capabilities, the tool provides enriched visibility for proactive threat hunting and rapid identification of compromised identities and suspicious activities.
• Open-Source and Extensible: As an open-source Python framework, Polar Espresso is modular and adaptable, allowing security teams to customize it to their specific needs, add new integrations, and evolve its capabilities as their cloud landscape changes.

About the Speaker(s)

Art Ukshini is a Detection Engineer at Permiso Security, a US-based company that focuses on universal identity protection, uncovering evil across all cloud integrations. Originally from Kosova, a country in Europe in the Balkans, Art brings a unique perspective to cloud security challenges. His passion for espresso, often enjoyed with the Yeti character, inspired the name for his tool, Polar Espresso, reflecting its purpose of "pulling shots" of live response and advanced analysis from cloud logs. His work at Permiso Security aligns with the goals of Polar Espresso, aiming to unify and clarify identity-related activities across diverse cloud platforms.