Second, this approach limits lateral movement of attackers should they be able to establish a foothold. By assuming a mindset that everything is untrusted by default, you make the effort required for an attacker to move laterally within your environment that much more difficult. Each individual node that an attacker compromises doesn’t necessarily mean that they will be able to move to the next node any more easily.
Over the past few years, organizations are more and more waking up to the fact that they might have had attackers dwelling in their network for long periods of time. Making lateral movement more difficult does two things at once: it increases the amount of time required for an attack campaign and it increases the amount of effort attackers must expend to move between devices. There are two outcomes that derive from this: first, since an attacker’s campaign is time-bound (i.e., it’s a race for them to complete their objective before they’re discovered and you lock them out) it is more likely that you will catch them before they achieve their objective. Second, because you’re increasing the amount of effort attackers need to expend to expand their foothold they need to be “louder” (i.e., less subtle about how they move through your network) in their approach to expand their foothold. This in turn means you increase the chances that you will detect indicators of compromise as they do so.
Putting this into action
If this sounds appealing to you, you’re not alone. More and more often organizations are adopting a zero trust mindset for securing assets. But if your organization isn’t already employing this approach, the question then becomes how to adopt it within your shop. You might, for example, see the value associated with a zero trust architectural approach but be unclear how to get there. For example, you might have a legacy architecture that is everything but this; instead, being designed around a tightly-controlled external perimeter and leveraging internal resources that are trusted because of where they’re located (inside the perimeter) and with plaintext, unauthenticated communication channels.
The most important thing to start with when moving to a zero trust strategy is to recognize that you won’t get all the way there all at once. You won’t wake up one day and magically be a 100% “zero trust” environment just by willing it so. Instead, zero trust is an architectural strategy that requires both a mental shift and then investment to make happen. And, let’s be honest, conversations to change strategies mid-stream can be challenging because there is often little direct business-visible value associated with doing so. Trying to explain to a business stakeholder, for example, that they’ll wind up with the same functionality tomorrow after making a sizeable investment to redesign around different architectural principles is a tough sell. This is OK though.
Instead of trying to “boil the ocean” and address everything all at once to shift to a zero trust architecture all in one swoop, instead do so slowly and migrate as time allows and as new services are rolled in. You can shift to a zero trust mentality in how you view your network, infrastructure, and technology footprint but recognize that it’ll take some time for the environment to come into alignment with how you view it.
To do this, as you release new systems or update existing ones, apply the principles of zero trust where and when you can. Over time, slowly adapt the environment in piecemeal fashion to shape it around your new viewpoint. After some time (potentially in some cases years), you’ll reach a state where the “old guard” of perimeter-bound architecture is phased out while systems that enforce and embrace zero trust are phased in. The important part here is adopting the mindset; the actual execution will get there over time.
Second, keep in mind that you can also strategically select and incorporate tools that forward a zero trust way of looking at the world. Tools like Edgewise for example are designed to work within a zero trust environment by fostering visualization of traffic between entities, by helping you to microsegment network communications, and by providing reporting that can help you identify indicators of compromise — zero in on potential attacker activity, and shut it down. Even if you can’t get to a fully zero trust environment in how you architect your systems and applications, you can get a head start on doing so through building capabilities that foster the approach.
Either way, zero trust can be a powerful concept when incorporated into your overall approach. Understanding what it is and why it’s valuable is a good first step; a more powerful “step two” consists of embracing the concept and using it as a fundamental architectural principle in how your technology landscape is architected.