Next Gen Network Security topologies

Introduction

In this blogpost I want to discuss the benefits of using a Software Defined Network (SDN) solutions in the evolving network security landscape.

What, why and how: network security and micro-segmentation?

In traditional networking environments filtering (from now on I will call it “firewalling”) is executed at the edge (or perimeter) of each network. With “each network” I mean a layer 2 domain: a VLAN including one IP subnet. All nodes connected to that particular VLAN can communicate with others nodes in the same VLAN without being firewall’d, communication within a VLAN is open.

This being said: Traditionally from a network security perspective a VLAN is deployed for a group of nodes with the same “security policies”. Examples are clients (a.k.a. desktops), wifi, printers, servers, etc. And yes, they are only connected/firewall’d at the edge. The network security is offered from a high level only.
This topology has one mayor drawback (or flaw you may call it): when an attacker has surpassed the “edge-firewall” it’s just like a child in a candy store, because it’s one open world for them.

Let’s call this traditional approach a “perimeter-centric network security“.

A higher (more granular) level of security is demanded, but that’s only one part of the story.
Let’s continue: as said firewalling is handled by a perimeter device, which usually is a physical firewall. This topology put some limitations on the scalability, performance and flexibility of the solution, as all firewalling occurs on one (1) device and one device only. Stateful firewall appliances usually don’t have great reputation when it comes to performance: when the performance of this single device becomes insufficient, you will have to replace the device by a bigger one: You don’t have an option to scale vertically or distribute the load to other devices as firewalling usually is a stateful service. Replacing a in-service single (non-clustered) stateful device can cause a severe unwanted outage.

Another downside of perimeter-centric network security is that it can only block traffic based on network (TCP/IP) information. This is called the “5-tuple”-approach (source IP, source port, destination IP, destination port and protocol type). An approach which isn’t sufficient nowadays as it is not in line with the application logics: from a network security perspective web-, application-, and database-servers (called: “application-tiers”) are treated exactly the same as others servers (and are placed in the same VLAN). Traditionally the application logics have to be translated to the 5-tuple approach before a “sufficient” network security can be achieved (but still the security is applied at the edge of the VLAN).

No one wants to be overloaded with additional manual labor and/or complexity, so a bare minimum of VLANs and/or firewall rules are usually implemented. Traditionally the results are that there is no segregation between applications and/or application-tiers, sacrificing the involved risks as outline above.

A few years back micro-segmentation has entered the world of network security, which is explainable as: “splitting up a unified system in isolated segments” as stated by Tech-o-pedia. I will call it: firewalling on a per-node or application-base base, gaining a higher (and more granular) level of network security. The network security becomes more application aware, which is called an “application focussed network security”. But as with each innovation there is always a drawback and in this case it is the amount of administrative overhead (manual labor) and complexity involved with configuring and maintaining the micro-segmentation firewall rules.

As always it is a constant battle between maintainability and the level of security for every organization. The evolvement of a perimeter-centric network security into an application-focused network security doesn’t do this any favor without any help.

Beyond the 5-tuple approach

yes, filtering as for today still occurs by the 5 tuples. BUT: By using SDN techniques you can now convert other (non-networking related) objects to one of the 5 tuples in a dynamic way (no manual intervention needed). Which helps when creating application focused network security.

So we are now able to create firewall rules or group-membership based on, for example, MAC addresses, Virtual Machine names, VMware Cluster objects, tags, etc. Instead depending solely on IP addresses and ports which had to be manually translated from those objects.

This opens new doors when it comes to network security topologies.
But which one of those new possibilities to use, depends on the way you design (and automate) it. The automation part itself is a blog worthy, but for now out of scope.

Let’s continue talking about topologies

New (Next Gen) Network Security Topologies

When talking about network security, we’re talking about isolation, segmentation and filtering, traditionally based on “zones” (aka VLAN segments) and nowadays based on “applications”.

