More and more organisations are looking to implement a zero trust security model. Here Morey Haber, CTO at BeyondTrust, argues that this is not something everyone can do unless they are embarking on a brand new initiative.
A zero-trust security model redefines the architecture of a trusted network inside a defined corporate perimeter. This is relevant today since technologies and processes like the cloud, DevOps and IoT have either blurred or completely dissolved the idea of a traditional perimeter. But while zero trust has become a trendy catchword in IT here in the Middle East, in practice, it remains more of a theoretical concept as opposed to one that organisations can implement, for a couple of reasons.
Legacy internal applications
If your organisation develops its own software for internal consumption and the applications are more than a few years old, you may have technical debt. Loosely defined, technical debt refers to solutions based on older or obsolete technology that would not be used to develop new solutions today. Applications written in Cobol are an extreme example of technical debt.
Today, redesigning, recoding and redeploying applications to replace technical debt can be costly and potentially disruptive. There needs to be a serious business need to undertake these types of initiatives. Adding security parameters to existing applications to make them zero trust-aware is not always feasible. Odds are your existing applications have no facilities today to accommodate a zero trust model.
Therefore, depending on how reliant you are on custom applications, this will dictate whether or not you can adopt zero trust to those processes and potentially determine the effort and cost required. This is especially true in instances when applications are not micro-perimeter compatible or lack Application Programming Interfaces (API) to support the required automation for a zero trust implementation.
Legacy infrastructure
Legacy infrastructure and network devices are most certainly not zero trust aware. They have no concept of least privilege or lateral movement and they do not possess authentication models that dynamically allow for modifications based on contextual usage.
Any zero trust implementation requires a layered, or wrapper, approach to enable these systems. However, a layered approach entails wrapping the external access to the resource and rarely can interact with the system itself. This defeats the premise of zero trust. You cannot monitor the behaviour within a non-compatible application. You can screen scrape, keystroke log and monitor logs and network traffic to look for potentially malicious behaviour, but your reaction is limited. You can only limit the external interaction of the legacy device to the user or other resources – but not the run-time itself.
This limits the coverage of zero trust and based on the characteristics of legacy infrastructure, organisations may find that even monitoring network traffic is not feasible due to heavy encryption requirements, including emerging standards like TLS 1.3.
P2P communication
If you think your organisation does not use peer-to-peer (P2P) networking technology, you are probably unaware of the default settings in Windows 10.
Starting in 2015, Windows 10 enabled a P2P technology to share Windows Updates among peer systems to save internet bandwidth. While some organisations turn this off, others are not even aware it exists. This represents privileged lateral movement between systems that is fundamentally uncontrolled. While no vulnerabilities and exploits have materialised for this feature, it does present communications that violate the zero trust model. There should be no unauthorised lateral movement – even within a specified microperimeter.
In addition, if you use mesh network technology, you will find that they operate completely counter to zero trust. They require P2P communications in order to operate and the trust model is based strictly on keys or passwords with no dynamic models for authentication modifications.
Therefore, if you decide to embrace zero trust, you need to investigate if your organisation has P2P or mesh network technologies, even for wireless networks. These present a huge stumbling block to embracing the access, segmentation and microperimeter controls required for zero trust.
Digital Transformation
Even for organisations that are in a position to build a brand-new data centre, implement a role-based access model and embrace zero trust 100%, there is the challenge posed by Digital Transformation.
The Digital Transformation driven by cloud, DevOps, IoT and IIoT does not inherently support the zero trust model as it requires additional technology to segment and enforce the concept. For large deployments, this can be cost-prohibitive and may even impact the ability for the solutions to interact correctly with multi user-access. If you doubt this, consider simply the storage requirements and license costs to log every event for dynamic access on all resources within the scope of the project.
While some may disagree that the cloud does embrace segmentation and zero trust models, it all depends on how you use the cloud. A straight migration of your raised floor to the cloud does not embrace zero trust. If you develop a new application in the cloud as a service, then it certainly can embrace zero trust.
However, just moving to the cloud alone as a part of your Digital Transformation does not mean you inherently get the prescribed zero trust model benefits. And if you decide to embrace zero trust and bake it into your plan, your results may be limited for all the reasons discussed earlier in this article.
The zero trust model is not new. Regulatory standards like PCI have embraced the concepts, minus analytics and automation, for years. The basics make common sense, but without considering the existing technology within your stack, your strategic direction and the technologies used for remote access and vulnerability management, it is just a theoretical approach used for architecting good cybersecurity hygiene from the ground up, not a pre-packaged solution that can be bought to retrofit over your existing systems.
Therefore, the only successful zero trust implementations that have gone from marketing to reality are ones that have baked zero trust in from day one. These are brand new end-to-end designs with minimal legacy interactions. Typically, this is not something everyone can do unless they are embarking on a brand new initiative.
