Software-Defined Perimeter Architecture Guide Preview: Part 4

Part 4 of a four-part series

By Jason Garbis, Vice President/Secure Access Products, Cyxtera Technologies Inc.

Over the past three blog posts on this topic, we’ve provided an overview of the Software-Defined Perimeter (SDP) Architecture Guide, including its outline, core SDP concepts, and a summary of SDP benefits. In this, our final preview blog on the Architecture Guide, we’ll introduce the SDP policy section, and conclude with a few final thoughts.

While an SDP system is technically responsible for allowing or preventing network packets from flowing between two systems, its real value—and its real opportunity as an emerging architecture—is to define a policy model that aligns identity and application access with enforcement at network level. That is, to enable organizations to construct policies that determine which identities—human or system—should be permitted to access which target services, under which conditions. And, to have the ability to enforce this by preventing any network-level access by unauthorized users.

Enterprises have numerous network access enforcement points and policy models, whether they think about them in these terms or not. Unfortunately, these are typically spread across multiple teams, technologies, and expressed in highly varying languages. For example, an enterprise’s access control model often follows defense-in-depth with layered security, commonly pieced together through a combination of network enforcement points (firewalls, NACLs, VPNs, VLANs) and identity enforcement points (IAM, PAM, WAF). Each of these has its own scope and has varying degrees of connection to the business. Some of these, such as access governance, are primarily business processes and business policies. Others, such as ACLs, are purely technical rules enforced at the network layer.

Mind the gap

There is a gap—increasingly recognized by enterprises—between the network and identity enforcement layers, which represents a problem for many organizations. SDP can bridge this gap, through its policies that are identity-centric and network-enforced. SDP policies can (and enterprises should) draw upon attributes from a broad set of categories, including user, device, network, service, enterprise ecosystem, and world.

Many of these attributes have been used by security products for many years—for example, device attributes and security posture checks have been performed by network access control (NAC) solutions, and geolocation has been used by authentication solutions. What’s interesting now is the way that SDP can combine and extend these. For example, with SDP enterprises can create virtual network enclaves, determining which server elements are accessible to each user, based on attributes. Another example has to do with the dynamic nature of cloud or virtualized environments. As services are instantiated, an SDP system can use the service metadata—such as tags—to determine and adjust user access levels, based on policies.

Software-defined perimeter support

Note that the SDP Specification does not define a policy model or language—it’s up to each vendor to determine how to implement this. As such, the examples below are representative of the kinds of policies that enterprises can expect to be supported

Allow all users in the Finance department to access the business application running on the SAP Server, from managed devices

Allow developers working on Project Everest to access the cloud-based build and test servers for this project.

I hope that this preview series has provided you with a good sense for the approach that we’ve taken in the Architecture Guide, and that our excerpted sections have given you a solid introduction to the content. Thank you for reading, and we look forward to sharing the completed guide with you soon.

Jason Garbis is Vice President of Secure Access Products at Cyxtera, a provider of secure infrastructure for today’s hybrid environments, where he leads strategy and management for the company’s security solutions. Jason has over 25 years of product management, engineering, and consulting experience at security and technology firms including RSA, HPE, BMC, and Iona. He is co-chair of the Software Defined Perimeter (SDP) Working Group at the Cloud Security Alliance, holds a CISSP certification, is a published author, and led the creation of the Cloud Security Alliance initiative applying Software-Defined Perimeter to Infrastructure-as-a-Service environments.