Security Think Tank: Facing the challenge of zero trust
In theory, the elimination of trust on the network simplifies IT security, but zero trust also brings new complications and new challenges. How should CISOs go about moving their organisations from traditional network security to a zero-trust architecture?
Zero-trust architecture refers to security controls and threat models that no longer assume that actors, users, systems or services operating from within the security perimeter should be automatically trusted, and instead everything must be verified in order to operate.
This IT security model requires strict verification of all systems and people interacting with the ecosystem. This is in comparison with the traditional perimeter security approach, which is analogous to a “castle wall and moat” model.
Zero trust includes “least privilege” – only providing access to the extent to what is needed. The result of this approach is segmentation of the network and systems within the perimeter, also called micro-segmentation, whereby the network is broken into zones, each of which requires authorisation to access and utilise – “trust but verify”.
Privileged access management (PAM) refers to a class of solutions that help secure, control, manage and monitor privileged access to critical assets, which is a core component to the zero-trust model.
Challenges to adopting zero trust (which is rather slow) include technical debt, impact on legacy systems, and the historical deployment of peer-to-peer and distributed systems. Most successful zero-trust deployments have been built from a greenfield situation where it was baked in from day one.
Technical debt
Many systems and architectures have not taken into account least privilege or PAM, and to retrofit such a model would be a significant project. Least privilege is only the starting point of zero trust.
“Zero trust requires least privilege and privileged access management – if your architecture or processes support shared access accounts, implementing zero trust would be difficult”
Eoin Keary, cyber security industry veteran
Technical debt includes identifying sensitive data across all systems to apply least privilege, designing micro-segments around and inside different silos of data based on their sensitivity, understanding flows of sensitive data, and monitoring segment access and sensitive data flows on a continuous basis.
Most systems are not architected to fulfil the micro-segmentation requirements of zero trust.
Many legacy systems don’t have the capability to provide access control in that manner (least privilege).
Peer-to-peer challenges
Many systems use peer-to-peer (P2P) models, including windows operating systems and wireless mesh networks. P2P breaks the zero-trust model as systems communicate in a decentralised manner, which breaks the micro-segmentation model.
Peer-to-peer systems share data with little or no verification, and therefore break the least privilege model also.
Hybrid cloud
When public and private cloud services work together and unify to deliver a service which is not uncommon, this also breaks the segmentation model.
Moving from silos to data centric
Most systems are silos of data, containing both sensitive and less sensitive data, which would need to undergo segmentation based on the data. The verification and access controls are based on the data, not the system.
Many systems currently would require large architecture.
Digital transformation and DevOps
Digital transformation is the process of using digital technologies to create new – or modify existing – business processes, and customer experiences to meet changing business and market requirements. Digital transformation – also known as moving to the cloud, implementing the internet of things and deploying a DevOps culture – does not, in nature, support zero trust.
Implementing zero trust in a DevOps environment needs additional technology and impact processes to segment and enforce this paradigm given such an environment is very dynamic. Applying zero trust in a DevOps environment without some form of automation and removing the manual aspect would simply not be scalable and would slow down pipeline throughput dramatically.
Cloud adoption (lift and shift to the cloud) would not embrace or support zero trust, but systems built from the ground up could be designed to leverage the concept.
A requirement for zero trust is “least privilege” and “privileged access management” – if your architecture or processes support shared access accounts, implementing zero trust would be difficult.
Read more from Computer Weekly’s Security Think Tank about zero trust