Network security topologies were traditionally based on “open” VLANs, where communication within the VLAN is open. Nowadays companies require a “zero-trust” security model, only allowing specified network communication were all other communication is prohibited (also within a VLAN). So, in the context of a zero-trust environment I want to explain it as outlined below:

• Isolation: Isolate application and/or environment (prod, test, dev) so they cannot communicate which each other.
• Segmentation: Only allow communication via a controlled path, for example only allow communication from the internet to the web-servers and not to the application and/or database-servers.
• Filtering: Only allow network communication on specified network (TCP/UDP ports) to a server. All other communication towards the server are denied.

A SDN environment usually uses an overlay-technique (like for example: VxLAN, GENEVE) and enhanced L3-L7 services (routing, firewalling, load-balancing, etc), which enables the application-focused approach. Each SDN solution bring its own set of possibilities, but I want to highlight the most used ones:

• By using a SDN (including an overlay-technique and virtualized appliances for routing, firewalling and load-balancing) you’re able to create a perimeter firewall, multiple segments (VxLAN logical switches) per application-tier in an automated way, which is in line with the application-focussed approach. This approach has one drawback, as it is feasible only for new deployments. When you have an existing (brownfield) environment where all servers are placed in one VLAN, you’re unable to migrate to this topology as application must be assigned new IP addresses (which usually is not allowed without breaking the application structure). You have to rely on other techniques to create an application focussed network security for brownfield environments.

• With a SDN you’re also able to create Access Control Lists (ACLs or firewall rules) based on MAC-addresses and/or other server-related objects, allowing firewall rules to be create per server. By grouping servers (which belong to an application tier) together you’re allowed to segmentate and isolate based on application-tiers and/or server instances. The insertion point of the firewall is not at the edge of the network, but it is inserted at the Network Interface Card (NIC) level of the server -or- the port of the physical switch to which the server is connected to. This approach allows you to maintain the current IP address- and VLAN strategy and it allows you to create an application focussed network security by relying completely on the firewall functionality of the SDN.

The above examples are true for both VMware NSX and Cisco ACI. Both also deliver enhanced routing capabilities by distributing a routing instance over multiple devices (switches or hosts), but that’s outside the scope of this blog.

I often get the question: When configuring an application-focused network security, do I still need a perimeter firewall? And my answer is: Yes!
When talking about network security you cannot rely on one vendor for your entire security, you still need another security vendor(s) for protecting the perimeter. So vendor A protecting the perimeter and Vendor B protecting the applications. This protects the environment in the case of the solution of one vendor has been compromised.

But this raises the question: “where to place my firewall rules?”
You don’t want to maintain the same rules in both vendor solutions. When designing a network security topology you want to create as few firewall rules needed, right?

The perimeter firewall is protecting (between) zones: datacenter, campus, wan, wifi, etc. which is called North-South traffic.
The micro-segmentation firewall is protecting (between) the applications in the datacenter, which is called East-West traffic.
The firewall rules created for the perimeter firewall should be (on a high level) protecting network traffic between the zones, all application related protection must be executed by the micro-segmentation firewall.

What about DMZs?

Everyone is familiar with perimeter-centric network security, as it has been out there for years. Physical separated De-Militarized Zone (DMZ) zones where created and tier-1 (web) servers were placed into them. If you think about it: The DMZ-zone is nothing more than a segment (an application-tier) in the application logics surrounded by firewalls. Do you see the resemblance with micro-segments?

From a functional level there is no difference between a DMZ segments and micro-segments. you can state that a DMZ topology is the precursor of the current micro-segmentation topologies. The difference is that micro-segments can be created more automatically by the use of SDN and automation. You can also turn it around: Are DMZ-zones still needed in a time where micro-segments-techniques are available?
I don’t think so, but a lot of people are sceptical about the idea that they have to rely on the SDN-techniques to accomplish their network security, They tend to forget that the SDN approach gives them a more granular and effective methods of creating firewall rules, which is more in line with the application-focused approach setting a higher level of network security.

