The truth about cloud security is in network traffic

During the cloud race an attractive promise was sold: less operational concerns and, by the way, security that "would already be included." Reality has been more complex. Infrastructures that change at every minute, overlapping APIs, ephemeral deployments in containers and multinational environments have created visibility gaps that security equipment cannot ignore.

Cloud security is not fixed by magic; it requires visibility. When protection tools in endpoints fail to detect advanced techniques or attackers deactivate local sensors, network traffic becomes an independent witness and often the only way to rebuild what happened. Organizations and experts have been remembering for years that the principles of network defence are still in force even in modern architectures: seeing traffic allows to detect anomalies that fragmented logos do not show.

A recurring obstacle is the heterogeneity of the native records of each supplier: different fields, incompatible structures and mass volumes of calls to APIs make standardization and analysis difficult. This is why many teams find value in network telemetry as "common denominator": metadata and network flows are essentially comparable between suppliers and, in addition, are something that security analysts already know how to interpret quickly. Add cloud inventory context - accounts, projects, VPC / VNet, cluster tags or pod - transforms these flows into meaningful signals and facilitates research.

To capture this evidence in a reliable way, there are well-documented mechanisms by large suppliers. AWS VPC Flow Logs and its mirror traffic function (traffic mirroring), the Google Cloud equivalent for VPC flow records and Azure Network Watcher capabilities are concrete pieces that allow you to get both wide vision and package depth when needed. You can check the official AWS guides ( VPC Flow Logs, Traffic Mirroring), by Google Cloud ( VPC Flow Logs) and Microsoft Azure ( Network Watcher NSG Flow Logs).

Network-based detection (NDR) emerges as a practical solution to unify and normalize this telemetry between clouds and on-premises. A well-integrated NDR approach adds contextual enrichment and exposes communication patterns that indicate exfiltration, command & control, cryptominery or side movements within clusters. In addition, the collection by traffic mirror and virtual taps is much less susceptible to manipulation by an attacker who has achieved privileges in a host.

What behaviour should be of concern to a defence team? Unusual outgoing communications to ports or atypical protocols, sudden transfer peaks from a service that should be stable, interactive activity within production containers (such as SSH or RDP sessions that should not exist in unchanging environments), access to APIs or unknown regions and signs of discovery between services are all relevant signs. In many cases these traces are the ones that allow you to connect an intrusion to your initial vector, for example a compromised container image or a malicious package introduced in the supply chain - a risk that authorities like the CISA have pointed out as critical for modern organisations.

The good news is that the way to operationalize cloud visibility is drawn: it starts by enabling flow and mirroring records to understand latency and fidelity of each source; it centralizes telemetry on a unique platform where it can be standardized and labelled with the context of inventory; it establishes base lines of behavior by role, service and destination in order to be able to distinguish noise from true anomalies; and it alters those rules iteratively to reduce false positive without losing valuable signals.

Evacuation monitoring and early detection are key. Instrumenting your VPC / VNet output points allows you to capture exfiltration attempts or communications with command and control infrastructures. In parallel, the inspection of TLS metadata, such as SNI or certified subjects, helps to identify APIs or managed endpoints that should be familiar for a service; the first access to an unknown domain or region must trigger an investigation.

It is also prudent to look for concrete patterns that report malicious activities: connections to cryptominery tools, regular and "slow but persistent" peaks (low-and@-@ slow) in data transfers, or the presence of interactive protocols where they have no room. When a corporate endpoint is compromised, the correlation between the records of that device and the telemetry of egress in the cloud may be the piece that confirms the extent of the incident.

We must not forget to validate the detection capacity: the simulation of adverse techniques and network team exercises make it possible to check that the expected signals actually appear on the platform and that the response playbooks work. This process of "putting in the attacker's shoes" keeps the teams honest and avoids blindly trusting controls that, in dynamic environments, can be outdated.

The discussion on these practices was the starting point for an episode of the podcast DefeNDR in which Corelight specialists spoke; the talk offers practical examples and perspective on how to apply NDR in multinational environments (you can hear the episode here: DefeNDR episode, and the complete series in the podcast page). If you want to deepen commercial solutions that combine network telemetry with context detection and enrichment, the Open NDR platforms offer a good starting point; for example, Corelight explains its focus on your Elite Defense page.

In short, cloud security is achievable if we look back at the flow of the network. Applying classic monitoring and detection principles to modern architectures, enriching data with inventory context and continuously validating the detection capabilities transforms visibility into a strategic advantage: it is not a question of demystifying the cloud, but of activating it to stop being a dark territory and become a controllable environment.

For those who want to support these practices with frameworks and recommendations, technical literature is abundant: the NIST explains considerations and risks of adopting cloud services ( NIST SP 800-144) and the ATT & CK matrix of MITRE remains a reference to understand techniques that adversaries use in both traditional and cloud environments.