Cisco has just announced its latest security initiative: Cisco Hypershield! There have been many questions about it, which is understandable. It is not a new device in the usual 19″ 2U format we install in our rack cabinets. It’s an unfamiliar concept, consisting of several relatively new technologies and a new way of thinking about the problem. So, instead of trying to summarize it in a single word, let me start from the beginning.
Once upon a time, firewalls were physical boxes with two, maybe three interfaces. Good and kind people were connected internally, while the evil, nasty hackers were on the outside – and perhaps a MailGateway or Webserver on a DMZ.
These firewalls fit perfectly into the IT architecture of the time, where our machines and data were housed internally – precisely what we needed to protect with our firewall.
As things evolved, we realized that not all outsiders were bad. There were also customers out there whom we wanted to invite into our business. Marketing, WebShops, and Self-service moved online, resulting in significant efficiency gains.
However, this also meant that the firewall had to be moved further into the company to segment the internal systems as needed. Systems with customer access, partners, and various internal units, like clients and servers, were separated on different firewall interfaces to control traffic between them.
It was also a time when an application typically ran on a single machine. In fact, multiple applications might run on the same machine. It was common to see a file and print server, AD, and DNS on the same server. Similarly, an SMTP server (mail between companies) and an IMAP server (clients’ mail access) might share the same physical machine. The firewall sat in the middle of it all, and by using IP addresses and port numbers, one could control access to these applications.
Things are different now. With the advent of cloud and containers came micro-services. This means that all the functions and services previously embedded in applications, like the mail server mentioned above, now appear as micro-services. Your SMTP and IMAP services run in separate containers and are not necessarily on the same machine. They can be spread across multiple servers, even different data centers in various parts of the world.
However, the biggest challenge is that multiple containers are likely running the same service for scalability and redundancy, meaning you never know where the functions are located. The services move around dynamically. It wouldn’t surprise anyone anymore if I said that I am currently sending and receiving my emails in Frankfurt but reading them from an IP address belonging to a data center in Ireland.
But where does that leave our good old firewall? Where do you place your firewall to control traffic, and how do you configure it when you don’t know where your applications and functions are located?
A paradigm shift – new technology and new combinations
We are facing a paradigm shift, and it’s becoming clear that our reliable old firewall can’t quite keep up despite cluster technology and NG features.
Cisco has wisely looked towards the cloud and container world, acquiring new technology and combining it in a fresh, innovative way. There are three primary technologies we will need to familiarize ourselves with in the future. Let’s start with a quick overview:
eBPF – Extended Berkeley Packet Filter
eBPF is a technology that allows dynamic injection of functions into an OS kernel without recompiling it. Unlike programs that run on top of the kernel, eBPF operates within the kernel as part of it. This means you can execute functions with minimal footprint and gain direct access to all system calls, kernel resources, and information. You can access data on active processes and libraries on machines, control access to CPU, RAM, disk, and, crucially, all network packets going in and out of the machine, as well as to and from individual processes and applications. eBPF offers numerous advanced features. For instance, you can create and use custom “tags,” eliminating concerns about IP addresses and port numbers. Additionally, if desired, you can allow or block traffic and redirect it, such as to a proxy.
Originating from the open-source world, eBPF has long supported cloud providers’ business models. In the past, even when multiple applications and services were on the same machine, the CPU was likely idle over 80% of the time, and the disk was only half full. This “resource waste” underpins the business model of cloud providers, who sell CPU cycles and disk space, not the hardware itself.
Controlling processes and resources has been crucial to making this model work. It wouldn’t be good if one customer’s process could kill another’s or read/write to another’s memory or disk. eBPF addresses this problem and can answer questions about system calls, active processes, libraries, and resources. We can leverage all these capabilities and information. We can control what each workload can do and utilize the information.
Remember Log4J in December 2021? A vulnerability appeared in a widespread library, causing many of us to spend our holidays checking machines for vulnerability. We simply lacked an overview. With eBPF, we have better visibility and can implement mitigating controls to prevent disasters, securing future holiday seasons.
Imagine thousands of small, interconnected baby-firewalls within a large eBPF domain. All your workloads, and eventually your network devices, will participate in this domain. With this kernel-level insight, we can create firewalls based not just on IP addresses and port numbers but also on processes, libraries, and resource usage.
We can define rules allowing a process on a workload in one part of the world to communicate with a process on a workload in another. There might be no need to send IP packets over the network if the receiving process isn’t running!
“But that’s just for our workloads; what about network devices?” – you might ask – and thank you for that!
DPUs (Data Processing Units – SmartNICs)
Cisco has a strategic partnership with Nvidia, a company you probably know for its high-performance graphics cards for gaming PCs and exceptional GPUs (graphics processing units). Nvidia also produces DPUs (Data Processing Units – SmartNICs) with the same high performance, serving as the network card’s equivalent to GPUs. DPUs are already present in several Cisco devices, and moving forward, they will likely become the norm rather than the exception.
Besides being incredibly fast, DPUs have a feature that plays a significant role in Cisco’s announcements: Dual-Path Technology. This is a result of thoughtful innovation.
The technology essentially sends all data to two data planes. One is for production, while the other simply drops the packets. However, we continuously measure what the outcome would have been for the packets in our “test path.” This allows us to test new rules, apply patches, and even upgrade our firewall “on the fly.” If everything looks good, we switch to the other data plane and call it production. An integrated test environment – what’s not to like? I can’t count the number of times I’ve sat in a dark basement, wishing all applications would still run after a firewall upgrade.
Oh, did I mention that these DPUs are designed to participate in your new eBPF domain? Voilà – firewall anywhere!
