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.

cyber security, lockOver 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. Some examples:

SDP policy categories chart

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

SDP Policy chart for Finance

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

SDP policy chart for Development

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.

 

 

 

 

 

 

Software-Defined Perimeter Architecture Guide Preview: Part 3

Part 3 in a four-part series

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

cyber security, lockThanks for returning for our third blog posting, providing a preview of the forthcoming Software-Defined Perimeter (SDP) Architecture Guide. In this article, we’re focusing on the “Core SDP Concepts” section of the document, which introduces the underlying principles of SDP, and in which we explain the benefits that SDP provides. In the table below, we list five categories, and for each we explain several aspects of SDP that deliver benefits, along with some color commentary.

Information/Infrastructure Hiding

One of the key security benefits that SDP provides is that not only are the organization’s servers protected by the SDP Gateway, but the SDP infrastructure itself is secured against access by unauthorized users. This makes it safer to deploy SDP components in internet-facing roles, compared with traditional security infrastructure (such as VPNs) which are directly and easily accessible to attackers.

Aspect Benefits Threats Mitigated
Servers are “Blackened” The SDP components (Controller, Gateways) will not respond to any connections until the clients have been authenticated and authorized with the use of protocols such as Single Packet Authorization (SPA). External network attacks and cross domain attacks mitigated.
Mitigates Denial of Service attacks Internet-facing services are typically placed behind a ‘deny-all’ gateway/firewall, commonly an SDP Gateway, and are therefore protected from DoS attacks. The SDP Gateway itself is protected against DoS attacks by SPA (see above). Bandwidth DDoS.
Bad Packet detection The first packet to an accepting host (AH) from any other host is a SPA packet (or similar construct). If an AH receives any other packet, it is viewed as an attack, and future packets from that host can be rejected. External network and cross domain attacks quickly detected.

Mutual Two-way Encrypted Connections

Another key element of SDP is that all communications between components – typically the Client and the Controller & Gateways—are encrypted with mutually-validated TLS. This ensures that these elements can validate each other, ensuring the integrity of the system.

Aspect Benefits Threats Mitigated
Device Authentication The connections between all hosts must use mutual authentication to validate the device as an authorized member of the SDP. Ensures that connections cannot be initiated from invalid or unauthorized devices.
Disallows forged certificates Mutual authentication schemes pin certificates to a known valid root managed (or trusted) by the SDP. Reduces attacks from credential theft.
Disallows Man-in-the-middle attacks Mutual handshake ensures secure and tamper-proof communications between components. Prevents Man-in-the middle attacks.

SDP and the Need-to-Know Access Model

Because SDP is built upon a whitelist access policy model, users are only permitted access to those specific network resources that are permitted by policy—not to an entire subnet or network. The SDP philosophy is that application-level authentication is insufficient security, and that the ability to access a network resource—even without credentials—is in fact a privilege that should be explicitly granted.

Aspect Benefits Threats Mitigated
Allows fine-grained access control Only authorized users and devices are allowed to make connections to servers, based on access policies. Theft from external users from unknown devices is reduced.
Makes forensics easier All bad packets can be analyzed and tracked for forensics activities. Bad packets and connections are reduced.
Enforces device validation Device validation proves that the key is held by the proper device requesting connections. Threats from unauthorized devices are reduced and mitigates credential theft.
Protects from compromised devices Because users are only granted access to authorized applications and to no other ones, the threat of lateral movement from compromised devices is eliminated. Mitigates threats from lateral movement.

Dynamic Firewall

SDP acts as a logical (and in some implementations, actual) firewall, dynamically adjusting network access based on policies. This permits enterprises to create dynamic enclaves—essentially adapting user access to network resources based on membership attributes, such as directory group membership.

Aspect Benefits Threats Mitigated
Allows dynamic membership-based enclaves Access to protected resources enabled by dynamically creating and removing access rules. Mitigates network-based attacks.

Application Layer Access

The final key element of SDP is that users only have access to specified, permitted network resources (referred to as “Applications”, even though they may be admin-level services such as SSH or RDP). By preventing all unnecessary network-level access, organizations benefit by having a reduced attack surface, preventing reconnaissance (such as port scanning) by unauthorized users, and enabling the detection of attempted malicious activity.

Aspect Benefits Threats Mitigated
Eliminates broad network access With SDP, identities no longer have broad access to network segments or subnets. Devices can only access specific hosts and services permitted by policy. Minimizes attack surface. Eliminates port and vulnerability scanning by malware or malicious users
● Enables control of application and service access SDP can be used to protect different types of services, such as application and system services.

SDP systems can control which devices and applications are permitted to access specified services.

Limits attack surface, and prevents malware or malicious users from connecting to resources.

That’s a brief overview of the SDP Core concepts. In our next (and final) preview posting, we’ll be discussing the SDP Policy model. You can read our earlier installations here and here.

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.

Software-Defined Perimeter Architecture Guide Preview: Part 2

Part 2 in a four-part series

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

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.

Software-Defined Perimeter Architecture Guide Preview

Part 1 in a four-part series.

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

cyber security, lockThe Software-Defined Perimeter (SDP) Working Group was founded five years ago, with a mission to promote and evangelize a new, more secure architecture for managing user access to applications. Since the initial publication of the SDP Specification, we’ve witnessed growing adoption and awareness throughout the industry. As practitioners, vendors, evangelists, and guides, we (as the SDP working group) have learned a great deal about SDP in practice, and wanted to capture and share that knowledge.

