TechTarget.com/searchsecurity

https://www.techtarget.com/searchsecurity/tip/Understanding-the-zero-trust-SDP-relationship

Understanding the zero trust-SDP relationship

By John Burke

The first thing to understand about zero trust is that it is a bad name for a powerful concept. The point isn't: Nothing trusts anything. Rather, the point is: No trust is assumed. All trust relationships need to be explicitly stated.

Perhaps zero trust would be better stated as zero implicit trust, taking into account all aspects of implicit trust, including the following:

• No one has an implicit right to access a network -- just explicit rights to reach specific systems over the network.
• No one has an implicit right to stay on the network -- only an explicit right to use the network as long as they are not acting badly and their system remains in good health.

The software-defined perimeter (SDP) concept grew out of work done by the Defense Information Systems Agency (DISA) but was formalized and popularized by the Cloud Security Alliance in the past decade.

An SDP embodies the principles of zero trust at the network level. It introduces mechanisms to control network-level access to a system and to request access and grant it. An SDP is an endpoint-focused, virtual, deeply segmented network overlaid across any and all other physical and virtual networks already present.

SDP roles and responsibilities

An SDP relies on controllers "outside" a network to manage ingress to that network.

The basic process is the following:

• An entity wanting to talk on the protected network -- an initiating host -- must run the SDP software and authenticate with an SDP controller. Note, authentication is presumed to involve multiple levels of verification, which can range from a device certificate to an active system health check, and it is assumed always to include user authentication as well -- preferably multifactor.
• Once authenticated, the initiating host is told which other entities -- accepting hosts -- it is allowed to talk to, and those hosts are told to allow it to communicate with them. Accepting hosts are already known to the controller; they have already authenticated. Hosts not currently visible to the controller are not in the list of permitted hosts. The list of accepting hosts is determined by context, according to which service the initiating host is trying to reach and what it is allowed to do with that service. It should include only those accepting hosts essential to the requested communications.
• The initiating host sets up VPN tunnels directly to the given accepting hosts. Note, the controller is not part of that end-to-end, encrypted virtual network.
• An accepting host will reject, or drop, all network communications originating with a host not on the list of authorized initiating hosts it has from the controller.
• Controllers and hosts can be on premises or not; cloud controllers can manage communications for hosts anywhere and so can on-premises controllers. Even SaaS options can, via proxies or cloud access security brokers, be brought under the protection of an SDP.

Variant architectures place gateway hosts in the environment. These act as accepting hosts for clients outside the environment -- be it data center or cloud -- and do all the communications with the actual service providing hosts. Initiating hosts see only the gateway and never communicate directly with the infrastructure providing application services.

A key benefit of implementing an SDP is that accepting hosts are invisible on the network to all other systems or users until the controller allows them to connect to something. Only initiating hosts the controller allows to see it can see it; to everything else, it is invisible. This is an extremely strong basic security posture and the main reason DISA promoted this approach.

SDP is (one form of) zero trust

Given that SDP is based on granular management of who can connect with whom, with the default stance of "no traffic flows if not explicitly sanctioned," SDP is clearly an implementation of zero trust.

However, zero trust is wider and accommodates concepts not deemed essential in SDP. For example, zero trust calls for a dynamic trust map that responds to behavior. SDP allows this, but it is not considered foundational.

SDP also assumes the hosts -- under the direction of the controller -- are the only entities enforcing whether network communications take place, dropping packets from unsanctioned communications partners. Alternately, zero trust allows for an infrastructure that can participate actively, dropping traffic before it even gets to a host. Under zero trust, there may be a network-based component to traffic management, either in addition to, or replacing, SDP.

Enterprises seeking a comprehensive, multi-cloud security base on which to build are embracing the concept of zero trust. They should also be evaluating SDP tools as an expression of that principle.