Study Guide_ZT .pdf

1 SDP History, Benefits, & Concepts In this unit, you will be introduced to the concept of SDP, as well as gain a high-level overview of SDP architecture. Part of this introduction includes learning about the basics, such as the history of SDP, its technological and business benefits, as well as ot...

1 SDP History, Benefits, & Concepts In this unit, you will be introduced to the concept of SDP, as well as gain a high-level overview of SDP architecture. Part of this introduction includes learning about the basics, such as the history of SDP, its technological and business benefits, as well as other related concepts. 1.1 SDP Definition & Function CSA defines SDP2 as a network security architecture implemented to provide security for all layers of the open systems interconnection (OSI) model. An SDP implementation hides assets and uses a single packet to establish trust via a separate control and data plane; only then are assets exposed to the requestor. Although SDP has different roots than the ZT security model, the evolution of both concepts over time has led to community consensus in categorizing SDP as an implementation option of a ZTA. In order to isolate services from unsecured networks, SDP aims to give infrastructure and application owners the ability to deploy perimeter functionality when and where it’s needed. SDP overlays existing physical infrastructure with logical components that should be operated under the control of the application owner. SDP only grants access to the application infrastructure after device attestation and identity verification. Figure 1: Access Granted After Device Attestation/Identify Verification 2 https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-and-zero-trust/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 2 SDP is based on the premise that organizations should not implicitly trust anything inside or outside the network. It requires users on validated devices to cryptographically sign in to the perimeter created around hidden assets, even as they reside on public infrastructures. An SDP implementation hides assets with a drop-all firewall, uses a single packet to establish trust via a separate control plane, and provides mutual verification of connections in a data plane to hidden assets. SDP brings together multiple controls that are usually separated by function and therefore hard to integrate: applications, firewalls, and clients, to name a few. These pieces of information need unification in order to establish and ensure secure connections. SDP helps to integrate controls for firewalls, encryption, identity and access management (IAM), session management, and device management into a comprehensive security architecture. 1.2 SDP Principles The SDP architecture is based on the principles of least privilege and segregation of duties, enforced by implementing the following key controls and processes: Dynamic rules on drop-all firewalls Hiding servers and services Authentication before connections, for example not allowing connections before authorizing users on specific devices Using single packet authorization (SPA) and/or bi-directional encrypted communications like mutual transport layer security (mTLS) Fine-grained access control and device validation 1.3 Relationship Between SDP & ZT In this section, you will learn about the relationship between SDP and ZT. ZT is the umbrella category under which SDP falls. The ZT model is based on the following principles: Making no assumptions about the trustworthiness of an entity as it requests access to a resource Starting with no pre-established privileges, then relying on a construct which is used to add privileges Assuming breach and verifying all workforce, device, workload, network, and data access regardless of where, who, when, or to what resource In essence, the ZT concept retires the use of trusted entities inside a defined corporate perimeter. Instead, it mandates that enterprises create micro-perimeters around sensitive data assets to maintain control and visibility around data use across the environment. Essentially, ZT aims to defend enterprise assets by distrusting anything inside or outside the perimeter. Implementing ZT requires verifying connection requests to assets before granting access, followed by continuous monitoring and evaluation throughout the entire duration. For additional references on ZT concepts © Copyright 2022, Cloud Security Alliance. All rights reserved. 3 and architectures, please refer to the existing literature on the topic, and additional CSA training3. By comparing the foundational principles of SDP and ZT, it is clear that they are driven by the same high-level principle: “never trust, always verify”. In fact, SDP is considered one implementation type of a ZTA; others include Zero Trust Network Access (ZTNA) and Google BeyondCorp, to name a few. Compared to other ZTA implementations, SDP has some distinctive features and benefits, such as the use of a drop-all rule and the adoption of SPA. While these features are not necessarily unique to SDP, they are foundational to it; however, these features are not necessary requirements of other ZTA implementations. NOTE: SDP is a ZTA, but not every ZTA conforms with SDP requirements. 1.4 History of SDP In this section, you will learn about the history of SDP, its origins, and why it was developed. 1.4.1 The Origination of SDP SDP is a cybersecurity approach that evolved from the U.S. Defense Information Systems Agency’s Global Information Grid Black Core Network initiative in 20074. Designed to be extensible and future proof, this approach would later serve as the basis for CSA’s SDP framework in 2013. The CSA SDP framework focuses on how to control access to resources based on identity and device attestation. Per SDP, connectivity is provided on a need to know model that verifies device posture and identity before granting access to an application infrastructure. Because the application infrastructure exists without visible domain name system (DNS) information or IP addresses, it is effectively hidden and undetectable unless access is specifically granted. 1.4.2 The Business Case for SDP As organizations continue to undergo digital transformation, staying ahead of the threat landscape and attack chain curves is becoming increasingly difficult to achieve. Today, rather than managing and securing a single network, most organizations operate a variety of environment types, such as the following: Physical, on-premises networks Private clouds Multiple public clouds Virtual software-defined networking (SDN) environments 3 Cloud Security Alliance, “Publications,” https://cloudsecurityalliance.org/research/artifacts/ 4 DOD, “Vision for a Net-Centric, Service-Oriented DoD Enterprise,” June 2007, https://www. acqnotes.com/Attachments/DoD%20GIG%20Architectural%20Vision,%20June%2007.pdf © Copyright 2022, Cloud Security Alliance. All rights reserved. 4 Within these newer environments, organizations must facilitate the following: An expanding wide area network edge Information technology and operation technology convergence An increasingly mobile workforce As organizations shift from traditional infrastructures to more virtualized and hybrid architectures, new attack vectors also emerge that require a novel approach to network security. SDP’s designers focused on mitigating the most common network-based attacks, including server scanning, denial of service, SQL injection, operating system and application vulnerability exploits, man-in-the-middle, pass-the-hash, pass-the-ticket, to name a few. Despite the evolving cyber threat landscape, SDP continues to hold up against both existing and unknown threats. 1.5 Technology Benefits of SDP In this section, we will explore the technological benefits of SDP. Some of these include SDP’s attack surface reduction and pre-access authentication/authorization. We will also discuss SDP technologi- cal benefits such as IAM security and SDP’s open specification. 1.5.1 Reduced Attack Surface Today’s network architectures consist of devices with assigned IP addresses used for connectivity. When a device is establishing a connection to another device, a handshake is established and au- thentication is verified. By reversing this sequence and first verifying the connection, SDP provides key technical benefits, most notably attack surface reduction. Connectivity to an organization’s assets is provided only after authentication, validation/authorization, and the determination of which protected assets the user is allowed access to. These steps greatly reduce the attack surface of the application infrastructure. With SDP, users and devices are no longer granted general access to network segments or subnets. Instead, policies ensure that users and devices only have access to specified hosts, resources, and/ or services. Therefore, SDP can be used to protect different types of services or protocols such as Hypertext Transfer Protocol Secure (HTTPS) or remote desktop services (RDS). By controlling the ac- cess level that individual users and devices have to specific services, SDP can allow authorized users to access privileged services while hiding them from unauthorized users. 1.5.2 Authenticate & Authorize Before Access SDP is an inherently comprehensive security architecture implemented using software components overlaid onto physical and virtual infrastructure. SDP uses a drop-all gateway to ensure that authenti- cation and authorization is first performed in the control plane. By performing authentication prior to granting access to the perimeter, SDP ensures only users with appropriate authorization have access to the hidden infrastructure. © Copyright 2022, Cloud Security Alliance. All rights reserved. 5 This functionality (i.e., providing connectivity to resources after authentication and authorization) is made possible by separating the control and data planes, providing enhanced protection by exposing assets only to verified users and devices. Fine-grained access control is implicit in SDP’s design. Without the SDP gateway’s drop-all capability, allowing and enforcing only trusted connections would be prohibitively difficult. SDP’s architecture enables pre-access vetting and fine-grained access policies through role and attribute-based permissions, as well as other similar access control mech- anisms. Traditional architectures require separate implementations for each of these components, leading to increased complexity and higher maintenance overhead. In contrast to IP-based alternatives, SDP provides a connection-based security architecture — this means access is granted per each independent connection, versus granting access to a device based on its allowlisted IP address. SDP is a connection-oriented security architecture: while the physical infrastructure routes packets, SDP secures all connectivity over an infrastructure. This connection-based architecture distinction is important because of the current IP address explosion and the disintegrated perimeter in cloud envi- ronments — without SDP, IP-based security protections are ineffective when faced with this increas- ing complexity. SDP enables validation on the data plane prior to any Transmission Control Protocol/ Transport Layer Security (TLS/TCP) handshake and enforces mutually encrypted communications. This practice helps to mitigate threats related to unauthorized access. 1.5.3 Centralized Organizational IAM Security A prominent technical aspect of SDP is its centralized organizational IAM security. With IAM, a secu- rity problem on the front-end only requires an update to the SDP — every subsequent service with- in the perimeter will adjust to the heightened security measures. Traditional, direct access would require the checking and updating of potentially hundreds of services to address a single flaw. This is another example of how SDP drastically decreases maintenance overhead and complexity. Figure 2: Traditional IAM Security vs. SDP © Copyright 2022, Cloud Security Alliance. All rights reserved. 6 1.5.4 Open Specification Open specifications are publicly available and therefore directly benefit from greater community contributions. This increases the volume of data flowing in, the validity, and practicality of the specifi- cation that is developed, based on a given set of data. With an open specification you can customize the code or implementation to your needs, audit the code as it exists, and receive community feed- back on faults and errors. The SDP specification is open and has been proven on many network implementations, such as SDNs, IoT networks, network functions virtualization, edge computing, 5G, and more. As part of the research efforts, the CSA Software-Defined Perimeter Working Group teamed up with the com- munity at large to research how to create a high availability infrastructure using public clouds with the equivalent robustness of a dedicated data center. The CSA Software-Defined Perimeter Work- ing Group has also created additional reference materials, such as SDP Architecture Guide v25 and Software-Defined Perimeter as a DDoS Prevention Mechanism vs. SDP and DDoS6 that are publicly available. These documents were created with input from the global cybersecurity community. 1.6 Business Benefits of SDP In this section, we will discuss the various business benefits that companies gain from implementing SDP. As part of this discussion, we will examine how SDP enhances existing cybersecurity invest- ments, reduces costs and labor, and assists in governance, risk, and compliance (GRC) efforts. 1.6.1 Enhances Existing Cybersecurity Investments Organizations are under continuous pressure to respond to security events in a timely manner; to this end, they’ve made substantial investments in cybersecurity. For example, expenditures in vul- nerability management, patch management, and configuration management, have allowed organiza- tions to lock down machines that utilize IP addresses for connectivity. Threat intelligence combined with endpoint threat detection and response (EDR) may also be in place, enabling organizations to better understand who the unauthorized users are and what connections they are making. Many organizations also manage their own security operation centers to actively monitor for threats and respond to intrusion alerts and other security events. SDP helps optimize security investments and make them more cost effective as a result of both preventive and reactive security capabilities. SDP provides a preventive measure against network-based and cross-domain attacks. By hiding re- sources and applying the drop-all rules, SDP helps companies reduce their attack surface and conse- quently reduce the amount of security events or alerts that are collected by the security information and event management (SIEM) and sent to the security operation center. In addition, SDP reduces lateral movement in attacks by keeping assets invisible to unauthorized users. SDP helps reduce the 5 Cloud Security Alliance, “SDP Architecture Guide v2,” 7th, May 2019, https://cloudsecurityalliance. org/artifacts/sdp-architecture-guide-v2/ 6 Cloud Security Alliance, “Software-Defined Perimeter as a DDoS Prevention Mechanism,” 27th, October 2019, https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-as-a-ddos- prevention-mechanism/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 7 complexity of integrating controls like firewalls, IAM, encryption, and device management by main- taining all rules in one place instead of addressing them for each individual implementation. This al- lows companies to focus internal resources on a smaller set of potentially negative events, therefore increasing the cost-effectiveness of the security investments. Figure 3: SDP Ecosystem and Communication Flows7 1.6.2 Cost Reduction & Labor Savings Replacing traditional network security components with SDP reduces licensing and support costs. Implementing and enforcing security policies using SDP reduces operational complexity and reliance on traditional security tools. SDP also reduces costs of corporate backbone components by reduc- ing or replacing multiprotocol label switching (MPLS) or leased line utilization. As information and communication technology environments change, reliance on corporate backbone is reduced, and more dynamic networks are implemented. SDP allows organizations to achieve dynamic network im- plementations securely. Ultimately, SDP brings efficiency and simplicity to organizations, which can ultimately help reduce scarce and often expensive labor needs. 1.6.3 Reduces Compliance Scope As mentioned earlier, two of the main technology benefits of SDP are the reduction of the attack surface and an increased granular control over resource access. These two features, alongside mi- cro-segmentation, are key to helping organizations better face compliance challenges, as they allow the reduction of the scope of compliance. By better controlling where regulated data are processed and stored, and by limiting, both physically and logically, who can have access to that data, organiza- tions can reduce the scope of the compliance requirements. In addition, granular logging and moni- toring of who-does-what-when-why support the creation of a much-needed accountability approach, which is foundational to any compliance effort. 7 Figure adapted from NIST, “SP 800-207 Zero Trust Architecture,” August 2020, https://csrc.nist.gov/ publications/detail/sp/800-207/final © Copyright 2022, Cloud Security Alliance. All rights reserved. 8 2 Traditional Architecture Issues & SDP Solutions This unit reviews various issues that exist within current network security architectures. We will dis- cuss how SDP protects against threats that exist due to those architectural inadequacies. In addition, we will explore how SDP integrates with industry adopted solutions or replaces them. 2.1 Concerns SDP Addresses In this section you will learn about critical issues that SDP addresses, including the changing perime- ter, the IP address challenge, and the integration of security controls. 2.1.1 The Shifting Perimeter Virtualized networks have superseded the older, fixed network perimeter paradigm that relies on trusted internal network segments protected by network appliances (e.g., load balancers and fire- walls). Network protocols of the past are not secure by design and are known to have vulnerabilities. In addition, the plethora of mobile and IoT devices further challenge the validity of a fixed network perimeter. The introduction of the cloud has drastically changed the composition of organizations’ IT environ- ments. With the emergence of bring your own device (BYOD), machine-to-machine connectivity, the rise in remote access, and phishing attacks, legacy security approaches are no longer effective in protecting the shifting physical perimeter. For one, there are more internal devices and varieties of users. For example, contractors working on-site may require temporary access to IT resources, both on-premises and in the cloud. IT environments are also increasingly diversified with the continued enterprise adoption of hybrid architectures. Corporate devices are moving to the cloud, co-located facilities, and in some cases to off-site customer and partner facilities. These migrations further shift the physical perimeter of the organization; SDP addresses the inherent challenges of securing this shifting physical perimeter with a software overlay that creates virtual perimeters dynamically, when and where they are needed. 2.1.2 The IP Address Challenge Everything on the internet today relies on TCP/IP for trust. This is problematic, because IP addresses have no concept of users’ identities. TCP/IP simply addresses connectivity — it doesn’t validate the endpoint or the user as being trustworthy. TCP/IP is a bidirectional protocol, so internal trusted hosts communicating with external untrusted hosts can receive unsafe messages. Any changes to IP addresses may require extensive reconfigura- tion resulting in potential security group and network access control (NAC) list errors. Unmanaged/ forgotten internal hosts can provide an entry point for malicious actors by providing default respons- es using legacy protocols such as ICMP. This illustrates that common use of network address transla- tion (NAT) tables combined with TCP/IP is inherently open to compromise. © Copyright 2022, Cloud Security Alliance. All rights reserved. 9 IP addresses should not be used as anchors for network locations because they are location-depen- dent (i.e., users’ devices are assigned new IP addresses when they are relocated). SDP tackles this IP address challenge by securing connections while being IP address agnostic. This means that the SDP is aware of IP addresses but doesn’t rely on them for authorizing access to protected resources. 2.1.3 Integrating Security Controls The integration of multiple security controls like firewalls and identity managers is typically imple- mented to achieve compliance. However, integrating these controls to work as a whole in protecting the application infrastructure can be challenging. Currently, the integration of controls may be per- formed by gathering data in an SIEM for analysis; however, correlating disparate streams of security to gain deeper insights (e.g., who is connected, from what device, from where, to what, and more) is resource intensive. A single point of trust for network connections requires the following: Information about users, provided by the applications Information about the network, provided by firewalls Information about devices, provided by the client These disparate requirements make it difficult to implement an integrated set of controls for a physical network. Furthermore, integrating identity management prior to allowing access through a firewall requires the routing of packets to a different service — one that is resource-intensive and may or may not be proxied. In addition, most DevOps teams consider application layer firewalls and anti-denial of service/distributed denial of service (DoS/DDoS) protection as an afterthought; more- over, allowing individual applications to control their own security posture may result in catastrophe. Integrating access control, identity management, session management, and firewall management in today’s environments is highly difficult; SDP addressed this challenge by providing a unified location for implementing and managing controls for the entire environment, versus using traditional distrib- uted controls. 2.2 Threats SDP Protects Against In this section, we will analyze the efficacy of SDP for reducing cyber risk and mitigating threats. We will present well-known threats/cyber risks published by the OWASP, Verizon, and CSA that demon- strate the real value of ZTA using the SDP. As illustrated below, the integration of SPA and SDP with enterprise IAM helps raise the bar for security. The tables provide a high-level overview of the rele- vant risks/threats, results of a successful exploit execution, and how SDP can be leveraged to prevent these security incidents from occurring. © Copyright 2022, Cloud Security Alliance. All rights reserved. 10 2.2.1 CSA’s Egregious 11 Risk/Threat Result(s) of Successful SDP Mitigation Exploit Execution Data breaches Reputational damage, loss of SDP has a drop-all firewall that customer/partner trust, loss drops packets not explicitly of intellectual property to configured, preventing data competitors which may impact breaches and/or preventing product releases, regulatory their scope of damage. implications that may result in monetary loss, brand damage/ market value loss, legal and contractual liabilities, and financial expenses incurred due to incident response and forensic analysis Misconfigurations & Exposure of data stored in SDP assists in change inadequate change control cloud repositories control by providing access configured for changes only after approval. Lack of cloud security Financial loss, reputational SDP has a ZT policy that architecture & strategy damage, legal repercussions, outlines a framework with and fines systems designed around the value of the data and its specific protection needs. Insufficient identity, Unauthorized access, Authentication, authorization, credential, access, & key exfiltration, modification, and mutual factor management deletion of data, issuing of authorization (MFA) is at the control plane and management core of SDP; subsequently, functions, eavesdropping on using SDP integrated with data in transit, and the release enterprise and cloud IAM/ of malicious software that identity provider (IdP) reduces appears to originate from a the attack surface. legitimate source © Copyright 2022, Cloud Security Alliance. All rights reserved. 11 Account hijacking Complete deletion of Authentication, authorization, organization assets, data and and MFA is at the core of SDP; capabilities, data leaks and using SDP integrated with resulting brand/reputational enterprise and cloud IAM/ damage, legal liability due IdP limits the exposure for to sensitive personal and account hijacking. business information exposure Insider threat Loss of proprietary information SDP includes micro- and intellectual property, segmentation of the system downtime impacting organizational environment company productivity, and to ensure that access to other customer data losses resources are granted on a that reduce their confidence in need to know basis. SDP’s the organization’s services continuous logging integrated with user entity behavior analytics can limit the data loss and/or alert on malicious/ abnormal activity and behavior. Insecure interfaces & APIs Regulatory and financial impact SDP provides controls defining in the form of fines/penalties, communication endpoints (as security issues related to long as the interface and API confidentiality, integrity, communications sit behind availability and accountability the SDP controller). Weak control plane Data loss, either due to theft SDP’s control plane is or corruption, resulting in protected by both network a substantial impact on the level controls (e.g., SPA), and business — particularly if the strong authentication. incident includes privileged user data, and regulatory punishment for data loss may be incurred Metastructure/application Failures at the cloud service SDP limits the impact of infrastructure failures provider level, resulting in misconfigurations by hiding customers being severely resources behind the gateway/ impacted, and tenant controller. misconfigurations could result in financial losses and operational disruptions © Copyright 2022, Cloud Security Alliance. All rights reserved. 12  Limited cloud usage visibility Lack of governance, SDP logs all inbound activity, awareness, and security providing better visibility and situational awareness. Abuse of cloud services Financial losses due to SDP safeguards access to excessive metered cloud stateful (e.g., security group/ use (e.g., attackers using network security group) and compromised cloud servers as stateless (e.g., access control a malware distribution host) list/network access list) firewall configurations. Coupling security group/ network security group and access control list/ network access control list configurations enables the dropping of unauthorized traffic (e.g., for mining cryptocurrency or distributing malware). Table 1: Top Threats to Cloud Computing: Egregious Eleven Deep Dive8 2.2.2 Verizon’s DBIR Risk/Threat Result(s) of Successful SDP Mitigation Exploit Execution Phishing & Acquisition of credentials SDP’s integration with social engineering domain-based, message authentication/reporting, as well as its requirements for validating source networks and capabilities (e.g.,MFA and device fingerprinting) reduce the risk of these attacks. 8 Cloud Security Alliance, “Top Threats to Cloud Computing: Egregious Eleven Deep Dive,” 23rd, September 2020, https://cloudsecurityalliance.org/artifacts/top-threats-egregious-11-deep-dive/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 13  Web application attacks Stolen credentials and SDP’s use of SPA for inbound/ successful brute force outbound server traffic attempts that enable coupled with MFA helps unauthorized access to web prevent these attack types application servers, mail (i.e., requiring authentication servers, and others IT assets, prior to authorizing access). resulting in compromised privileged data (e.g., medical records, employee data) Lost or stolen credentials Exposure of sensitive data SDP’s MFA requirement minimizes the impact of stolen credentials, since malicious actors are not given explicit access to resources. Ransomware Revenue loss and supply chain SDP prevents the disruption installation of unapproved software and potentially malicious applications (e.g., ransomware) on servers. Miscellaneous errors Eavesdropping, data loss, data SDP requires authentication compromising security exposure, and unauthorized prior to accessing applications access and/or server resources. DoS Loss of service and/or service SDP controls communication disruption endpoints and is therefore stateless; drop-all firewalls block threats such as malware and command and control servers. System intrusion Eavesdropping, data loss, data SDP requires the use of SPA exposure, and unauthorized to/from the server. Coupled access with MFA, these controls help to enforce authentication prior to authorized access. Privilege abuse Eavesdropping, data loss, data SDP’s MFA requirement exposure, and unauthorized prevents unauthorized access access and escalation of privileges from occurring. Table 2: DBIR- 2021 Data Breach Investigations Report9 9 Verizon, “2021 Data Breach Investigations Report,” 2021, https://enterprise.verizon.com/resources/ reports/2021-data-breach-investigations-report.pdf © Copyright 2022, Cloud Security Alliance. All rights reserved. 14 2.2.3 OWASP IoT Top 10 Risk/Threat Result(s) of Successful SDP Mitigation Exploit Execution Weak, guessable, or hard Unauthorized access SDP authenticates users prior coded passwords to granting them access; additionally, MFA helps mitigate the risk of stolen/lost credentials and devices. Insecure network services Unauthorized access SDP requires encryption for enforcing confidentiality in an insecure network. For example, devices must support encryption in order for SPA over HOTP (HMAC One Time Password) and data communications via mTLS to function (in protecting confidentiality). Insecure ecosystem Unauthorized access SDP unifies the different interfaces ecosystem interfaces into a secure, single source of truth. Lack of secure update Unauthorized access SDP and SPA provide device mechanism authentication and valid endpoints via mTLS, allowing for secure over-the-air authentication and device update mechanisms. Use of insecure or outdated Eavesdropping, data loss/ SDP leverages ZT call flows in components exposure, and unauthorized the TCP/IP network, thereby access protecting legacy, insecure or outdated components. Insufficient privacy Eavesdropping and data loss/ SDP requires encryption in protection exposure order for SPA over HOTP to function and ensure confidentiality. © Copyright 2022, Cloud Security Alliance. All rights reserved. 15  Insecure data transfer & Eavesdropping and data loss/ SDP requires encryption in storage exposure order for SPA over HOTP and data communications via mTLS to function and ensure confidentiality. Lack of device management Unauthorized access SDP provides secure mobile device management by enabling device management and software updates via SPA and mTLS. Insecure default settings Unauthorized access SDP requires micro- segmentation as well as MFA to mitigate the risk of outdated/unpatched and misconfigured devices. Lack of physical hardening Unauthorized access SDP couples automated device auditing with secure device management to validate device security postures. Table 3: OWASP IoT Top 1010 2.2.4 OWASP Top 10 Risk/Threat Result(s) of Successful SDP Mitigation Exploit Execution Broken access control Unauthorized access SDP authenticates users and validates that requests are authorized prior to granting access. Cryptographic failures Exposure of sensitive data or a SDP enforces cryptography compromised system requirements (e.g., in mTLS sessions). Injection Malicious injection and SDP mitigates application alteration of responses to attacks through its inherent compromised application MFA and SPA/drop-all server approach. 10 OWASP, “OWASP IoT Top 10,” 2018, https://owasp.org/www-pdf-archive/OWASP-IoT-Top-10-2018- final.pdf © Copyright 2022, Cloud Security Alliance. All rights reserved. 16 Insecure design Exploitation of vulnerabilities SDP helps bolster threat modeling, secure design principles, patterns, and design practices affecting reference architectures and configuration audits. Security misconfiguration Exposure of data and SDP mandates micro- exploitation of application segmentation and MFA vulnerabilities — critical SDP features for mitigating the impact of security misconfigurations. MFA limits the escalation of privileges and reduces the blast radius of attacks. Vulnerable & outdated Exploitation of known SDP prevents legacy, insecure, components vulnerabilities or outdated components from being attacked by hiding the associated services from unauthorized users/devices. Identification & Privileged access escalation SDP mandates micro- authentication failures and lateral movement segmentation and the granting of access to resources based on the requester’s need to know/ need for access. Software & data integrity Insertion of malicious code Leveraging the SPA, SDP failures into critical path continuous uses endpoint authentication integration/continuous to assist with verifying the delivery (CI/CD) pipelines integrity of CI/CD pipelines (e.g., open source software, and software updates. containing malicious code) Security logging & Lack of visibility into SDP enforces comprehensive monitoring failures unauthorized or malicious and continuous monitoring. events With logging/monitoring services in place per SDP’s requirements, security incidents can be remediated in a timely manner. © Copyright 2022, Cloud Security Alliance. All rights reserved. 17  Server side request forgery Unauthorized access and SDP helps mitigate attacks compromise of vulnerable to applications exposed applications and related/ on a network through its connected back-end systems. inherent MFA and SPA/drop-all Attackers may also use this approach. exploit method to circumvent user input validation Table 4: 2021 Draft OWASP Top 1011 In addition, the following sections address some of the various threats that SDP helps protect against. These include server exploitation and hijacking, among others. 2.2.5 Server Exploitation Threats SDP features like server isolation, SPA, and dynamic drop-all firewalls bolster application infrastructure security and help protect against server exploitation threats such as the following: DoS/DDoS attacks Code injection attacks Other attacks that exploit server misconfigurations/vulnerabilities 2.2.6 Hijacking Threats SDP attributes such as encryption, pinned certificates, and non-reliance on DNS protect against connection hijacking threats like the following: Man-in-the-middle (MITM) attacks Certificate forgery DNS poisoning Code injections 2.2.7 Other Threats SDP features like MFA, mTLS, and device fingerprinting protect against the following: Phishing Keyloggers Brute force attacks For further information, please refer to CSA’s SDP Architecture Guide12 and existing research on SDP and ZT13. 11 Footnote 12: OWASP, “OWASP Top 10,” 2021, https://owasp.org/Top10/ 12 Cloud Security Alliance, “SDP Architecture Guide v2,” 7th, May 2019, https://cloudsecurityalliance. org/artifacts/sdp-architecture-guide-v2/ 13 Cloud Security Alliance, “Software-Defined Perimeter (SDP) and Zero Trust,” 27th, May 2020, https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-and-zero-trust/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 18 2.3 SDP & Industry Adopted Solutions In this section, you will learn about various industry adopted solutions and how SDP replaces or works in conjunction with them. This includes NAC, virtual private networks (VPNs), IAM, and next generation firewalls (NGFW). 2.3.1 Network Access Control NAC typically controls what devices can connect to a given network and which network locations or segments they have access to. These solutions use a combination of standards-based hardware (e.g, 802.1X for port-based NAC) and software to validate devices, prior to granting them network access. NAC typically operates at layer 2 (i.e., the data link layer) of the OSI model. When a device first appears on the network, the NAC performs device validation followed by assignment to the correct network segment (e.g., virtual local area network). In practice, NACs coarsely assign devices to a small number of networks, as most organizations only have a few networks set up (e.g., guest, employee, and production). Because NACs operate at layer 2 of the OSI model, they more often require specific network equipment, don’t operate in cloud environments, and are not used by remote users. Figure 4: SDP as NAC Replacement In some respects, SDP can be considered a modern replacement for NAC. Though they share similar functionalities, SDP, unlike NAC, does not require specific network hardware to function. This allows for the integration of users and provisioning of device access without a dedicated network appliance. SDP fully supports cloud environments and remote access, overcoming traditional NAC limitations. However, some environments are more suitable for NAC implementations — for example, those with printers, copiers, landline phones, or security cameras. These devices are often 802.1X compliant with built-in support, which means they don’t typically support the installation of an SDP client. In this case, the gateway-to-gateway model is a better option for protecting and managing access to these devices. © Copyright 2022, Cloud Security Alliance. All rights reserved. 19 2.3.2 Virtual Private Network VPNs establish secure private network connections over untrusted networks. Commonly used for secure remote access (e.g. employee access to a corporate site, secure site-to-site communications, or site-to-site extranets between companies), VPNs use TLS/Secure Sockets Layer (SSL) or Internet Protocol Security (IPSec) to establish an encrypted tunnel. Although VPNs encapsulate and encrypt network traffic, they also allow unrestricted access to a network segment. This is risky, especially if credentials are compromised. In contrast, SDP will only allow access to specifically assigned applications in the network segments. On the user experience side, VPNs tend to impose a considerable burden on users, especially in environments undergoing significant cloud-based transformations and migrations. IT may also need to configure VPN for users requiring secure access to multiple sites, as this prevents unintentional network bridging and systems from connecting to multiple locations simultaneously. Ultimately, this shifts the burden and inconvenience of switching back and forth between remote locations on the user. 1. In distributed environments, VPNs may require the unnecessary backhauling of user traffic through a corporate data center, adding latency and bandwidth costs. 2. VPN servers themselves expose the network on the internet. VPN servers contain security vulnerabilities as do most IT components, which an attacker could exploit to gain access and exfiltrate data or perform other malicious activities. 3. VPN licensing costs are not expensive, but anecdotally they can be difficult to implement and maintain. Whenever cloud migration is involved, VPN management balloons in complexity. This is because IT administrators need to configure and sync VPN and firewall policies across multiple locations,making it even more difficult to mitigate unauthorized access. Figure 5: SDP as VPN Replacement © Copyright 2022, Cloud Security Alliance. All rights reserved. 20 VPNs are a prime technology use case for replacement by SDP — however, it’s worth noting that SDP can work alongside existing VPNs or replace them entirely, depending on the deployment model. However, both require an installation of a client on the user’s device. By using SDP instead of VPNs, organizations can have a single access control platform consistent for secure access to cloud, remote, on-premises, and mobile device users. Since SDPs enable zero visibility via SPA and dynamic firewalls, they are considerably more resilient to cyber attacks than traditional VPN servers. 2.3.3 Identity & Access Management The SDP architecture is designed to integrate with existing enterprise IAM providers in the cloud, on-premises, or hybrid environments. IAM provides a unified mechanism for users and devices to be validated, authenticated, and authorized. It provides a way to store managed identity attributes and group memberships within a central system using protocols to enable access directly or via federation. SDP supports standard protocols and security mechanisms used by IAM, including Lightweight Directory Access Protocol (LDAP), Active Directory (AD), and Security Assertion Markup Language (SAML). Figure 6: SDP and IAM SDP typically controls access based on business rules. These rules can be built up from IAM attributes and group memberships, as well as from the attributes of devices making the connection and/or the network segments themselves. The telemetry data provided by these sources enables the creation of granular access rules for allowing/restricting access. This ensures only users requesting specific access on registered devices are granted authorization to the resources in question. Integration of SDP with IAM is not only used for initial user authentication; it’s also commonly used in conjunction with step-up authentication (e.g., prompting for a one-time password to access sensitive resources). IAM systems can also communicate with an SDP via API calls, as SDP can respond to identity lifecycle processes in this configuration. Some examples include joiners, mover, and leavers (JML), disabling an account, group membership changes, and dropping user/device connections from certain geographic locations. © Copyright 2022, Cloud Security Alliance. All rights reserved. 21 In order to authenticate users, SDP must leverage IAM to access identity telemetry information that the SDP controller uses to make authorization decisions. IAM data is not only used to augment the SDP controller’s capabilities — it’s also used for populating audit logs with additional details regarding user and device access (e.g., access granted/denied details). Compared to traditional network access and IP address information, IAM telemetry correlates application access to users, yielding far more useful data with less overhead. This reduced overhead is leveraged primarily by IT when auditing historical access records in security or compliance use cases. 2.3.3.1 SDP & Identity Lifecycle Management In identity lifecycle management, IAM tools focus on the business processes for maintaining the identity lifecycle (i.e., the JML process). IAM standardizes how identity information is used to control access to resources, using access methods such as role-based and attribute-based access control. SDP supports these IAM processes and relies heavily on IAM-managed identity attributes and group memberships. As user attributes or group memberships change, SDP will alter access permissions accordingly without changing IAM telemetry, as SDP is a downstream system. These processes are utilized by SDP via standard protocols like SAML, AD, LDAP, or through the use of APIs. 2.3.3.2 SDP & Open Authentication Protocols SDP integrates with open authentication protocols such as SAML. Within an SDP deployment, a SAML entity might act as an identity provider for user attributes and/or as an MFA authentication provider. In addition to SAML, SDP integrates with many other open authentication protocols such as OAuth, OpenID Connect, W3C Web Authentication, and the FIDO Alliance Client-to-Authenticator Protocol. These protocols will be explored in future SDP-related research, but are not in scope for this training. 2.3.4 Next Generation Firewall NGFWs have all the capabilities of traditional firewalls, along with additional capabilities such as intrusion detection/prevention and deep packet inspection. NGFWs filter data using the information in layers 2 through 4 of the OSI model (i.e., the data-link, network, and transport layers). Additionally, NGFWs use the information in layers 5 through 7 (i.e., the session, presentation, and application layer) to perform additional functions. Depending on the vendor, NGFWs may provide some or all of the following capabilities: Application awareness – recognizes applications to determine what attacks to look for Intrusion detection/prevention system (IDPS) – monitors the security status of the network and denies traffic to prevent security problems Identity awareness (user and group control) – controls which resources users can access VPN – allows for remote user access across an untrusted network © Copyright 2022, Cloud Security Alliance. All rights reserved. 22 While NGFWs represent a significant improvement over traditional firewalls, they still have their limitations. Some of these include: Latency – as is the case with IDPS, NGFWs will cause additional network latency, especially if they’re performing file inspection Scalability issues – a NGFW requires more robust hardware to scale Rule complexity – some NGFW vendors include identity management capabilities such as user/group attribute assignments, but anecdotally these tend to be complex to implement SDP is a natural complement to existing NGFWs. Enterprises can use SDP for secure user access policies while leveraging their NGFWs for core firewall, IDPS, and traffic inspection capabilities. By integrating SDP with a NGFW, enterprises can at once enforce the zero visibility principle and make them more dynamic. User access policies can be achieved by integrating NGFWs with IAM or AD. By combining NGFW VPN capabilities with user and application awareness, enterprises can, to some degree, accomplish many of the goals of SDP. However, there are some general architectural differences. NGFW systems are IP-based and offer limited identity and application-centric capabilities, whereas SDP is connection-based and therefore easier to control authorized connections. Additionally, NGFWs tend to be much less dynamic than SDPs, while the latter often supports the ability to include external systems in access decisions. For example, a prime use case for SDP is to only permit developer access to staging servers during an approved change management window. Since NGFWs are still firewalls, their network deployment/design patterns still favor traditional perimeter-centric network architectures with site-to-site connections between locations. On the other hand, SDP deployments usually support more distributed and flexible networks, thereby enabling a flexible network segmentation capability. SDP is fundamentally based on a need to know security principle, which by design hides all unauthorized services from users and leverages SPA and dynamic firewalls to hide connections protected by the SDP. NGFWs are not designed to function this way and typically result in environments that are more visible and therefore higher risk than with SDP. It should be noted that NGFWs have not yet been able to integrate authentication and authorization controls prior to allowing connections. © Copyright 2022, Cloud Security Alliance. All rights reserved. 23 3 Core Tenets, Underlying Technologies, & Architecture In this unit you will learn the foundation of how SDP works and how it accomplishes its task of providing network security. We will explain SDP’s core tenets, underlying technologies, architectural components, and secure workflow. 3.1 SDP Core Tenets SDP has three core tenets that govern its implementations: assume nothing, trust no one or thing, and validate everything. These tenets are used as the building blocks of the SDP framework. SDP was designed to secure dynamic workloads, most prominent in cloud mobile environments, by providing the following: Software-defined, dynamic, endpoint validation A connection-based paradigm Integration of firewalls, identity and access, session, encryption, and device management These design features are covered in CSA’s SDP Specification v214. Figure 7: SDP Core Tenets Tree 14 Figure adapted from Cloud Security Allaince, “Software-Defined Perimeter (SDP) Specification v2,” 10th, March, 2022, https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-zero-trust- specification-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 24 3.2 Underlying Technology In this section, we will introduce and discuss the underlying technologies that support the SDP architecture, including drop-all firewalls, separate control and data planes, mTLS, and SPA. SDP provides a security architecture designed from the ground up using these foundational technologies. 3.2.1 Drop-All Firewall The drop-all firewall is the most critical underlying technology of the SDP. Using drop-all rules, these firewalls operate according to the principle of least privilege: all actions not explicitly allowed remain forbidden. This strategy supports the ability to add rules to the firewall dynamically for post- authentication access level changes. An SDP deployment can identify and deny risky transactions based on the analysis of a single packet. When malicious actors attempt to connect, SDP uses a drop-all rule to drop all unauthorized packets at the perimeter. This approach is highly effective as it only focuses on allowing approved actions, rather than blocking unapproved actions. 3.2.2 Separate Control & Data Planes The three basic components of an SDP architecture are the data plane, control plane, and management plane. The data plane — also known as the user plane, forwarding plane, carrier plane, or bearer plane — is the part of a network that carries user traffic. In SDP, the control plane and management plane enable the data plane, which bears the traffic that the network carries. The control plane is responsible for establishing connections and dropping unauthorized packets at the perimeter. The control plane takes care of authenticating and authorizing users and devices prior to sending data to the SDP gateway. No devices are allowed to reach the data plane until the user and device in question are validated at the control plane. In traditional architectures, data and control planes are commonly implemented together. In contrast, SDP architectures place the control plane outside the organization’s perimeter; subsequently users and devices do not enter the organization’s environment until they are authenticated and authorized. By separating the data plane from the control plane, SDP enables the external control plane to perform authentication and authorization before granting access to resources. 3.2.3 Mutual Transport Layer Security SDP uses mTLS authentication to ensure that client-server traffic is secure and trusted in both directions. This allows requests that do not log in with an identity provider (e.g., requests from IoT devices) to demonstrate that they are permitted access to a given resource. Client certificate authentication adds an additional security layer for team members who both log in with an identity provider and use a valid client certificate for authentication. © Copyright 2022, Cloud Security Alliance. All rights reserved. 25 Chiefly, mTLS is ideal for use in the following IT environments: A limited number of programmatic and homogeneous clients connect to specific web services The operational burden is limited Security requirements are more stringent compared to consumer environments Subsequently, mTLS authentication is more widely used in business-to-business applications. 3.2.4 Single Packet Authorization SPA is a protocol that allows a user to make a request to a server. This request cannot be replayed and uniquely identifies the user. SDP uses SPA to compensate for the fundamentally open and insecure nature of TCP/IP. In addition, SDP uses SPA to authorize a valid device and authenticate a user identity. SPA then permits access into the perimeter and the relevant system component. The purpose of SPA is to allow assets within the perimeter to be restricted via a default drop-all firewall. While implementations of SPA may differ slightly, they should share the following common concepts for an SDP implementation: An SPA packet must be encrypted and authenticated An SPA packet must self-contain all the necessary information Packet headers are not considered trustworthy A SPA packet must not depend on administrator or root level access in order to generate and send There is no raw packet manipulation The server must receive and process the SPA packet as silently as possible, no response or verification is sent 3.2.4.1 SPA Benefits The key advantage of using SPA is service restriction. A default drop-all firewall posture prevents port scanning and other attacker-related reconnaissance techniques. It effectively renders the SPA components invisible to unauthorized users, significantly reducing the attack surface of the SDP system. This compares favorably to systems such as VPNs, with open ports and known vulnerabilities in many implementations. There are subsequent benefits to restricting services. One is zero-day protection. Any newly discovered vulnerability becomes significantly less critical when only authenticated users can access the affected service. Another benefit is DDoS protection. A relatively small amount of traffic can take an HTTPS service offline if that service is exposed to the public internet for attack. A SPA makes that service visible only to authenticated users. Therefore, a DDoS attack is handled by a default drop-all firewall instead of the protected service itself. One of the core goals of SDP is to overcome the fundamentally open, or insecure nature of TCP/ IP, which follows a connect, then authenticate model. Amid today’s threat landscape, it’s simply © Copyright 2022, Cloud Security Alliance. All rights reserved. 26 unacceptable to permit malicious actors to scan and connect to enterprise systems. There are far too many known and unknown vulnerabilities in systems to allow this. SPA and SDP solve this problem in two ways. First, applications using the SDP architecture are hidden behind an SDP gateway so that they’re only accessible to authorized users. Second, the SDP components themselves, the controller and gateway, are protected by SPA. This allows them to be securely deployed with internet-facing placement, ensuring that legitimate users have productive and reliable access, while they remain invisible to unauthorized users. 3.2.4.2 SPA Limitations SPA is only a part of SDP and is not a complete security architecture on its own. While SPA implementations should be designed to be resilient to replay attacks, SPA may be subject to a MITM attack; specifically, if MITM adversaries are able to capture or alter the SPA packet, they can potentially establish the TCP connection to the controller or accepting host (AH) in place of the authorized initiating host (IH). However, these adversaries will be unable to complete the mTLS connection, since it will not have the client’s certificate. The controller or AH should therefore reject this connection attempt and close the TCP connection. Even considering this limitation, which only applies to the MITM scenario, SPA is more secure than standard TCP. 3.3 SDP Architecture Components In this section, we will discuss the foundational SDP architecture components: IH, AH, gateways, SDP clients, and the controller. SDP provides an integrated security architecture that is otherwise hard to achieve with security point products. SDP integrates the following discrete architectural elements: Identity-aware applications Client-aware devices Network-aware firewalls/gateways 3.3.1 Initiating Hosts IH initiate connections to the SDP. IH are devices, including laptops, tablets, and smartphones that SDP client software is run on. This host environment may be on a network outside the control of the enterprise operating the SDP. 3.3.2 SDP Client The SDP client consists of software installed on the IH device. The client initiates connections in order to cryptographically sign in to the SDP. The SDP client typically generates the SPA packet for the SDP gateway after completing the authentication and authorization process with the SDP controller. © Copyright 2022, Cloud Security Alliance. All rights reserved. 27 3.3.3 Accepting Hosts AH are devices that accept connections from IH and provide a set of services that are protected by the SDP. They typically reside on a network under the control of the enterprise (and/or direct representative) operating the SDP, and do not acknowledge communications from any other host or respond to non-provisioned requests. To unauthorized users and devices, AH remain cloaked and inaccessible while using SDP’s SPA. 3.3.4 Controller The SDP controller is an appliance or process that secures access to isolated services. It does this by ensuring that users are authenticated and authorized, devices are validated, secure communications are established, and user and management traffic on a network remain separate. Like the AH, the controller is also protected by SPA, making it invisible and inaccessible to unauthorized users and devices. Both IH and AH connect to the SDP controller. 3.3.5 Gateway The SDP gateway is an appliance or process that provides access through the invisible perimeter for authorized users and devices. Through this gateway, authorized users and devices are able to access protected processes and services. The gateway can also effectively allow monitoring, logging, and reporting on these connections. The functionality of the gateway depends on where it is located. 3.4 SDP Secure Workflow In this section we will break down SDP’s workflow, illustrating how all of the architecture components discussed in the previous section work together. The following is the most basic SDP workflow for allowing an IH and AH to communicate securely: 1. The AH is cloaked by an SDP gateway on the AH or a similar construct. 2. An SDP controller is added and activated within the SDP and connected to authentication and authorization services (e.g., IAM, public key infrastructure service, device attestation, geolocation, SAML, OpenID, OAuth, LDAP, Kerberos, MFA, and identity federation). 3. An AH is added and activated within the SDP by checking into the SDP controller. It connects to and authenticates with the controller in a secure manner. 4. The IH is added and activated within the SDP, then connects to the SDP controller. The SDP controller authenticates the IH and determines a list of AH the IH is authorized to communicate with. 5. An SPA packet is always sent to establish communications, leaving the application layer cloaked from all but authorized users. In order to establish access after sending an SPA packet, the IH and AH exchange a mutual handshake using TLS for control plane communications. 6. The IH sends a login message request and receives a response from the controller. 7. The controller sends the IH a list of services available (based upon services allowed). © Copyright 2022, Cloud Security Alliance. All rights reserved. 28  8. The controller also sends a message stating that the IH has been authenticated with the AH. 9. Another SPA packet is sent from the IH to the AH for data plane communications. 10. Finally, a separate mTLS handshake establishes communication for data transfers. Figure 8: SDP Secure Workflow15 4 The Basics of SDP Deployment Models This unit will cover the various SDP architectural considerations to take into account before implementation. Along with this, you will learn the basics of SDP deployment models. 4.1 Architectural Considerations Several architectural considerations must be taken into account when deploying SDP. For example, organizations should evaluate how an SDP deployment fits into existing network topologies and technologies. Other critical considerations include how SDP impacts users, monitoring, logging, onboarding, application release, and device validation. 15 Figure adapted from Cloud Security Allaince, “Software-Defined Perimeter (SDP) Specification v2,” 10th, March, 2022, https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-zero-trust- specification-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 29 4.1.1 Existing Network Topologies & Technologies Network architects should select the SDP deployment model best suited for their particular use case. However, some models require additional in-line network components like gateways, resulting in network changes like adding firewalls or making routing alterations. This ensures that protected resources are hidden and only accessible through the SDP gateway. To fully leverage the capabilities of SDP, architects should consider proper micro-segmentation, keeping in mind that SDP ensures secure connections irrespective of the underlying network infrastructure. Enterprise security architectures16 can be complex, with numerous stakeholders across the organization and business units, as well as governance, risk management, and compliance (GRC) requirements alongside daily IT infrastructure operations and management. Architects should keep these factors in mind when planning their enterprise’s SDP deployment. 4.1.2 Monitoring & Logging Systems SDP affects monitoring and logging architectures. Because it uses mTLS between the IH and AH, SDP also hides network traffic from intermediary services, which may be in place to monitor for security, performance, or reliability. Architects must understand what systems are in operation and how the changes to the network traffic may affect them. However, SDP typically provides richer, identity- centric logging of user access — ideal for augmenting and enhancing existing monitoring systems for a more focused traffic monitoring scope and purpose. In addition, all dropped packets from SDP gateways and controllers can be logged, monitored, and analyzed using security tools like intrusion detection systems/intrusion detection and prevention systems (IDS/IDPS) and SIEMs. With an SDP in place, it is easier to collect the who, what, when, how, why information for every connection versus each individual packet. 4.1.3 Application Release & DevOps High-velocity application release practices like DevOps17 and its supporting automation and CI/ CD framework require thoughtful integration with SDP. An SDP can be integrated with DevOps to secure authorized users’ connections to the various deployment environments (e.g., development, test, staging, and production), as well as used during operations to ensure legitimate users have proper connectivity to protected servers and applications. Ideally, the SDP will be integrated into the application stack to fully leverage its security features. Common DevOps practices such as the use of virtualized environments and containers can further streamline SDP integration; that said, security architects must fully understand the chosen SDP deployment model and how their organization’s DevOps mechanisms will interact and integrate with it. When it comes to DevOps toolset integration, security teams should carefully review and evaluate third party APIs supported by their SDP implementation. 16 Sometimes referred to as enterprise information security architecture 17 Cloud Security Alliance, “Enterprise Architecture Reference Guide,” 18th, May 2021, https:// cloudsecurityalliance.org/artifacts/enterprise-architecture-reference-guide-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 30 4.1.4 User Experience Security teams typically strive to have their solutions work as transparently as possible, with minimal user interruption. SDP is similar to any security control where proper application of least privilege principles balances the user experience with security. Depending on the SDP deployment model, users will need to run the SDP client software on their devices. Security architects should collaborate with IT to model and plan for the user experience, client software distribution, and device onboarding processes. 4.1.5 Onboarding The onboarding process of SDP controllers, IH, AH, and users will vary depending on the chosen deployment models. SDP systems can be managed via an API or administrative user interface. A typical SDP onboarding process flow would involve the following steps: 1. One or more SDP controllers are brought online and connected to the appropriate optional authentication and authorization services. 2. One or more AHs are enlisted as SDP gateways. These gateways connect to and authenticate with the controllers. 3. One or more clients on the IHs are onboarded, with each user/entity authenticated by the SDP controller. Note: Because the onboarding process is distinct from the user authentication process, users are only onboarded once but will require authentication/authorization for each subsequent connection. Figure 9: Onboarding Process Flow18 18 Figure adapted from Cloud Security Allaince, “Software-Defined Perimeter (SDP) Specification v2,” 10th, March, 2022, https://cloudsecurityalliance.org/artifacts/software-defined-perimeter-zero-trust- specification-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 31 4.1.6 Device Validation mTLS proves that the device requesting access to the SDP possesses a valid, non-expired/non- revoked private key. However, this method can be compromised, as an attacker with a stolen key cannot be distinguished from a legitimate user/key. Device validation can help to further establish a trusted connection based on certificate-based keys. Per SDP, the controller acts as the trusted device because it resides in the most heavily controlled environment. The initiating and AHs must then validate themselves with the controller, thereby preventing unauthorized access via stolen keys. 4.2 Deployment Models In this section we’ll introduce the various SDP deployment models and explore their similarities and differences. As an architecture, SDP provides the protocol to secure connections at all layers of the network stack. By deploying gateways and controllers at key locations, SDP implementers can focus on securing and protecting the most critical connections from both network-based and cross-domain attacks. All the SDP models support identity-driven network access control/authorization, and most can accommodate existing network security tools like IDS/IDPS and SIEMs by enabling the analysis of dropped packets and unsecured connections. SDP secures the connections between components, as depicted in each of the deployment models described below. More information on these deployment models can be found in the SDP Architecture Guide v219. Figure 10: SDP Deployment Models20 19 Cloud Security Alliance, “SDP Architecture Guide v2,” 7th, May 2019, https://cloudsecurityalliance. org/artifacts/sdp-architecture-guide-v2/ 20 Figure adapted from Cloud Security Alliance, “SDP Architecture Guide v2,” 7th, May 2019, https:// cloudsecurityalliance.org/artifacts/sdp-architecture-guide-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 32 Figure 11: Client-to-Gateway Model 21 4.2.1 Client-to-Gateway Model The client-to-gateway model is suitable for use cases where one or more servers need to be protected behind a gateway. This approach is preferred when an organization is moving its applications to the cloud or securing on-premises legacy applications. The client (i.e., the IH) and gateway may be in the same location or distributed across the globe. In either case, the connections between the client and the gateway are secured, regardless of the underlying network topology. In this model, the client is connected to the gateway directly via an mTLS tunnel where the connection terminates. To secure the connection to server environments, additional precautions must be taken. For example, the network on which the server environments reside, will need to be configured to permit inbound connections to protected servers from the gateway only. This prevents unauthorized clients from bypassing the gateway. The gateway should be configured to deny all traffic by default, and explicitly allow approved traffic. The same gateway can be used for the controller and servers by locating the controller in the cloud or near the protected servers. This model preserves the ability for an organization to use its existing network security components, such as IDSs or IPSs, by deploying them between the SDP gateway and the protected servers. 21 Figure adapted from Cloud Security Alliance, “SDP Architecture Guide v2,” 7th, May 2019, https:// cloudsecurityalliance.org/artifacts/sdp-architecture-guide-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 33 Figure 12: Client-to-Server Model22 4.2.2 Client-to-Server Model The client-to-server model is ideal when moving applications to an IaaS provider, as it combines the server and gateway in a single host to ensure connections are secured end-to-end. Organizations are afforded a great deal of flexibility due to the portability of server-gateway combinations between multiple IaaS providers. Client-to-server is also appropriate for securing on-premises legacy applications that cannot be upgraded. With this model, the protected servers will need to be outfitted with the gateways. The network on which the servers reside do not need configuration to restrict inbound connections to the protected servers, as the gateways or server enforcement points use SPA to prevent unauthorized connections. Secure connections to the servers provided by the gateway may be controlled by the infrastructure owner, as they have full control over the connections. Similar to the client-to-gateway model, the client may be located in the same location or distributed across the globe — in either case, it remains secured. Additionally, this model leaves the data plane completely secure, as there are no breaks in the mTLS tunnel. Traffic can be monitored by analyzing dropped packets from the SDP gateway/protected servers, thereby preserving the mTLS connections between the client and the servers. 22 Figure adapted from Cloud Security Alliance, “SDP Architecture Guide v2,” 7th, May 2019, https:// cloudsecurityalliance.org/artifacts/sdp-architecture-guide-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 34 Figure 13: Server-to-Server Model23 4.2.3 Server-to-Server Model The server-to-server model is ideal for IoT and virtual machine environments, as it offers full control over connections, regardless of where the server is located, whether in the cloud or on-premises. This model ensures that all connections between servers are encrypted, regardless of the underlying network or IP infrastructure. In addition, it ensures that all communications are explicitly permitted by an SDP allowlist policy. This model enables secure communications between servers across untrusted networks while hiding the servers from all unauthorized connections using the lightweight SPA protocol. The server-to-server model is similar to the client-to-server model, except that the IH is itself a server and can also act as an AH. Like the client-to-server model, the server-to-server model requires that the SDP gateway, or similar lightweight technology, be installed on each server. This renders all server-to-server traffic hidden to other elements of the security ecosystem. The traffic can also be monitored by analyzing all the dropped packets from the SDP gateway/protected servers. The secure connections to the servers going through the gateway are under the control of the owner of the application/services on the server by default, giving the owner full control of these connections. 23 Figure adapted from Cloud Security Alliance, “SDP Architecture Guide v2,” 7th, May 2019, https:// cloudsecurityalliance.org/artifacts/sdp-architecture-guide-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 35 Figure 14: Client-to-Server-to-Client Model24 4.2.4 Client-to-Server-to-Client Model The client-to-server-to-client model is well-suited for environments in which organizations are moving their peer-to-peer applications to the cloud, such as IP telephone, chat, or videoconferencing. Regardless of where the server environment is located (cloud or on-premises), organizations can have full control over the connections to the clients. This model results in a logical peer-to-peer relationship between two clients. This can be used for applications in which the traffic must pass through an intermediary server. In these cases, the SDP conceals the IP addresses of the connecting clients, encrypts the network connections between the components, and protects the server/AH from unauthorized network connections by using SPA. 24 Figure adapted from Cloud Security Alliance, “SDP Architecture Guide v2,” 7th, May 2019, https:// cloudsecurityalliance.org/artifacts/sdp-architecture-guide-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 36 Figure 15: Client-to-Gateway-to-Client Model25 4.2.5 Client-to-Gateway-to-Client Model This variation of the client-to-server-to-client model has the advantage of supporting peer-to-peer network protocols that require clients to connect directly to one another, while still enforcing SDP access policies. This results in a logical connection between the clients, each acting as either IH, AH, or both depending on the application protocol. It’s worth noting that while the application protocol determines how the clients connect to each other, the SDP gateway continues to perform its standard role as a firewall. 25 Figure adapted from Cloud Security Alliance, “SDP Architecture Guide v2,” 7th, May 2019, https:// cloudsecurityalliance.org/artifacts/sdp-architecture-guide-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 37 Figure 16: Gateway-to-Gateway Model26 4.2.6 Gateway-to-Gateway Model The gateway-to-gateway model is well-suited for certain IoT environments. In this scenario, one or more servers sits behind the AH and acts as a gateway between the clients and the servers. At the same time, one or more clients sits behind an IH that acts as a gateway. In this SDP model, the IH gateway is running SDP client software, but the client devices are not — they may be incapable of supporting SDP client installation, such as in the case of printers, scanners, sensors, or IoT devices. In this model, the gateway would operate as a firewall or router/proxy, depending on the implementation. 26 Figure adapted from Cloud Security Alliance, “SDP Architecture Guide v2,” 7th, May 2019, https:// cloudsecurityalliance.org/artifacts/sdp-architecture-guide-v2/ © Copyright 2022, Cloud Security Alliance. All rights reserved. 38 Conclusion In this introductory SDP course, we provided learners with an overview of SDP’s history and how it relates to ZT. We defined key SDP terminology and principles, explored its myriad of technology and business benefits, and walked through current security architecture issues that SDP addresses. Learners were introduced to leading industry cyber risk matrices/lists in order to illustrate how SDP addresses specific, common threats, followed by a deeper dive into its core tenets and underlying technologies. Lastly, learners were provided with a set of crucial architectural considerations to account for when implementing SDP, followed by the various SDP deployment options and related guidance for selecting the appropriate model. © Copyright 2022, Cloud Security Alliance. All rights reserved. 39 1 Context of ZTA In this unit, you will learn how the various factors of the evolving technology landscape led to the emergence of ZTA, as well as explore ZT’s roots and early approaches in both government and enterprise. Organizations today are in a cycle of adopting new technologies by leveraging cloud services, either through platforms or by utilizing elastic computing. This means that while transformations are increasingly popular and technology adoption is the strategy for these organizations, their networks and security measures are equally under pressure to keep up with the changing environment and associated new risks. Changes in the technology landscape, such as cloud computing, edge computing, and IoT, and the evolution of social behavior, such as increased requests for mobility, have led to organizations increasingly adopting distributed environments. Cloud computing, in all its combinations of delivery and deployments models is becoming the leading source of IT services1. The result is an increase in complexity for networks and service architectures, due to the need for integrating on-premises IT services with public cloud services, sensors, and actuators. In addition, the need to connect remote offices, remote workers, contractors, smart objects, and others has reinforced the requirement for more flexible, scalable, and secure network capabilities. Similarly, data often resides in virtual environments outside the organization’s premises and its physical control. However, the organization is still responsible and accountable for the data. From a data protection standpoint, traditional security architectures that focus on securing the physical network perimeter are increasingly ineffective in preventing cyber attacks. This is where ZTA comes into play. ZTA is a model that creates virtual enclaves and grants access to resources inside of that enclave. Every transaction is vetted using the ZT concept of “never trust, always verify”. In essence, ZT enables the designing of architectures from the inside out versus outside in. 1.1 History of ZT ZT was first coined by John Kindervag around 2010 while working as a principal analyst at Forrester2. However, this concept was being researched much earlier by the Jericho Forum at the Open Group, and previously by the U.S Defense Information Systems Agency (DISA) and Department of Defense (DOD), with the Black Core project3. Kindervag, known as the grandfather of ZT, emphasized that all network traffic is untrusted. His position was that all requests to access data or resources should be verified at each step, with this being termed ‘trust but always verify’. 1 Cloud Security Alliance, “Security Guidance for Critical Areas of Focus in Cloud Computing v4.0,” 26th, July 2017, https://cloudsecurityalliance.org/artifacts/security-guidance-v4/ 2 John Kindervag, “Build Security Into Your Network’s DNA: The Zero Trust Network Architecture,” 5th, November 2010, https://www.virtualstarmedia.com/downloads/Forrester_zero_trust_DNA.pdf 3 In the CSA’s literature on SDP, terms such as “black cloud” or “network darkening” have been discontinued in favor of more neutral terminology. © Copyright 2022, Cloud Security Alliance. All rights reserved. 2 The earliest concept of ZT was based on a data-centric network design and leveraged micro- segmentation which mandated more granular rules and policies to ultimately limit lateral movement of attackers. As the concept of ZT continued to evolve, it took a more identity-centric approach. This trend accelerated with the adoption of mobility and cloud. In 2013, Cloud Security Alliance’s (CSA) Software-Defined Perimeter (SDP) concept was initiated. SDP was designed to create an invisible perimeter through a security architecture that requires positive identification of network connections from a single packet inspection prior to accessing resources. In 2014, Google implemented ZT for its employees, which motivated it to publish the BeyondCorp model. The approach revolved around the idea that the perimeter had expanded, hence traditional perimeter security and a protected intranet were no longer sufficient to protect against cyber threats. Google’s BeyondCorp model shifted the access controls and policies from the perimeter to individual devices and users. It addressed the need to replace the traditional VPN while still allowing users to work securely from any untrusted network with a superior security posture. Since its inception, the concept of ZT has extended the original security model beyond traditional infrastructure, databases, and network devices to include IoT, cloud environments, big data projects, DevOps environments, containers, and microservices. In 2018, Chase Cunningham and his team at Forrester published the Zero Trust eXtended (ZTX) Ecosystem report, which extends the original ZT model beyond its network focus to encompass today’s ever-expanding attack surface. In August 2020, NIST announced the final publication of Special Publication (SP) 800-207, Zero Trust Architecture, which discusses the core logical components that make up a ZTA4. Clearly, ZT is gaining widespread adoption, even as it continues to evolve as a security model. Figure 1: ZT History and Milestones 4 NIST, “SP 800-207 Zero Trust Architecture,” August 2020, https://csrc.nist.gov/publications/detail/ sp/800-207/final © Copyright 2022, Cloud Security Alliance. All rights reserved. 3 2 Definitions, Concepts, & Components of ZT In this unit, you will learn the definitions for key ZT terminology, as well as the concept’s main tenets, design principles, pillars, and components and elements. 2.1 Definition5 of the ZT Concept ZT is a set of principles and practices designed for reducing cyber risk in today’s dynamic IT environments. As a security model, ZT requires strict authentication and verification for each person, device, or service trying to access an IT resource, regardless of whether it is inside or outside the physical network perimeter. Since ZT emphasizes the protection of IT assets rather than network segments, the assessment of a given resource’s security posture is not based on its location, but rather on what authentication and authorization controls are in place, and by leveraging risk-based analytics for access verification. A key aspect of ZT networks is that authentication and explicit authorization must occur prior to network access being granted (e.g., the communication between a requesting entity and the target resource). Encrypting communications between two endpoints will no longer suffice; security practitioners must also ensure that access controls are implemented and each individual flow is confirmed as an authorized connection. ZT lays out a blueprint for combating both internal and external threat agents trying to access protected assets. Research has shown that 90% of attacks start with a breach via a phishing email6. This exploit leads to the creation or compromise of an administrative account, followed by the lateral movement of malware inside the network, finally leading to the exfiltration of enterprise data. In the context of this training and study guide, CSA defines the ZT concept as a cybersecurity approach that requires the following: Making no assumptions about an entity’s trustworthiness when it requests access to a resource Starting with no pre-established entitlements, then relying on a construct that adds entitlements, as needed Verifying all users, devices, workloads, network and data access, regardless of where, who, or to what resource, with the assumption that breaches are impending or have already occurred Recent trends in enterprise security point to an increasing number of remote users and assets that are based in the cloud versus inside the traditional corporate network7. To meet the security 5 Note: CSA’s working definition of ZT and ZTA is based on existing market definitions of ZT (e.g., as defined by Forrester, NIST, etc.). Throughout this