{"id":45909,"date":"2022-03-28T10:00:00","date_gmt":"2022-03-28T10:00:00","guid":{"rendered":"https:\/\/www.threatshub.org\/blog\/use-zero-trust-to-fight-network-technical-debt\/"},"modified":"2022-03-28T10:00:00","modified_gmt":"2022-03-28T10:00:00","slug":"use-zero-trust-to-fight-network-technical-debt","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/use-zero-trust-to-fight-network-technical-debt\/","title":{"rendered":"Use zero trust to fight network technical debt"},"content":{"rendered":"
<\/div>\n

Zero trust<\/a> (ZT) is a mindset and a method, not a technology. The current push to adopt ZT is driven by an urgent and growing need to make a major leap forward in risk management and attack containment in enterprise networks, a need driven home by every successive wave of ransomware. IT can use the urgency of moving to ZT to root out some of the technical debt in the environment. Specifically, it can be a catalyst to find areas exempted from network and network security standards and bring them up to date under the new paradigm of zero trust.<\/p>\n

No more exempting network components from access-control roles<\/h2>\n

In a ZT environment, the network not only doesn\u2019t trust a node new to it, but it also doesn\u2019t trust nodes that are already communicating across it. When a node is first seen by a ZT network, the network will require that the node go through some form of authentication and authorization check. Does it have a valid certificate to prove its identity? Is it allowed to be connected where it is based on that identity? Is it running valid software versions, defensive tools, etc.? It must clear that hurdle before being allowed to communicate across the network.<\/p>\n