Traditional network address-based security controls aren’t as effective for the cloud or internal networks. Here’s what to do about these security issues.
Networking is a challenging field and made more so by the use of hybrid networks or combinations of internal and external subnets. Security controls based on network addresses have a long and distinguished history of success at protecting organizations, but they are also not without certain limitations.
I discussed the concept with Peter Smith, CEO of cloud security organization Edgewise Networks, Reuven Harrison, CTO and co-founder of network security policy automation provider Tufin and Nitin Agale, senior vice president of Product Strategy and Marketing at security solutions provider Securonix.
SEE: Kubernetes security guide (free PDF) (TechRepublic)
Scott Matteson: What are the latest challenges with network address-based security controls?
Peter Smith: In the cloud, operators have far less control over the network, and addresses are ephemeral so it’s too complex to manage address-based firewall rules.
For internal networks, organizations are increasingly adopting flat internal networks, which allow cybercriminals to move laterally (and lateral movement is now involved in 70% percent of cyberattacks according to an April 2019 threat report by Carbon Black)
Network addresses are short-lived in modern networks, especially in cloud and container environments. As a result, it is very challenging, operationally, to keep address-based policies up to date. The chance of network overexposure is high and so too is the chance that legitimate communications are inadvertently blocked–especially in a locked down, least-privilege environment, inside a cloud or data center.
There are security issues too because network-address based security systems cannot identify what is communicating, which makes it easy for malware and other attacks to piggyback on approved firewall rules i.e., “safe” addresses. For example, if an address is allowed to communicate, then any software on that particular host can piggyback on the approved policy–even malicious software.
SEE: Trend Micro VP talks cloud security, IoT risks, and ransomware (TechRepublic)
Reuven Harrison: Traditional network address-based security controls aren’t as effective in the cloud. As an organization evolves from using servers and [Infrastructure as a Service] IaaS to more advanced cloud services such as [Platform as a Service] PaaS and [Software as a Service] SaaS, IP addresses are abstracted away from the users. For example, a storage bucket in the cloud isn’t associated with any specific IP address. To write security policies for this kind of service, you use an identity and access management policy (IAM) rather than a security group or a firewall.
Furthermore, the traditional reliance on subnets and vlans for security zones and segmentation, which stems from the original design of internet routing, is no longer required in modern software-defined networks, which allow segmentation in a much finer granularity.
Nitin Agale: Traditional network controls were designed to keep bad actors out of internal networks. The assumption was that data sat on a server in an internal network (data center). With cloud transformation, this is no longer the case. As a result, network controls are ineffective.
With data continuously migrating to the cloud, mobile devices and security controls need to see a shift as well. Controls must be designed with the understanding that data resides in the cloud and can be accessed from anywhere using multiple types of mobile devices.
Scott Matteson: Why do those challenges exist?
Peter Smith: These challenges exist because address-based security only looks at how something is communicating, not what is communicating, so as long as an attack uses network pathways and protocols that are deemed “safe,” it can move laterally without any impediments.
Here are the specific challenges associated with the three most common network-address based approaches to micro-segmentation and zero trust:
NGFW (Next Generation Firewall): In this model, IT repurposes layer 7-based network perimeter firewall appliances to segment internal networks. It provides deep packet inspection, enabling it to offer more protection than layer 3 and 4 firewalls, but is significantly more expensive than software-based alternatives, especially when the ability to scale is needed in order to cover different geographies. Furthermore, inspecting a protocol in a packet can never conclusively tell you what software was actually communicating.
NGFWs are less effective in protecting containerized workloads because networking lives within the context of the device and, as an appliance, the NGFW doesn’t. They’re also difficult to use to control east-west traffic in the cloud, especially in AWS, due to the virtual device form factor.
SDN (Software-defined networks): With software-defined networks, the firewall is incorporated within the network fabric, giving it a distinct advantage providing layer 2 isolation otherwise unavailable with host-based firewalls and similar solutions. It’s also more difficult to bypass than host-based firewalls, because you can’t just switch it off at the host level. However, SDNs require a significantly larger investment to provide protection beyond general layer 3 and 4 firewalling, which increases the total cost of ownership. Also, it cannot provide protection to containers or bare metal cloud deployments.
Host-based Firewall Orchestration: Cost savings is a big advantage because it’s built into the OS, pervasive, and it provides broad protection, including internal communications between devices. It’s also convenient for in the cloud because there are well-established means to deploy software that doesn’t ex ist for an appliance form factor.
SEE: 4 essential things security experts do to protect their own data (TechRepublic)
Unfortunately, host-based firewall orchestration offers only layer 3 and 4 control, with none of the layer 7 capabilities you’ll find with NGFW. The biggest disadvantage, however, is that attackers can piggyback on approved host firewall rules.
Scott Matteson: Why are companies moving to flat internal networks, sacrificing the protective capabilities of separate segmented networks?
Peter Smith: Maintaining a flat network is operationally simpler than a segmented one which is expensive to undertake and prohibitively complex to manage and maintain. Flat networks provide ease-of-use for admins, because it is easier to control traffic in and out (single point of entry and exit for network traffic), and all applications can more easily communicate with any other application or data store on the network.
Unfortunately, this method also increases attack surface by allowing a greater, and unnecessary, number of usable pathways between applications, each presenting a way for infiltrators to move laterally within the network. And once an attacker gains a foothold inside the environment, there’s very little to stop them from moving laterally to compromise the entire network.
Scott Matteson: What is lateral movement?
Peter Smith: North-south movement refers to traffic traveling across the external boundary of the network. Lateral, or east-west movement, describes communications inside a network environment.
Lateral movement of threats is without a doubt the biggest cybersecurity risk that organizations will face this year.
Scott Matteson: What are the better options here?
Peter Smith: The alternative (and better) option is to use a software- and machine-identity based approach to protection, also known as zero trust security. Identities are created for each workload based on an immutable, cryptographic fingerprint made up of multiple properties such as a SHA-256 hash of a binary or the UUID code of the BIOS. This way, communication is allowed only after the identity of the software and devices are verified, blocking all unauthorized traffic.
Organizations should also base security policies on the identity of devices, hosts and workloads themselves. These identities can be built using immutable, unique and intrinsic properties of each workload, such as a SHA-256 cryptographic hash of a binary, the universally unique identifier (UUID) of the bios or serial numbers of processors.
Reuven Harrison: Use identities such as tags, labels, security groups, FQDNs and URLs instead of IP addresses to specify sources and destinations in your security policies. Use cloud-native security controls and rely on the cloud providers to enforce them for you. Add your own cryptographic security when the data is too sensitive to rely on the cloud provider
Nitin Agale: Analyzing and processing data for security at the edge, or inside the SDN, is crucial in optimizing organizational security and costs. It delivers more real-time analysis of data, enables rapid response actions, and optimizes cost by avoiding moving mass volumes of data across networks.
Scott Matteson: What are the advantages of identity-based security controls?
Peter Smith: While the three approaches above each have strengths and weaknesses, they all suffer from one fatal flaw: each depends on network addresses to build and enforce policies. As a result, they can’t disambiguate good software from malware that’s communicating over an allowed access control.
SEE: Security holes in 2G and 3G networks will pose a risk for next several years (TechRepublic)
Identity-based controls use immutable, cryptographic identities to protect any segment with a max of 7 policies compared with the thousands often required in the other models, which can seriously hurt network performance. Because it only allows approved software to communicate—spoofed or altered applications won’t have the same identity as the genuine binary—piggybacking is prevented, and only approved communications from verified machines and software are allowed. Everything else is blocked by default. So if an unauthorized script or any other attacker gains a foothold, they won’t be able to move laterally to do any damage.
Identity-based policies are portable because they are applied at the workload level and not at the network level. As a result, the workloads are protected regardless of where they run–on premises, public cloud, or even in containers.
Identity flips the typical security script, because identity-based zero trust is focused on the positive identification of known, approved software and devices instead of weeding out what’s bad. All traffic that’s not identified as “good” is denied by default.
Scott Matteson: What are some subjective examples of how security policies would work?
Peter Smith: For the sake of ease and management, ideally, there would be as few policies as possible and an identity-based approach to zero trust enables that. Rather than keeping track of the infinite number of threats and creating policies to keep tabs on them, a far simpler and more manageable approach is to create policies for what is allowed to communicate–a much smaller number–in effect creating a least-privilege environment. All other traffic is considered unsafe or unauthorized, and therefore, blocked.
SEE: Small cloud configuration mistakes can open up big security risks (TechRepublic)
Scott Matteson: How easy is this to implement and maintain?
Peter Smith: In our environment it’s simple to deploy microsegmentation and create zero trust. A lightweight agent is installed which doesn’t even require a reboot of the system. Within 72 hours, the machine learning system creates an application topology map and eliminates unnecessary pathways to reduce attack surface, often resulting in a 90% reduction. After the policies are automatically built, operators can microsegment the entire network with a single click, reducing typical microsegmentation deployment times from months to minutes, and again, greatly reducing the cost to implement.
Once deployed, the solution requires minimal attention. Policies can adapt to ordinary network changes, such as application upgrades and autoscaling.
“We’re at a point now where I only look at it once or twice a month,” said Steve Strout, global head of technical operations, Vonage.