Breaches, hacks, hijacking, data loss, and exfiltration are all problems that exist in most cloud architectures for a very simple reason: most IT technology was not originally designed with security as a priority. The complexities around application development, workload operating systems, networking protocols, and overall process management were all designed with different priorities in mind: functionality and resiliency. These tasks all need to work, and they need to survive failures of elements in the overall architecture, but securing these elements has generally been an afterthought.
Regardless of how applications are developed, how different OS’s are built and deployed, and how all of this is virtualized, abstracted, and managed, most of these elements need to communicate with each other. If there is no network, each application is an island. And most applications today are designed to be accessed by remote clients, across either a private network or across the Internet. This is required in any kind of cloud architecture, and any cloud native architecture simply won’t work without a network already existing to communicate across it. So, it can be argued that the most critical element of any overall cloud architecture is actually the network itself.
Due to the critical nature of network infrastructure in any cloud architecture, there are challenges and priorities which are specific to only the network layer of all architectures. The network has concerns that are completely agnostic to workloads and applications, which rely on the network. Some examples of these network concerns include:
- Reliability (the network needs to work)
- Resiliency (the failure of one or more network device should not cause a system-wide failure)
- Traffic engineering and quality of service (IP networks are, by design, “connectionless”, but there should be ways to engineer and prioritize different kinds of traffic)
- Scaling (networks should be able to evolve without hitting some resource ceiling)
Applications and workloads should not need to be aware of any of these details in order for them to use the network.
So what does this mean for securing the network and securing workloads? There are distinct considerations that I’ll explore, specifically the contrast between network security and network-based solutions and workload security and solutions like micro-segmentation.
A brief history of network security
Since security is always the late-comer to most cloud architectures, security and network segmentation have traditionally been implemented at the network layer. Since the network is the critical infrastructure in the overall architecture, it would appear to make sense to apply security and micro-segmentation solutions there.
If you roll the clock back several decades, security in IP networks originally took the form of access control lists (“ACLs”) on routers and switches. Network devices generally deal with traffic on a per-packet basis, so as packets arrive at a router or switch, these ACLs are checked to make decisions about whether to allow or block a packet from being forwarded.
This approach was then outsourced to dedicated network devices – firewalls – which originally used the same basic approach. Since all IP packets contain information in their headers that indicate its source and destination, in addition to TCP or UDP numbers that indicate what type of data is present in the packet’s data payload, a firewall uses this information to make forwarding decisions based on their own access control lists. As the network deals with packets, it made sense to let the network deal with security and micro-segmentation as well, freeing application development and systems teams to focus on other concerns.
However, it is generally easy to fool a packet-based firewall. It is not too difficult to “spoof” addresses and TCP/UDP port numbers in an IP packet, which results in a packet that can easily mask what is contained in its data payload. So, session-based firewalls evolved to focus on mapping all packets in a given flow to a unique session, and to monitor the behavior of that session based on what application it “thinks” it is associated with. These firewalls didn’t have full visibility into each packet, but they compare how those packets and sessions behaved with application baseline behaviors, looking for anomalies.
Later, so-called “next generation” firewalls appeared, which apply far more intelligence into identifying what is contained in a packet, what application it is associated with, what user it is associated with, and other details that indicate a security breach. But all of these details are occurring in-line in the network, not in the source or destination workloads themselves. Firewalls have no idea what is going on at the workloads that are sending and receiving these packets, unless they are somehow communicating with some central tool that is also monitoring workloads and applications and then steering selected traffic to the firewall. But this can be complex to deploy, so firewalls are often simply sitting in the network, waiting for packets to arrive.
Network security is different than workload security
In parallel to firewalls making decisions about what packets can and cannot be forwarded, routers and switches have their own security concerns, which are a result of the same basic problem: Security was not a primary concern when networking protocols were originally designed.
TCP/IP and dynamic routing protocols that are used to forward packets, such as BGP and OSPF, were designed with the same basic goals as applications and workloads: functionality and resiliency. Security was not a priority at the inception of networking. Security and micro-segmentation became a priority at a later stage of network evolution, and network security solutions have been used to address security concerns that are specific to networking. Security is not just a concern for workloads and applications. There are security concerns in the network that workloads and applications have no visibility into.
As a reminder, these are just a few examples of security challenges that exist in the network-layer of any cloud architecture:
- Traffic engineering
- Denial of Service (DoS)
- ARP spoofing
- BGP authentication
- Traffic redirection
- Man-in-the-middle attacks
- Bogus route propagation
- First-hop router hijacking
- Session cookie hijacking
The items in this short list are all security concerns specific to networking, not to workloads or applications. For example, traffic engineering challenges are addressed by technologies such as MPLS, and the reliability of label distribution protocols. Denial of service is a significant problem which is often addressed via the use of BGP communities exchanged with ISP routing peers. ARP spoofing is a problem in which routers change their mappings between Layer-3 and Layer-2 addresses, causing the destination of traffic to be hijacked. BGP authentication requires something like RPKI to encrypt information exchanged between BGP peers, to avoid problems routing across the Internet. And so on. Networking has its own specialized vocabulary to deal with security problems that are unique to the network layer of any cloud architecture.
These examples are just some of the primary security concerns of network architectures, not of workload or application architectures. Application development and systems teams generally have no visibility into these network security concerns, because they should not need to. When a workload’s OS uses iptables, for example, to send or receive a packet, they don’t need to know if BGP is somehow being hijacked between ISPs in the network somewhere. Workloads and applications are concerned with workload and application security, not with network security.
Networking security solutions are not workload security solutions
What this means is that tools designed to address networking security challenges are not usually the appropriate tools to address security and micro-segmentation challenges at workloads or applications. Workload security often requires not being limited by scale: deploying thousands of workloads across multiple clouds should not be dependent on any one network-layer tool to somehow deliver application-level security to those workloads.
Workloads often live-migrate across Layer-3 boundaries, or between clouds, and workloads should not be dependent on network-layer tools somehow tracking these migrations in order to enforce workload security and micro-segmentation. Applications rely on dependencies across workloads, and these dependencies are often not visible to network-layer tools, so defining a ringfence around applications should not be limited by the network’s lack of visibility into full application dependencies.
Some networking vendors will propose their SDN solutions as solutions to workload and application security and micro-segmentation requirements. But these tools reside in the network or hypervisor layers, and these tools were designed to address priorities at those layers: such as automation, virtualization, network analytics, network overlays and tunneling, and authentication between dynamic routing protocols. SDN tools were not designed to provide security and micro-segmentation to workloads and applications at scale.
They may also propose firewalls – either hardware or virtualized instances in a hypervisor – as solutions to workload and application security requirements, arguing that next-generation firewalls provide full Layer-7 visibility into network traffic. However, any firewall is only useful once packets reach it. Firewalls don’t have the ability to influence the behavior of applications or workloads at their source, instead only waiting for packets to arrive at a firewall’s port. Firewalls enforce network security and micro-segmentation as traffic is in transit – north-south traffic. They don’t enforce application or workload security at the source – east-west traffic. Both solutions are required for a true Zero Trust architecture to be realized, but one layer of the architecture cannot provide full security and micro-segmentation to the other.
Networking teams should not be tasked with workload or application security
Network teams focus on networking tasks, which are different than workload or application tasks. These tasks involve terms relevant to those teams, such as Layer-2 and Layer-3 translations and forwarding mechanisms, routing protocols like BGP and OSPF and how they peer with each other, and their own authentication mechanisms. Solutions to Layer-2 networking problems, such as spanning tree and ECMP, also have their own security priorities. Networking tools like SDN and virtualized network appliances deployed in hypervisors are focused on issues specific to networking priorities. In none of these solutions are security risks within a workload itself a priority.
What this all means is that when designing security and micro-segmentation solutions for workloads, those solutions should be deployed there: on the workload. Network tools have priorities that differ from workload or application concerns. Network security tools will always exist, focusing on enforcing north-south traffic, in and out of the overall network fabric. These networking tools will be deployed on networking devices. Workload security should be deployed on the workloads themselves, and these will focus on enforcing east-west traffic, between workloads and between applications.
Keeping each layer of the overall architecture focused on the priorities specific to its own layer will allow each one to be agnostic to the other, with neither layer imposing limitations on how the other operates or scales. The result is a fully realized Zero Trust architecture.
Many cloud native architectures do follow security best practices and will deploy workload security solutions on the workloads themselves. But old habits die hard, and often when existing IT environments are migrated from data centers to cloud services, the traditional approach of using networking solutions to try to enforce workload security will also be migrated, with the result being a network layer which is often blind to east-west security requirements between workloads and applications. The result is not Zero Trust.
This is where Illumio fits into the overall security architecture. Unlike traditional approaches to network segmentation, Illumio enables security and micro-segmentation to be enforced directly at the entity you are trying to secure and segment: the workload itself. Doing so allows workload and application security and micro-segmentation to scale and evolve without any dependency on where these reside on the network. And this allows workloads to reside or migrate anywhere across on-premise data centers or across cloud providers.
A multi-cloud architecture will create one broad network fabric, with reachability across all of the underlying networking topologies. Security and micro-segmentation should follow the same guideline, providing one consistent and scalable solution across the same network fabric, end-to-end. Zero Trust means that the security trust-boundary is pushed out to every single workload and application that needs to be protected, and that goal should not be limited by trying to enable this goal in any different layer of the cloud architecture.
To learn more about these topics and how Illumio solves workload and application security:
- Watch this quick overview video on The Evolution of Segmentation
- Check out this on-demand webinar: Unlock Security from the Network: Segmentation Made Simple