For many organizations, the concept of “Zero Trust" has meant promising new approaches to tackling the complexities of network and data protection. While we’re seeing an increasing number of organizations setting aside budget and resources to kick off Zero Trust adoption, others are looking to Zero Trust as a “point solution” to address their immediate needs. In either case, organizations face daunting challenges when implementing a new solution, and a change of mindset in how they view cybersecurity solutions is needed.
In the hopes that others can learn from these real-world challenges, I’ve compiled the top three common mistakes organizations make when embarking on their Zero Trust journey – starting with “micro-segmentation,” the process of segmenting your internal networks to reduce its attack surface, and eliminate the ability for bad actors to move “east to west” across servers, applications and other critical data sources within your ecosystem.
Often, organizations underestimate the complexity of their network when they first start implementing Zero Trust framework. The number of applications, servers, users, and interdependencies between them often catch Information Technology (IT) administrators off guard. A server may need to have different policies based on its physical location, logical location (i.e., departments), resource capacity, underlying Operating System (OS), applications it supports, authorized users, etc.
What seemed simple on paper, such as using a handful of tags to accurately characterize a server, turns out to be insufficient in practice. The same level of complexities holds true for applications and users. Even organizations who are confident of their IT infrastructure mapping and inventory, inevitably face outdated audits from overlooked parts of the network.
Unfortunately, this is when many organizations hit the brakes. What started as a deployment plan consisting of a few weeks have now ballooned to several months with no end in sight. IT administrators scramble to right the ship but, in many cases, they often contact a different vendor in the hopes of finding a more practical solution. This is one of the few ways vendors uncover new opportunities and become aware of an organization’s challenges.
Recommendation: There is very little you can do to fix the complexity of the network. No magic wand to simplify it. However, it’s critical that organizations assess the time to value of any micro-segmentation solution they plan to deploy. How quickly can policies be created? How can you automate policies to learn from past experiences? How easily can policies be extended as the organization and network grow? These are all the questions organizations ask after having felt the pain of a stalled project. These questions must be addressed upfront before the deployment to accurately assess the progress based on the organization’s unique network requirements.
As previously mentioned, many organizations do not accurately plan for the duration of a Zero Trust micro-segmentation project, which leads to unrealistic expectations and dissatisfied teams. However, it’s important to note that organizations should focus more on intermediate milestones rather than simply the final target date and resulting outcome.
For example, an organization may work with a vendor to put together a deployment timeline that spans three months, implying that after the first month, one-third of the deployment would be complete, and after two months, two-thirds of the deployment would be complete. Any change to the overall timeline will have similar impact across the board.
Recommendation: What I encourage organizations to do is to work with the vendor and partners to create a milestone that can scale and be flexible in the face of unplanned events. For the same three-month deployment timeline, you can set a goal of 75% deployment to be achieved after the first month and 95% after the second month. Even if the overall timeline changes, organizations can still make significant strides. Of course, this is only possible with the right type of solutions and partners.
Traditionally, cybersecurity project deployments start with the user or identity. Based on the identity, policies for access to network and applications are then created. Many are using this approach to Zero Trust and micro-segmentation, often starting with deployment of Identity-as-a-Service (IDaaS). Afterall, don’t you need to know the user identity before you can set up any meaningful policies? The answer is “no” and here’s why.
A key benefit of micro-segmentation is that policies can be created and enforced based on several factors. These include users, of course, but also applications and servers. By creating and enforcing policies based on applications for example, a particular application can only access specifically identified resources, applications and servers. If a hacker were to gain access to a particular application, its lateral movement would be greatly restricted, preventing the further spread of cyberattacks. Similar arguments can be made for servers and other similar policies.
Recommendation: Many organizations unfortunately start with identity solutions, since that is what they are familiar with. I suggest that you focus instead on what you need first to be able to maximize the benefits of Zero Trust.
There is certainly more than one way to approach Zero Trust, and depending on the solution and partners you use, some of the recommendations here may not apply. However, before embarking on your Zero Trust journey, I encourage you to learn from the challenges and mistakes from others who have already walked that path.
As a leading Zero Trust and micro-segmentation vendor, ColorTokens has insights into the real-world challenges organizations face when embarking on Zero Trust and in particular, micro-segmentation projects. In some cases, we are working with the organizations from the very beginning, guiding them through various obstacles and avoiding common pitfalls. In others, we are contacted by the organizations to resuscitate their Zero Trust initiative after their plans have gone awry, possibly having fallen into one of those pitfalls.