Software-defined perimeter is a good place to start a rollout of Zero Trust network access

Zero Trust relies on continuously re-authorizing users, applications, and devices to establish myriad “perimeters of one” in the environment, but the name isn’t quite accurate.

Zero Trust doesn’t literally mean zero trust; it means zero implicit trust. You—whether that means a person, or a software or hardware system—are not to be trusted simply by virtue of where you are on the network; there is no network perimeter within which you are automatically trusted to connect to services. And you are not to be trusted now just because you were trusted when you first gained access to the network; gaining admission once is not the same thing as ongoing trust. And you are not to be trusted to make the new service connection you are trying to make now just because you were trusted to make the previous one.

So, in a ZT environment, each time someone or something tries to connect to a service, they are once again authenticated, and their right to use that service—in that way, at that time, from wherever they are at the moment—is re-verified. Architecturally, policy decision points use a trust map to evaluate requests before instructing one or more policy enforcement points to block or allow the requested sessions. “At that time” is a critical aspect of Zero Trust. The trust map is dynamic, and ideally it is updated in real time based on behavioral threat analytics run against actual, ongoing network activities.

The other crucial point: Zero Trust is an approach, not a product. ZT can be implemented at the network level (Zero Trust network access, ZTNA), at an application level, and at a data level, and individual products don’t play across all three domains.

Software-defined perimeter: Zero Trust without the feedback loop

Software-defined perimeter (SDP) as a concept actually predates Zero Trust. It implements the whole decision point/ trust-map/enforcement-point architecture at the network layer. That is, it is about controlling when packets are allowed to flow. When node A is not allowed to access services on node B, it will not even be able to detect that node B is there on the network; packets sent toward node B will simply be dropped. If node A is allowed to access, say, only encrypted web services via port 443, then it will not be able to get packets sent to any other port. It is “almost” zero trust only because, as defined, SDP does not require the behavioral feedback loop that Zero Trust uses to keep the trust map up-to-date. Vendors are, however,  closing this gap, turning their solutions into fully-fledged ZTNA systems.

SDP is a huge step toward full Zero Trust and one that can be used to control access from known devices, whether on a company network or remote, to company services, whether in a data center or in a cloud.

SDP a good place to start

Using SDP to replace VPNs for remote access to company resources makes a great first use case for ZT in many networks because

• It is a well-defined problem to solve, comprising limited and known use cases
• Current VPN solutions are often cranky for both admins and users, who tell us they are
  • prone to breaking, so user sessions drop
  • easy to misconfigure
  • complex to manage when many groups with divergent access needs share them or there are multiple security siloes in the infrastructure to manage access to,
  • frequently an impediment to quick, reliable access to protected systems
• Managing groups and individuals with widely divergent access needs is central to what an SDP is designed to do
• VPN-like levels of access control are simple to replicate
• SDP makes it easy to get far more granular about access rights quickly

Plan ZTNA thoroughly first

Nemertes most recent research on cybersecurity, the Secure Cloud Access and Policy Enforcement Research Study 2021-22, finds that the most successful security organizations that embrace Zero Trust approach it differently from most. The others dive in fast, undertaking not just defining their Zero Trust architecture in the first phase of the effort but also beginning to rearchitect networks and security, and to buy tools, and to put together their implementation team. By contrast, the more successful organizations limit the first phase of the effort to defining the ZT architecture. From there they pursue rearchitecting networks and security, and only after that do they pursue implementation.

The take-away is, get Zero Trust into your thinking for all future cybersecurity, now. Begin your Zero Trust journey by defining a Zero Trust architecture for your organization, then re-evaluating network and security architectures. When you get to the point of deciding where to begin implementing, take a hard look at SDP. Not only is it a logical jumping off point to improving your security posture, it could have significant payoffs in terms of improved user experience and reduced cybersecurity-staff workload.