Implementing Zero Trust: Beyond Internal Network Models
Posted by David Ratner | May 8 2024
With 2024 being the year that people and organizations are realizing that they will never be able to prevent every breach, and they need to ensure the implementation and deployment of appropriate proactive cyber resiliency solutions, zero-trust is rapidly becoming more popular. CISA published their zero trust maturity model and the NSA released their guidance on zero trust principles.
The US Government issued an executive order which included zero trust models, and zero trust is gaining ground internationally as well, from the Middle East and Europe to Asia and Australia. However, the question that needs to be asked is – are people thinking about zero-trust broadly enough, and is your implementation really going to help move forward cyber resiliency and reduce digital risk across your organization?
Let’s put aside the fact that Gartner indicates that most organizations won’t actually be able to rapidly deploy zero-trust for a variety of reasons. It still begs the question – how do you think about a complete zero-trust model?
Most people think of zero-trust as a model inside the organization to force a strict control of “who am I talking to, why am I talking to them, and should I be talking to them.” More specifically, Wikipedia provides a succinct definition of zero-trust:
"Zero trust is an approach to cybersecurity that emphasizes strict access control and verification of users and devices, regardless of their location or previous verification status. It involves never trusting users or devices by default and always verifying them before granting access to resources."
So, if you are implementing zero-trust, what about when the access goes outside of your environment? Are you similarly asking the same questions — for each connection that originates inside your network and tries to talk to a remote piece of Internet infrastructure outside your network, why are we talking to it, who is it really, and should we be talking to it? I find that this is often a forgotten or deprioritized aspect of zero-trust but should be one of the most critical.
Everyone will unfortunately be breached at some point, and often the first step in the attack after a successful breach is communicating with their command-and-control infrastructure for instructions – lateral motion, privilege escalation, and exploration of the organization. Even if it isn’t the very first step, it’s still required for data exfiltration and other aspects of a successful attack.
For each attempted communication leaving your organization, the best way to ensure cyber resiliency and protect the organization from ensuing data leaks and damage is to understand:
(i) Where is this connection going?
(ii) Should this connection be allowed?
(iii) Why or why not?
The principle of zero trust – assume nothing and validate everything – will render attacks inert because when they try and communicate with command-and-control to advance their attacks, the communication will be blocked, and they won’t be able to advance the attack.
CISA and the NSA call this Protective DNS and recommend it as part of the Shields Up initiative. It’s being implemented on a national level both in the United States and Internationally. It’s a recommended part of a SASE framework. It’s becoming part of standards like CMMC. Even cyber insurance carriers are starting to ask if the organization employs Protective DNS in their questionnaires and required attestations.
It should also be considered a critical and necessary part of a zero-trust implementation. Without Protective DNS, a zero-trust implementation is only providing partial protection; it can’t detect or block the beaconing behavior that malware and attacks generate, and thus cannot stop these attacks or render them inert. Given that Protective DNS solutions can be implemented in minutes, can be tailored to each organization’s architecture and configured for each organization’s level of desired risk, and add to the efficacy of the overall solution stack, those implementing zero-trust models should not only consider implementing Protective DNS as part of their project plan but should consider implementing it as the first part in that plan.
Given how much an organization relies on the Cloud and broader set of Internet services, and given how much communication flows between an organization and resources on the greater Internet, it shouldn’t even be possible to talk about zero-trust without incorporating an organization’s outgoing traffic. That’s the role of Protective DNS. And if you check out the testing that third-party organizations like AV-TEST do, it can really be very effective and drive a considerable ROI in terms of improving cyber resiliency and reducing risk.
Want to get the upper hand on adversary infrastructure? Contact us to get a complimentary security assessment and learn how to make the switch from reactive to proactive defense.
