Software-Defined Perimeter Architecture Guide Preview: Part 2


cyber security, lockThanks for returning for the second blog posting, providing a preview of the forthcoming Software-Defined Perimeter (SDP) Architecture Guide (Read Part 1). In this article, we focus on the “SDP Scenarios” section of the document, which briefly introduces the primary scenarios for SDP, explains why organizations should consider adopting SDP, and lists the benefits that SDP delivers for that scenario.

This section is—by design—concise. We’re passionate about SDP and network security, and could write an entire novel on this topic (in which our hero, network security architect Reavis Macdonald, uses SDP to prevail against a malicious adversary and save his organization from a record-breaking GDPR fine!). Sadly, our editor assures us that such a story wouldn’t be a bestseller, and that our Architecture Guide should likewise err of the side of brevity.

In this blog posting, we’ve chosen to elaborate on several of the scenarios and to provide some color commentary. Let’s get started!

SDP Scenarios at a Glance

Scenario 1: Identity-Driven Network Access Control
Chart: SDP Scenario 1

This scenario is the heart of the value that an SDP architecture provides. It enables organizations to fundamentally change the way they’re viewing security—shifting away from IP addresses and subnets, and toward identities and business systems. This is more than a technical shift—at least, it should be more than that. We’ll discuss this more in the SDP Policy section in the main document, but SDP allows for policies to be described in terms that are meaningful to the business, yet are enforced by the network.

Scenario 2: Network MicrosegmentationChart: SDP Scenario 2

The concept of network microsegmentation—often part of a Zero Trust initiative—is driven by the imperative to enforce the principle of least privilege at the application and network level. But microsegmentation is only a means to an end. It requires a policy model, and a mechanism for automated enforcement of these microsegments in order to deliver efficient and effective value to the enterprise.

Shifting gears slightly, we now introduce several use cases that organizations commonly use to get started with Software-Defined Perimeter projects.

Scenario 3: Secure Remote Access (VPN Alternative)Chart: SDP Scenario 3

Virtual private networks (VPN), while widely deployed, nevertheless suffer from a variety of shortcomings that frequently drive organizations to consider the Software-Defined Perimeter as an alternative. In addition to being disruptive to the user experience, VPNs typically provide too-broad network access, exposing far more services and protocols than necessary. VPNs are also difficult or awkward to use when people need to concurrently access many distributed resources —either across data centers or cloud environments. And finally, VPNs are a point solution. Because they are only used for remote access, their access policies are by definition unable to apply to on-premises users. SDP solves all these problems with VPNs, providing a single consistent and user-friendly platform that secures access for both remote and on-premises users with fine-grained control of access rights.

Scenario 4: Third-party User AccessChart: SDP Scenario 4

Third-party access is another very common use case for SDP. While remote third-parties may fall under the VPN scenario, many organizations have considerable numbers of third-party users working on-premises. These users often need very specific (and limited) network access, while nevertheless using the same network as employees with broader access. A Software-Defined Perimeter provides a simple solution for this, which ensures that these third-party users have a consistently secured and managed set of network privileges, regardless of whether they are remote or on-premises.

Scenario 5: Enabling Secure Transition to IaaS Cloud EnvironmentsChart: SDP Scenario 5

Finally, we’re seeing many organizations leverage SDP to more easily and securely adopt IaaS cloud environments. Rather than relying on direct site-to-cloud connections (which provide too-broad network access), or traditional VPNs (which are awkward to use in multi-account or multi-site environments). SDP allows for precise access control to cloud environments, managed on a per-user basis.

Conclusion

We hope that this preview blog post gave you a good sense for some of the SDP scenarios, as well as a bit of expository context on our thinking around them. In our next blog posting, we’ll be reviewing the core concepts of the Software-Defined Perimeter , explaining their benefits, and listing some of the associated threats that they mitigate.

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.

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

[Cloud Security Alliance Blog]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.