New ways of doing old things.

I don’t know for sure which one was first Software Defined Networking (SDN) or micro-segmentation (the chicken-egg story), but what I do know is that those two are always mentioned in one sentence. And that’s for a good reason, because in a cloud-minded environment you don’t want to manually implement anything anymore (because of the manual labor, the human errors, etc): Everything should be provisioned in an automated way. And yes, that requires a completely different mindset: As a network/security engineer, you have to come up with standardized “building blocks” instead of opening a CLI and start configuring “things”. It requires that they can script their building blocks and that’s something which is really hard for traditional network/security engineer that have been working directly (from a CLI) with their networking devices for years (I’ve mentioned this in a previous blog before).

So, I now hear you thinking: “building blocks”, right .. and what do you try to accomplish? a higher level of security (micro-segmentation through automation)? #abracadabra

Let me explain:
“Automation” has all to do with a specific mindset: standardization. A more service-oriented mindset, which most (not all) network engineers are not familiar enough with. Programmers and/or scripters (millenials?) are very familiar with this concept/mindset, they create a script or program which executes a standardized (and carefully conceived) task. Does the term “DevOps” ring any bell?
So, we take this particular mindset and reflect them on networking.

From a network point of view, with a “building blocks” I mean a standard set of objects (appliances, firewall rules, VxLAN segments, routers, load-balancers, etc) which can be deployed in a repeatable manner.
An example of an isolation building block follows below:

Here are the firewall rules needed for isolating a group of servers

Source	Destination	Action
Group-A	!Group-A	Deny
!Group-A	Group-A	Deny

The (!) exclamation mark tells the firewall to negate the group: reversing the selection !Group-A equals who is NOT a member of the Group-A.

So this a simple building block, consisting 2 firewall rules and 1 security group. Don’t misjudge the building block by its size, the effects on the security level of its simplicity are enormous.

What this building block does NOT prescribes is who are the members (servers) of Group-A and this is exactly the point where it’s getting interesting:
These firewall rules are the same for all application(tiers) and/or environments, which makes the “building block” become repeatable. The effects of this building block depends on the members of the security group, but not on the firewall rules itself: the rules will be the same for all applications/environments.

This is very easy to script and makes your network security topology fail-proof. It lowers the amount of manual labor and (when deployed correctly) it can help the application owners setting their own application security so you (as a network consultant/engineer) doesn’t have to do it anymore.

I’ve created a blog about creating a security framework  which describes all the necessary building block in more detail.

And what about intent-based networking?

Intent-based networking is another leap forwarding in this SDN-era. Both VMware and Cisco are jumping into to this new technology where the “SDN” monitors the application and apply rules based on their observation. It captures the intended network communication for the applications and applies the corresponding firewall rules based on machine learning and compute algorithms. Intent based networking is in the line of the zero-trust application focused network security, so why hasn’t this solution been implemented on a large scale? I think it has to do with majority and acceptance: Do we trust those algorithms enough so we can run our business safely?

When it comes to trust AI, I always (for the fun) refer to the “chihuahua or muffin“-challenge. But in reality AI have beaten us (humans) when it comes to “image recognition”. So the algorithms are so advanced, they beats us! so why not rely on them? We are out-smarted ..

Ok, this is maybe isn’t the case for network security. But it is for sure “stuff to think about”. Only time will tell.

Conclusion

Nowadays network security demand both new technologies as a new mindset, including the ability to rely on these new technologies. The current state of the technology enable you to create a zero-trust application-focussed network security environment, but the lack of knowledge, the collaboration with application- and network-teams and adoption of these new technologies are withholding the implementation of these technologies. Resulting in a sub-optimal network security, leaving cyber security treads open.

Is this a new topic? no, I don’t think so! But I meet a lot of people who are afraid of SDN, sacrificing the current business security levels.