One of the things I am often asked by people who are new to the Aruba philosophy of building WiFi networks is “Why do I need another firewall? I already have one of those at my perimeter. "
This always makes me nostalgic, bringing back the days of the “vanishing perimeter” or the “de-perimeterization” of the enterprise network. You may recall the story - first popularized by the Jericho Forum in 2004 - goes something like this - “The firewall is going away, because ubiquitous WiFi and VPN connectivity have effectively rendered it useless.” Like all good stories, it had an element of truth. The enterprise perimeter had become more difficult to defend, and has continued to grow more so. But have we given up our firewalls?
Fast forward to today. What was becoming common back then - enterprise-owned laptops accessing the enterprise network via VPN - is now universal. But the problem has grown even larger, with the entire BYOD movement leading to most enterprise knowledge workers caring two, three, or even more, devices around with them. These devices jump from the enterprise network to the cellular/LTE network, to hotel WiFi, and back again continuously. Users refuse to be disconnected from their information, and managers are eager to keep their users productive despite the security risks involved.
Back at the beginning of the mobility movement, as it has now come to be called, Aruba Networks was just getting started. What could we do to ensure that customers would feel safe deploying WiFi networks? Well, many things, it turns out, but one of the key decisions that we made was to protect the “new perimeter” of the network with a session aware, role-based firewall.
Now, back to the question at hand. Why DO you need this second, role-based firewall? Since so much of internet security is couched in metaphors of war, let’s invoke one here. Many people think of the enterprise firewall as either a moat around your castle, or the front-line trench in a 20th century-style war. Use either analogy that works for you. Conventional thinking, then, would have Aruba’s access edge firewall as a second moat or second trench. Either way, it obviously adds value in the old security “belt and suspenders” type of way. But is it worth the trouble? Assuming my primary firewall vendor holds the line, aren’t I just tying up a bunch of resources manning a defensive line that will see no action?
The problem with this assessment, and these “second front” metaphors is that the nature of the enemy has completely changed. In fact, in many ways, the enemy is now you (or, more precisely, your users). As devices routinely move between the inside and the outside of your network, compromised ones will certainly return back home to share their malicious payload, or harvest data from internal resource for their new internet-based masters.
A better way to think about the Aruba Networks Policy Enforcement Firewall is to imagine each user having an individualized bubble of control surrounding them wherever they go in the network, much like the “boy in the bubble”. The bubble protected the boy from anything that could harm him. The Aruba firewall role is designed to work the other way around - protecting the network from any harmful effects of the user, wherever they roam inside the enterprise network. With application and web content aware capabilities, it allows an unprecedented amount of flexibility over what types of traffic touch the enterprise network, and what doesn’t.
Let’s look at an example to make this more concrete.
We’ll look at an enterprise that has some mission-critical embedded devices that have strict uptime requirements. These could be Point of Sale devices in retail stores, IV drip pumps in a hospital, or a factory floor full of robots and other production tools. Of course, they also have a mobile workforce that is constantly moving from the factory, to the HQ, to a hotel, etc. One simple Role-Based strategy would be the following:
Embedded devices - this role will have a strict set of controls that will allow it to communicate to the various resources it needs to do its job - back end transaction processing and reporting, and vital IT configuration management resource in the case of POS systems. Nearly all other communication with devices inside the corporate network would be blocked. Inappropriate communication attempts (in or out) will be logged for auditing by the Aruba firewall, as they may indicate a compromise.
POS IT Staff - people in this role are responsible for maintaining the embedded infrastructure. They are mobile, and responsible for adds, moves, and changes to the critical infrastructure. Their systems will have full access to the embedded devices, and most other corporate resources. So, before access is granted, we will be authenticating them to ensure that only the actual authorized user, using the actual authorized device, will be granted access to the privileged role. The same user, with a different device, would be given regular corporate access.
Since these systems are key to keeping the infrastructure safe, their role will be locked as much as possible. In practical terms, this means that we will configure application-level firewall rules to block access to really inappropriate applications, and block access to any websites which have dubious reputation scores. This will reduce the opportunity for compromise by malicious applications. Additionally, we will log all communication between these users and the embedded infrastructure, recording the user, time, day, and exact application traffic type. This information can be audited if the need arises. As a best practice, it would also be a good idea to lock down these systems with advanced endpoint security software.
Other corporate users - Since these users don’t need access to sensitive equipment, this role will have a much more relaxed security. All access to the embedded systems will be blocked, as will access to very dubious web content and dangerous applications. Otherwise, they will be free to use the network as necessary to do their jobs.
Guests - Guests or customers will be given a role with only internet access.
This is just one example of the many ways that PEF can, and does, enhance the security of Aruba WiFi customers. How do you use roles in your organization? Please comment below and get the discussion started!