How to gain visibility into attacker behaviors inside cloud environments

How to gain visibility into attacker behaviors inside cloud environments

How to gain visibility into attacker behaviors inside cloud environments

June 10, 2019

The same technology that makes the cloud dynamic can have the opposite effect on an organization’s ability to implement detection and response in cloud environments.

Virtualized cloud environments supported by cloud service providers (CSPs) present challenges for visibility into attacker behaviors. Traditional detection methods in physical environments that involve logs, network and endpoint data cannot adapt to dynamic environments where virtual machines come and go in response to sharp increases or decreases in demand.

Organizations lack access to every layer in the cloud computing stack, and therefore can’t offer high-fidelity visibility when monitoring for attacker behaviors. Shifts in scope are also a challenge in cloud environments, as assets and applications move between systems that have varying levels of security monitoring.

The biggest problem facing the cloud is ensuring that only the right people have access to data stored in cloud workloads. Inside the confines of the enterprise network, misconfigured systems and applications aren’t as susceptible to compromise because of internal controls that limit external access.

In the cloud, a simple misconfiguration or exposure of system access means there are no defenses in place to stop someone from just taking everything. The potential for misconfiguration of access to cloud workloads is real, as evidenced by the Uber data breach among others.

For an even more interesting analysis of how attacks change the dynamics of threat detection, we can examine the ongoing attacks against cloud infrastructures by the APT10 group in a series of breaches dubbed Operation Cloud Hopper.

In the Cloud Hopper attack, the method of initial intrusion was cloud specific, but the attack behaviors within those cloud environments exhibited the same behaviors found in private cloud and physical data centers.

This is because all attacks have a lifecycle, from initial infection to data exfiltration. Preventing a compromise is increasingly difficult but detecting the behaviors that occur – from command and control to data exfiltration – are not. More importantly, when an attack is carried out in hours rather than days, the time to detect becomes critically important.

So how do you gain visibility into attacker behaviors in cloud environments? And where does the shared responsibility model begin and end between CSPs and cloud tenants?

Major CSPs are building out capabilities for authentication, control, and visibility. They have also started implementing better integration for third-party security vendors to enhance cloud security capabilities.

For example, Microsoft has introduced the Virtual Network Tap in Azure to enable the monitoring of all network traffic between cloud workloads. Vectra leverages the Azure Virtual Network Tap to apply machine learning models to cloud traffic and identify unwanted changes in system traffic that would indicate an attack in progress.

To learn more, read the white paper, Threat Detection and Response in the Cloud. This white paper helps you navigate through uncharted security territory by analyzing the attack lifecycle in the cloud, reviewing the top cloud security threats, and dissecting a real-world cloud attack. It also provides key takeaways for managing access, detection and response, and security operations.

About the author


Vectra® is the world leader in AI-powered network detection and response.

Author profile and blog posts

Most recent blog posts from the same author

Threat detection

How to Track Attackers as They Move to Your Network from the Cloud

December 8, 2020
Read blog post
Security operations

Expertise That Unlocks the Potential within Your Security Operations

July 21, 2020
Read blog post

A Tale of Two Attacks: Shining a Security Spotlight on Microsoft Office 365

October 26, 2020
Read blog post