This was the driver for us to create the forthcoming Software-Defined Perimeter Architecture Guide. We’ve decided to publish a preview blog series here to obtain feedback on this work-in-progress artifact, and to spark conversation about SDP architectures and deployments. Ultimately, we intend the final published Architecture Guide—scheduled for publication in Q4 2018—to encourage broader (and more successful) adoption of SDP architectures.

Please join the conversation in the SDP working group here—we’re open to feedback, questions, or even just good restaurant recommendations. Thanks for reading this, and we look forward to engaging with you.

In this first blog posting, we’re going to walk through the SDP Architecture Guide outline and provide color commentary. Keep in mind that this document is still a work-in-progress, so the content and structure may well change prior to publication. Let’s dive in:

  • Introduction
    • Why We Wrote This Document
    • Target Audience
    • Goals
    • SDP Scenarios

In the introduction, we provide the motivation for the document, articulate who our target audience is, and explain our goals. Then, we enumerate SDP scenarios (AKA use cases), briefly explaining each one, and exploring the benefits that SDP provides in that scenario.

  • SDP, Zero Trust, and Google’s BeyondCorp

In addition to SDP, there is a lot of noise and activity in today’s marketplace around the Zero-Trust philosophy, and to some degree about Google’s internal BeyondCorp security initiative. In this section, we attempt to make sense of this and explain the similarities and differences between them.

  • SDP Overview
    • Core SDP Concepts
    • SDP Architecture
    • SDP Deployment Models
      • Client-to-Gateway Model
      • Client-to-Server
      • Server-to-Server Model
      • Client-to-Server-to-Client
      • Client-to-Gateway-to-Client
      • An Alternative Architecture: The Cloud-Routed Model

This section presents the foundational elements of SDP, including its core underlying concepts. We also dive into the SDP architecture and discuss each of the SDP deployment models.

    • Single-Packet Authorization
      • SPA Benefits

Single-Packet Authorization (SPA) is one of most important parts of SDP. By compensating for the fundamentally open (and insecure) nature of TCP/IP, SPA enables secure and reliable deployment of SDP Controllers and Gateways onto insecure and public networks. In this section, we analyze the SPA protocol, suggest some improvements, and expand upon its benefits to SDP.

    • SDP Policy Model
      • SDP Policy Overview
      • Policy Components

SDP, as a specification, is silent on a policy model. In this section, we introduce the elements that an SDP policy model should have and the corresponding capabilities that an SDP platform should be able to express. We conclude this section with a few example policies.

  • SDP in the Enterprise
    • Architecture Considerations
    • Security and IT Technologies
      • SIEM
      • Firewalls
      • Intrusion Detection/Prevention Systems
      • Virtual Private Networks
      • Next-Generation Firewalls
      • Identity and Access Management
      • VPNs
      • NAC
      • SDN
      • IDS / IPS
      • EMM / MDM
      • Web Application Firewalls
      • Cloud Access Security Brokers

This section introduces a simplified (but prototypical) enterprise model, exploring how each of the Security and IT technologies shown above are impacted by the deployment of SDP.

  • SDP Business Benefits

We conclude with the business benefits that SDP can deliver. This section, which will be constructed in a tabular format, will provide an overview of these benefits. We look forward to providing more detailed, quantified benefits and case studies in a future document.

Thanks for reading through the outline. In our next blog post in this series we’ll talk through the SDP Core Concepts table.

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.

New Software-Defined Perimeter Glossary Sheds Light on Industry Terms

By Shamun Mahmud, Research Analyst, Cloud Security Alliance

The Cloud Security Alliance’s Software Defined Perimeter Working Group set out to author a comprehensive resource on the terms and definitions within software defined perimeter (SDP) architectures. SDP has changed since the working group’s inception in 2014, so the Working Group went about creating a glossary to reflect this evolution, holding a series of regular meetings over the course of the last eight months to bring the new Software Defined Perimeter Glossary, a free industry resource, to fruition.

Compiling the information in this document was meant to minimize misinterpretation about SDP and provide a succinct understanding of the architecture. A balance was struck between length of the definitions and clarity with reliance on the reference source as the final arbiter. The result is a common language to communicate, understand, debate, conclude, and present the results of the SDP framework.

As a reference document, the Software Defined Perimeter Glossary brings together SDP-related terms and definitions from various professional resources. These terms, and the supporting information, cover a broad range of areas, including the components of SDP and common supporting technologies.

The SDP Glossary was intended as a reference document to draw enterprises (and service providers) that are interested in learning more about the underlying technologies and protocols. Those that are new to SDP will notice many familiar technologies involved, expediting their awareness of SDP. Ultimately, we see this glossary as a tool to familiarize practitioners with the Software Defined Perimeter.

Awareness of the SDP toolkit is the first step to its adoption. Based on this glossary revision effort, we’re pleased to see this level of familiarity. The SDP Working Group is confident that SDP will continue to gain momentum, but realistic that we, as its proponents, have some work to do. Clearly organizations face challenges in making the case for using SDP instead of traditional security technologies.
CSA plans to fill this gap with further SDP resources and information. The glossary, along with the SDP Specification v2 (Read SDP Specification v1) and SDP Architecture Guide, are vital pieces of SDP adoption and deployments within the industry.