We’ve been talking about zero trust for a while. And so have many others! This makes sense considering how much of a threat cyber-crime has become. But… What do we mean by zero trust? Why are so many vendors claiming to have a “zero trust” solution? There’s of course a certain amount of the inevitable marketing behind it, but there’s also the fact that zero trust can be applied to many aspects of the organization. In fact, when adopting a zero trust strategy, one of the first aspects you should do is precisely to define your “protect surfaces.”
Protect surfaces? Yes, a crucial difference between zero trust and previous cyber security strategies is that, instead of focusing on defending against all potential threats, we’re going to define a set of “protect surfaces” and work towards securing them. I personally find this approach very interesting; instead of fighting the never-ending battle of combating every possible threat, we can define a strategy where we can gradually tackle the important task of securing important company resources. There are some good guides on how to prioritize what resources to protect based on your company’s business. I’ve added one of them in the resources section at the bottom.
The campus network as a “protect surface”
Once you’ve decided you’re going to adopt a zero trust strategy, you may wonder, "How important is the campus network? Is it something worth protecting or can I just secure endpoints and corporate applications and call it a day?" How to protect resources will ultimately depend on your business, but I do believe there’s a very significant percentage of organizations where the corporate network, and the assets connected to it, are something worth protecting.
Think about it. According to recent reports, as many as 75% of organizations have experienced attempted ransomware attacks in just 2023 alone! If we consider that the cost of recovering from these types of attacks can be measured in millions of dollars, coming up with a strong security strategy is key. Wouldn’t you feel safer knowing that all access is identified, lateral movement is limited to what is strictly required, and east-west traffic is constantly being monitored?
Adopting a zero trust architecture doesn’t need to be overwhelming
The popularity of zero trust has led to a wealth of excellent literature available for learning. I’ve added a few links at the bottom in case you want to learn more. The downside of the abundance of information is that it’s easy to get overwhelmed. Over the course of this blog series, I’m going to guide you through a pragmatic approach to securing your network. If you have a network managed by HPE Aruba Networking Central, you’ll be surprised about how many of the tools you need are already available to you.
In this blog series, we’ll cover the basics of zero trust and how you can use tools you may already have available to put this in practice. This first entry, Part 1, covers the basics of zero trust as well as implementation of identity-centric policy. Part 2 will focus more on for least-privilege access and continuous monitoring.
Three pillars for a simple zero trust architecture
A good way to tackle a zero trust architecture is by breaking it into three steps, or initiatives. These principles guide design and planning of infrastructure and workflows. The order in which you could implement these projects will depend on your organization, but “identity” does feel like a natural first step, so we’ll start with that one.
- Identity-centric policy: All access to services must be authenticated, authorized, and encrypted.
- Least-privilege access: The services you can access should not depend on where you connect from.
- Continuous monitoring: Access is subject to change at any point. Continuous monitoring is therefore required.
Identity-centric policy
At this point you’ve probably implemented an Identity Provider (IdP) in your organization to regulate application access. We’re going to leverage that same IdP when controlling access to the network. We’ll try to use the most secure method available for every device, but we’re also going to try and keep things simple for users and administrators. With that in mind, we’re going to focus on HPE Aruba Networking Central NAC (also referred to as “Cloud Auth”) for this exercise. As I hinted before, Central NAC is included as part of your Central subscription, so you should already have a very good head start.
The first thing you’ll need to do is “connect” Central NAC with your IdP. You can use Microsoft Entra ID, Google Workspace or Okta Workforce Identity Cloud. The instructions vary slightly depending on your IdP, but they’re simple and easy to follow. You can find them in the HPE Aruba Networking documentation portal:
Apart from the clickable links, I’ve added a video to the resources section for those of you who are more "visual" learners.
Onboarding smart devices (computers, tablets, etc.)
Certificate-based authentication is undeniably the most secure method to authenticate a user/device into the network. The problem? Not everyone has a PKI infrastructure and the corresponding tools to enroll all employee computers, tablets and smartphones into the network. The good news is that HPE Aruba Networking Central NAC includes all this and more as part of the service. Once you’ve connected your IdP with Central, it will provide a URL that allows the helpdesk team and even the users themselves to quickly enroll a user or device into the network. Check how easy it is in this short video: https://youtu.be/YHSGJrYndAk?si=K9-MUxxC-kGxSMVV
You will also be presented with a simple yet effective access policy that will allow you to assign every user and device to the right user role (more about this in the next section).
Onboarding headless wireless devices
Certificate-based authentication is of course the most robust authentication method, but using it is unfortunately not always possible. For those devices where you need an alternative method, you can also use MPSK (Multi Pre-Shared Key). We can share another URL for users to retrieve their unique MPSKs or we can generate MPSKs for those devices that aren’t associated with a specific user (for example, a printer, a thermostat, etc.). It’s as simple as that!
One key aspect of this approach is that even if the device is using a PSK (Pre-Shared Key) to connect to the network, all your monitoring, logging, etc., will display the user or device associated with that PSK — resolving concerns about “invisible” devices in your network.
Onboarding headless wired devices
For wired devices where you can’t use certificates, passphrases, etc., consider using an authorization policy based on the type of device accessing the network. This should be straightforward, as you can use the native profiling capabilities of HPE Aruba Networking Central to do this. Devices will be automatically classified based on static characteristics such as the MAC OUI, DHCP fingerprint, or HTTP User Agents, as well as more dynamic attributes, such as Applications, Domains Visited, and so on. Central will classify your devices with automatic or user-defined device tags, and Central NAC will assign a user role based on those tags.
Read Part 2 of this series to explore the final two fundamental precepts of zero trust architectures: least-privilege access and continuous monitoring.
Continue your exploration of zero trust
Zero Trust Made Simple Webinar Replay – See live examples of how to set up a zero trust architecture using HPE Aruba Networking Central. “(You must be logged in to your Airheads account to view. Not a member? Sign up here.)”.