4 easy ways to work toward a zero trust security model
4 easy ways to work toward a zero trust security model
Building toward a zero trust network is a capability most organizations possess. We look at how to get started.
There has been a lot of talk about zero trust networks lately, but little consensus about what they actually are. Similar to DevOps or software defined networking, that zero trust means something a little different to everyone is becoming clear. That said, there is one thing we can all agree on: The network cannot be trusted.
At its core, zero trust is a security model. Any system operating in a way that completely removes trust from the underlying network is said to be conformant to the model. As you might imagine, there are many ways to accomplish this goal, some more robust than others. All zero trust implementations, however, rely on extensive authentication and authorization processes that can be sprinkled liberally throughout the infrastructure.
There are few commercial options available in the zero trust space, and even then the options are far from comprehensive. Most present vendor lock-in challenges, and none provide a full end-to-end implementation, which would require complexities such as secure introduction and workload authenticity. That said, building toward a zero trust network is a capability most organizations possess, and doing so will help ensure that they are well-positioned to weather the architectural shakeup that will no doubt occur in the coming years.
Building toward zero trust
The zero trust model, originally conceived by John Kindervag, works to solve the majority of challenges in modern computer network security. Lateral movement, in particular, is practically eliminated under zero trust, as are most phishing attacks and other commonly successful vectors. Despite the fact that ready-made commercial solutions are hard to come by, there are a handful of low-hanging fruits to be had on incrementally improving security posture by using the lessons learned from the zero trust model.
1. Stop deploying unauthenticated services.
Retrofitting security is hard. Ensuring it's applied moving forward is a lot easier. By drawing a line in the sand and ensuring all future deployments are compliant, the accumulation of technical debt can be avoided in an impactful way.
Because all traffic on a zero trust network must be authenticated and authorized (regardless of whether it's between servers in the datacenter or clients and enterprise resources), a simple step forward is to disallow deployment of new services that don't leverage strong authentication. Requiring strong authentication rather than simply inspecting the source address of a request goes a long way in mitigating lateral movement as well as the dangers associated with WAN communication. This is particularly important in cross/hybrid cloud deployments.
2. Start collecting device data.
The cornerstone of a zero trust network is knowing what to expect. The network should operate in a whitelist mode, where every flow is enabled and authorized by its policy, without which it doesn't work. This is, of course, a non-trivial challenge. The key to solving it is knowledge of exactly what you have plugged into your network, and what that thing does.
We refer to this source of truth as the device inventory. The device inventory is a database of all the physical assets in the network (whether that be a server or an end-user device), joined with information about their purpose or intention. For instance, a server may be annotated with its role within the datacenter, and a client device might be annotated with the user or department to which it was assigned. Once gathered, this data is used to gain confidence on whether or not an access request to a particular resource is authorized.
3. Start configuring host-based firewalls.
Zero trust networks typically are built from the inside out. Rather than starting with a firewall and then building data behind it, start with building security controls around the data or resource itself. Although host-based firewalls don't conform to the zero trust model on their own (they usually rely on data delivered by the network to authorize requests), they present a good starting point for changing the way you think about network security.
This is not to say you should poke holes in host-based firewalls until the application works. Instead, strive to understand the exact requirements of each application, and codify them in the local firewall. Of course, this can become tedious quickly, so leveraging some sort of automation or process (even if it's as simple as "here are the firewall policies for hosts of type X") will be required. Once this is done, you'll likely find that the data sources required to build a true zero trust network are within reach.
4. Start asking more questions.
Perhaps the easiest way to start building a zero trust network is simply to start asking more questions. Zero trust networks are all about a shift in thinking—things that were once trusted no longer are. As such, shifting the way that an organization thinks and approaches systems design will not only strengthen their security posture, but also will go a long way in minimizing disruption when the inevitable shift to zero trust occurs.
Good questions to ask are: Would this service or host be vulnerable if an attacker were to plug into its switch or VLAN? If so, why? Another good question may be: If this host was compromised, what would the attacker gain access to?
Above all, the questions should be designed to better understand the communication requirements and exposure of the new service or resource. By asking the right questions, you'll begin to shift organizational thinking toward the principles that the zero trust model embodies, in addition to improving your overall security posture along the way. Building and referencing a structured threat model is also helpful. Doing so will ensure the questions asked are appropriately targeted and scoped.
Building a zero trust network is absolutely possible with today's technology, but not without significant expense, whether that comes in the form of commercial software, engineering hours, or both. As more and more options become available in this rapidly growing area, an inevitable tipping point will be reached. Being a straggler in this arena is ill-advised. Understanding zero trust concepts early on— and ensuring that new technology is deployed with these concepts in mind—is critically important in preparing any organization for the security transformation to come. Without sufficient preparation, the costs associated with zero trust adoption can become insurmountable. With that, never forget the old security adage: Outrun, outlast.