A Security Mindset Reset: Five Reasons Network Security Just Doesn’t Work in the Cloud
Making the leap to the cloud is not for the faint of heart. If you’ve done it, you know: the things you want most from the cloud – elasticity, velocity, flexibility – are the very things that break many of the practices we’ve used in data centers for decades. You can’t just lift and shift your IT shop to the cloud. This is especially true for security, and I’m going to take a look at why in this blog.
Traditional security approaches evolved in very static environments. Stable networks, managed servers, and monolithic applications gave rise to network-based tools that delivered security using connection information and packet data. Changes often required hardware which puts a natural brake on velocity.
Many of the steps that used to slow down deployments and help with stability are gone in the cloud. Freed from hardware constraints, executables come and go instantaneously, network addresses are recycled seemingly at random, and even the fundamental way traffic flows changes. You have to reset how you think.
Here are a few ways network-based security tools fall short when transitioning to the cloud:
1.) Traffic critical to security is not visible
Network security tools do a great job of protecting data centers from malicious inbound traffic. But when it comes to East-West and outbound traffic, network security is not up to the task. Here’s why:
- Internal (or “East-West”) connections account for 80% of total cloud traffic. Much of this traffic never even leaves the virtual machine. Traffic that doesn’t show up at a virtual switch or a span port can’t be seen by the network only tools. Cloud trends continue to disrupt expected traffic patterns. For example, instead of moving large amounts of data to a compute resource, cloud architects have gotten smart: they use lightweight containers to move to compute resources to the data, putting even more critical traffic out of reach of network security resources.
- With the pervasive use of third-party software services, the volume of internally-initiated connections (e.g. applications contacting external APIs) has dramatically increased. Traditional perimeter firewalls are designed to stop unwanted outside-in traffic. They’re terrible at stopping unwanted inside-out traffic.
2.) Establishing identity – for users and endpoints – is really tough
The cloud has changed a lot of things. But nothing has confounded network security as much as the demise of static IP addresses and endpoints. Endpoints have gone from physical machines to virtual machines and now containers. Everything is dynamic and nothing is predictable. IP addresses and port numbers are recycled really fast, making it impossible to know who or what is behind a connection just by looking at network traffic. Existing network and endpoint security solutions are crippled when IP addresses and port numbers can no longer identify endpoints.
At the user level, Cloud DevOps practices of using service and root accounts have been a double-edged sword. While they accelerate the pace of software delivery, they have also made it easier to initiate attacks from these accounts. The use of these accounts removes DevOps roadblocks but they give attackers yet another place to hide. By co-opting a user or service account (and then escalating privileges to root in some cases), cybercriminals can evade identity-aware network defenses. Even correlating traffic with IAM or Active Directory can fail to provide insights into the true user.
3.) Deep Packet Inspection (DPI) doesn’t work
When security based on simple network characteristics (addresses and port numbers) failed to stop increasingly sophisticated attacks, the industry responded with DPI (aka “next-gen firewalls”). These tools still add value in the cloud when customers use similar applications (as they do in SaaS models), but in IaaS and PaaS models, applications are usually custom-built. Because next-gen firewalls can’t understand custom applications (at least not without a herculean effort to build custom rules), they can’t detect attacks.
The other challenge is that there is a growing use of host encryption which makes any traffic analysis to identify applications difficult at cloud-scale using network tools.
4.) Other attack surfaces are missed
In this new environment, where network security isn’t as effective as it once was, non-network attack surfaces are an even more urgent concern. Here are a few examples that illustrate this point:
- User privilege changes and many application activities (such as a launch or a change to the launch sequence) can’t be seen on the network
- Containers have a number of attack surfaces that are outside the view of network defenses (see our CEO’s “Smitten by Containers?” blog on this topic)
- Automated capacity management is great for elasticity, but network security tools often can’t cope with the confusing intermix of here-today-gone-today services and cloud entities driven by changes in demand
5.) Nefarious activity easily blends in
Software increasingly looks like Lego® blocks. Pieces fit together easily and standardized services simplify development and deployment. But there’s a security risk hidden in this new approach: cybercriminals using the same standardized services are harder to detect with network only tools. For example, an AWS S3 bucket used to store stolen data before exfiltration looks the same as an S3 bucket supporting a legitimate app. Standardization makes blending in much easier and the bad guys can hide in plain sight.
Implications
Focusing exclusively on network connections won’t secure the cloud. Focusing exclusively on servers and endpoints isn’t any better because these entities come and go too fast for an endpoint-only strategy to succeed. So what are we to do?
At Lacework, we decided to take a different approach. We collect data at the VM and Docker level, organize that data into logical units that can give us security insights, and then analyze the situation in real-time. In other words, we go deep vertically when collecting data from machines, but analyze the information horizontally across all servers. This is how we can focus on the application’s behaviors and not on network five tuples or single machines.
Lift and shift is not an option. Security professionals need to look beyond network connections to secure their clouds.
The Lacework team has also paid special attention to the ease of deployment and daily operations. “Zero-touch” is our mantra and you can experience how easy it is to deploy our platform and get value automatically and almost instantaneously.
