5 Limitations of Network-Centric Security in the Cloud

Traditional security solutions were designed to identify threats at the perimeter of the enterprise, which was primarily defined by the network. Whether called firewall, intrusion detection system, or intrusion prevention system, these tools delivered "network-centric" solutions. However, much like a sentry guarding the castle, they generally emphasized identification and were not meant to investigate activity that might have gotten past their surveillance.

Modern threats targeting public clouds (PaaS or IaaS platforms) require a different level of insight and action. Since executables come and go instantaneously, network addresses and ports are recycled seemingly at random, and even the fundamental way traffic flows have changed, compared to the traditional data center. To operate successfully in modern IT infrastructures, we must reset how we think about security in cloud.

Surprisingly, many organizations continue to use network-based security and rely on available network traffic data as their security approach. It's important for decision makers to understand the limitations inherent in this kind of approach so they don't operate on a false sense of security.

To help security professionals understand the new world of security in the cloud, below are five specific use cases where network-centric security is inadequate to handle the challenges of security in modern cloud environments:

1. Network-based detection tends to garner false positives

Nothing has confounded network security as much as the demise of static IP addresses and endpoints in the cloud. Endpoints used to be physical; now they are virtual and exist as containers. In the cloud, everything is dynamic and transient; nothing is persistent. IP addresses and port numbers are recycled rapidly and continuously, making it impossible to identify and track over time which application generated a connection just by looking at network logs. Attempting to detect risks, and threats using network activity creates too many irrelevant alerts and false positives.

2. Network data doesn't associate cloud sessions to actual users

The common DevOps practice of using service and root accounts has been a double-edged sword. On one hand, it removes administrative roadblocks for developers and accelerates even further the pace of software delivery in cloud environments. On

the other hand, it also makes it easier to initiate attacks from these "privileged" accounts and gives attackers another place to hide. By co-opting a user or service account, cybercriminals can evade identity-aware network defenses. Even correlating traffic with Active Directory can fail to provide insights into the true user. The only way to get to the true user of an application is to correlate and stitch SSH sessions, which is simply not possible with network only information.

3. The network attack surface is no longer the only target for cyber attacks

Illicit activities have moved beyond the network attack surface in the cloud. Here are four common attack scenarios that involve configuration and workloads (VMs or containers) in public clouds, but will not appear in network logs:

User privilege changes: most cyber attacks have to operate a change of privilege to succeed.
The launch of a new application or a change to a launch package.
Changes in application launch sequences.
Changes made to configuration files.

4. When it comes to container traffic, network-based security is blind

Network logs capture network activities from one endpoint (physical or virtual server, VM, user, or generically an "instance") to another along with many attributes of the communication. Network logs have no visibility inside an instance. In a typical modern micro-services architecture, multiple containers will run inside the same instance and their communication will not show up on any network logs. The same applies to all traffic within a workload. Containerized clouds are where cryptocurrency mining attacks often start, and network-based security has no ability to detect the intrusion.

5. Harmful activity at the storage layer is not detected

In cloud environments, the separation of compute and storage resources into two layers creates new direct paths to the data. If the storage layer is not configured properly, hackers can target APIs and conduct successful attacks without being detected by network-based security. On AWS specifically, S3 bucket misconfigurations common and have left large volumes of data exposed. Data leaks due to open buckets will not appear on network logs unless you have more granular information that can detect that abnormal activity is taking place.

Focusing exclusively on network connections is not enough to secure cloud environments. Servers and endpoints don't yield any better results as they come and go too fast for an endpoint-only strategy to succeed. So, what can you do? Take a different approach altogether. Collect data at the VM and container level, organize that data into logical units that give security insights, and then analyze the situation in real-time. In other words, go deep vertically when collecting data from workloads, but analyze the information horizontally across your entire cloud. This is how you can focus on the application's behaviors and not on network 5-tuples or single machines.

About the author: Sanjay Kalra is co-founder and CPO at Lacework, leading the company's product strategy, drawing on more than 20 years of success and innovation in the cloud, networking, analytics, and security industries.