Zero Trust Planning Study Guide PDF

The official location for SDP and Zero Trust Working Group is https://cloudsecurityalliance.org/research/working-groups/zero-trust/ Disclaimer Cloud Security Alliance designed and created this Zero Trust Training course study guide (the “Work”) primarily as an educational resource for security and governance professionals. Cloud Security Alliance makes no claim that use of any of the Work will assure a successful outcome. The Work should not be considered inclusive of all proper information, procedures and tests or exclusive of other information, procedures and tests that are reasonably directed to obtaining the same results. In determining the propriety of any specific information, procedure or test, professionals should apply their own professional judgment to the specific circumstances presented by the particular systems or information technology environment. © 2023 Cloud Security Alliance – All Rights Reserved. You may download, store, display on your computer, view, print, and link to the Cloud Security Alliance at https://cloudsecurityalliance.org subject to the following: (a) the draft may be used solely for your personal, informational, non- commercial use; (b) the draft may not be modified or altered in any way; (c) the draft may not be redistributed; and (d) the trademark, copyright or other notices may not be removed. You may quote portions of the draft as permitted by the Fair Use provisions of the United States Copyright Act, provided that you attribute the portions to the Cloud Security Alliance. © Copyright 2023, Cloud Security Alliance. All rights reserved. ii About Cloud Security Alliance The Cloud Security AllianceSM (CSA) (www.cloudsecurityalliance.org) is the world’s leading organization dedicated to defining and raising awareness of best practices to help ensure a secure cloud computing environment. Cloud Security Alliance harnesses the subject matter expertise of industry practitioners, associations, governments, and its corporate and individual members to offer cloud security-specific research, education, certification, events and products. Cloud Security Alliance activities, knowledge and extensive network benefit the entire community impacted by cloud—from providers and customers, to governments, entrepreneurs and the assurance industry— and provide a forum through which diverse parties can work together to create and maintain a trusted cloud ecosystem. CSA Address 709 Dupont St. Bellingham, WA 98225, USA Phone: +1.360.746.2689 Fax: +1.206.832.3513 Contact us: [email protected] Website: https://cloudsecurityalliance.org/ Zero Trust Training Page: https://knowledge.cloudsecurityalliance.org/page/zero-trust-training Zero Trust Advancement Center: https://cloudsecurityalliance.org/zt/ Provide Feedback: [email protected] CSA Circle Online Community: https://circle.cloudsecurityalliance.org/ Twitter: https://twitter.com/cloudsa LinkedIn: www.linkedin.com/company/cloud/security/alliance Facebook: www.facebook.com/csacloudfiles CSA CloudBytes Channel: http://www.csacloudbytes.com/ CSA Research Channel: https://www.brighttalk.com/channel/16947/ CSA Youtube Channel: https://csaurl.org/youtube CSA Blog: https://cloudsecurityalliance.org/blog/ © Copyright 2023, Cloud Security Alliance. All rights reserved. iii Acknowledgments Dedicated to Juanita Koilpillai, a pioneer in software-defined perimeters whose contributions to the Zero Trust Training and CSA are immeasurable. The Zero Trust Training was developed with the support of the Cloud Security Alliance Zero Trust Training (ZTT) Expert Group, whose members include volunteers from a wide variety of industries across the globe. Made up of subject matter experts with hands-on experience planning and implementing ZTT, both as cloud service consumers and providers, the ZTT Expert Group includes board members, the technical C-suite, as well as privacy, legal, internal audit, procurement, IT, security and development teams. From cumulative stakeholder input, the ZTT Expert Group established the value proposition, scope, learning objectives, and curriculum of the Zero Trust Training. To learn more about the Zero Trust Training and ways to get involved please visit: https:// cloudsecurityalliance.org/zt/ We would also like to thank our beta testers, who provided valuable feedback on the Zero Trust Training. Lead Developers: Alex Sharpe, CRISC, CDPSE, CMMC RP, Sharpe Consulting, USA Clement Betacorne, CISSP, One Step Beyond Group, France Heinrich Smit, CISSP, CISA, CRISC, Semperis, USA Mark Schlicting, CISSP, CCSP, BPM, USA Michael Herndon, CCSP, CISSP, CRISC, CGEIT, CIPP/US, CIPT, AWS Certified Solution Architect, Bayer Business Services, USA Michael Roza, CPA, CISA, CIA, MBA, Exec MBA, CSA Research Fellow, Consultant, Belgium Prasad T, OCSP, Head - Information Security, Verse Innovation, India Richard Lee, CISSP, CCSP, WCP, MITRE, USA Shruti Kulkarni, CISA, CRISC, CISSP, CCSK, ITIL v3 Expert, ISO27001 LA, 6point6, United Kingdom Sky Hackett, CISSP, CISA, Amazon Web Services, USA © Copyright 2023, Cloud Security Alliance. All rights reserved. iv Contributing Editors: Aunudrei Oliver, CISSP,CCSP,CWNE,CWDP,CCISO,CDPSE,CGEIT, CISCO, USA Emilio Mazzon Ledy Eng , CISSP, CCSP, CCSK, CASP+, CySA+, Security+, Contractor - Undisclosed, Indonesia Matt Lee, CISSP, CCSP, CCSK, CFR, Pax8, USA Ron Kearns, SCF, CISSP, CCSP, GCSA, Charter Communications, USA Expert Reviewer: Agnidipta Sarkar, Group CISO, Biocon, India James Lam, CISA, CISM, CRISC, CDPSE, TOGAF, M.S., Accenture, USA Jaye Tillson, CCSK, MBA, Axis Security, UK Robert Morris, CISSP, GDSA, GCIH, MITRE, USA Roland Kissoon, MBA, MSc, CCSK, CISSP, CRISC, CISA, PMP, Microsoft, USA Ron Martin (Dr.) , PhD, CPP, Capitol Technology University, USA Vani Murthy, CISSP, CDPSE, CCSK, CRISC, PMP, ITIL, MBA, MS, Akamai Technologies, USA Farid Gurbnov, AWS SAP, AWS Sec, Azure SAE, CCNA, Snowflake, PRICE2, TOGAF 9, ITIL 4, Tech Arch, Netherlands CSA Staff: Anna Schorr-Campbell, MBA, CCSK, CSA, USA Chandler Curran, CSA, USA Adriano Sverko, CSA, USA Daniele Cattedue, CISM, CSA, Italy Noelle Scheck, CSA, USA Hannah Rock , CSA, USA Leon Yen, CSA, USA Stephen Smith, CSA, USA © Copyright 2023, Cloud Security Alliance. All rights reserved. v Table of Contents List of Figures viii Course Intro 1 Course Structure 1 Course Learning Objectives 1 1 Starting the Zero Trust Journey 2 1.1 Module Assumptions 2 1.2 Initial Considerations 3 1.2.1 CISA High-Level Zero Trust Maturity Model 5 2 Planning Considerations 6 2.1 Stakeholders 7 2.1.1 Stakeholder Responsibilities 7 2.1.2 Stakeholder Communications 8 2.2 Technology Strategy 8 2.3 Business Impact Assessment 9 2.4 Risk Register 9 2.5 Supply Chain Risk Management 9 2.6 Organizational Security Policies 10 2.7 Architecture 11 2.8 Compliance 11 2.9 Workforce Training 12 3 Scope, Priority, & Business Case 12 3.1 Prerequisite to Understanding the Protect Surface 13 3.1.1 Data & Asset Discovery & Inventory 13 3.1.2 Data & Asset Classification 13 3.1.3 Entities/User Discovery 14 3.2 Scope 14 3.3 Priority 14 3.4 Development of a Business Case for ZT Planning 15 3.5 Use Case Examples 15 3.5.1 Role Based Access Control for Internal Staff 15 3.5.2 Remote Access 16 3.5.3 Services Accessed Using Mobile Devices 16 3.5.4. Third-Party Service Providers with Remote Access 16 3.5.5 Staff Access to Assets in Hybrid Environments 16 3.5.6 SaaS & PaaS 17 © Copyright 2023, Cloud Security Alliance. All rights reserved. vi 3.5.7 Application Release & DevOps 17 3.5.8 Industrial Control Systems, Operational Technology, & Internet of Things 17 4 Gap Analysis 18 4.1 Determine Current State 18 4.2 Determine the Target State 19 4.3 Create a Roadmap to Close the Gaps 20 4.4 Requirements 20 5 Define the Protect Surface & Attack Surface 21 5.1 Identify the ZTA Protect Surface 21 5.2 Identify the Attack Surface 21 5.3 Illustration of Protect Surface & Attack Surface 26 5.4 Protect & Attack Surface Considerations 28 6 Document Transaction Flows 29 6.1 Example Transaction Flow: eCommerce 30 6.2 Transaction Discovery: Functional Analysis & Tooling 32 6.2.1 Collecting Data 33 6.2.2 Discovery of Known & Unknown Transactions 33 6.2.2.1 Transaction Inventory 34 6.2.2.2 Transaction Records 34 6.2.3 Monitoring & Analytics 34 6.2.4 Identifying Anomalies & Edge Cases 34 7 Define Policies for Zero Trust 35 7.1 The Policy 35 7.2 The Policy Workflow 36 7.3 Policy Considerations & Planning 37 7.4 Continual Improvement 38 7.5 Automation & Orchestration 39 8 Developing a Target Architecture 39 8.1 Identity Considerations 40 8.3 Network & Environment Considerations 42 8.4 Workload & Application Considerations 43 8.5 Data Considerations 43 8.6 Visibility & Analytics Capability Considerations 43 8.7 Automation & Orchestration Capability Considerations 44 8.8 Governance Capability Considerations 44 8.9 Examples of Zero Trust Architecture 44 Conclusion 45 Glossary 45 © Copyright 2023, Cloud Security Alliance. All rights reserved. vii List of Figures Figure 1 The ZT Journey Roadmap 2 Figure 2 Five-Step Process for ZT Implementation 4 Figure 3 CISA High-Level ZT Maturity Model 5 Figure 4 CISA Zero Trust Maturity Model: Traditional 19 Figure 5 CISA Zero Trust Maturity Model: Advanced 19 Figure 6 General ZTA Reference Architecture 22 Figure 7 Attack Surface & Protect Surface: Credit Card Example 26 Figure 8 Laptop & Cloud Services Expand Attack Surface 27 Figure 9 Two Protect Surfaces Created with Micro-segmentation 28 Figure 10 Different Views of the Organization 28 Figure 11 Example Transaction Flow: eCommerce Payment Process 30 Figure 12 Transaction Visibility & Control 33 Figure 13 PDP/PEP & Zone Interactions 35 Figure 14 Zero Trust Entities & Policy Workflow 36 Figure 15 Zero Trust Pillars & Foundations 40 Figure 16 Validating SaaS Application Access 41 Figure 17 Access Decisions with Endpoint Risk Analysis 42 © Copyright 2023, Cloud Security Alliance. All rights reserved. viii Course Intro Welcome to Zero Trust Planning by the Cloud Security Alliance (CSA). This training module is part of a larger series titled Zero Trust Training (ZTT). In this course, learners will get an in-depth look at the crucial facets of ZT planning, from initial considerations such as stakeholder identification and supply chain risk, to organizational security policies, to compliance. Use cases for prioritization, scoping, and gap analysis are also covered. Course Structure This course consists of 8 units, each geared towards helping learners gain competency in the following topics: 1. Starting the Zero Trust journey 2. Planning considerations 3. Scope and priority 4. Gap analysis 5. Defining the protect surface and attack surface 6. Documenting transaction flows 7. Defining policies for Zero Trust 8. Developing a target architecture Course Learning Objectives After completing this course, learners will be able to: Demonstrate understanding of the ZT maturity model, and how it supports an organization’s ZT planning process Identify the crucial ZT planning steps and key considerations Understand ZT pre-requisites and common ZT use cases Possess a working knowledge of how industry-recognized methods (e.g., gap analysis, risk register, RACI diagrams) fit into a ZT planning process Demonstrate an understanding of the concepts of protect and attack surface Demonstrate understanding of how to map organizational data flows within the scope of the ZT approach Demonstrate an understanding of how to plan ZT policies Demonstrate an understanding of variables to consider when planning for a ZT target architecture © Copyright 2023, Cloud Security Alliance. All rights reserved. 1 1 Starting the Zero Trust Journey Congratulations, your board of directors and senior management are committed to starting the organization’s ZT effort. Now your journey begins! The following roadmap identifies the primary phases of your organization’s journey to ZT and maps them to the respective units and sections covered in this module. Figure 1: The ZT Journey Roadmap During the course of this module, we explore the various considerations and steps to plan your ZT journey. During ZT planning, the primary focus should be aligning activities and resources to achieve business outcomes, with acceptable risk levels defined by the board of directors and senior leadership. In this unit we will cover: Module assumptions Initial considerations 1.1 Module Assumptions It is most likely that ZT will be implemented in an existing environment with existing controls (in either on-premises, hybrid, or cloud-only scenarios). However, this module applies to completely new implementations as well. While these considerations are similar to implementation in existing environments, they have little or no dependencies on existing business systems and may be implemented more deeply and quickly. Additionally, this module focuses on items specific to ZT and presumes that learners possess foundational knowledge in areas like project planning, enterprise risk © Copyright 2023, Cloud Security Alliance. All rights reserved. 2 management (ERM), information security (InfoSec), systems engineering, and enterprise architecture design. The module also assumes an understanding of core ZT principles, including the following: Never trust; always verify: Claimed identities and authorized entitlements should be verified before access is granted to assets. Inside-out security: Starting with the assets, the mission-critical elements that are most valuable or vulnerable should be protected. Risk-based security approach: ZT planning efforts should stem from risk-driven business decisions; that is, assuming budget scarcity, the organization should allocate resources based on risk and opportunity. For example, the decision to protect a specific asset should depend on how it contributes to the company’s financial value and its criticality to the organization’s mission. To foster learning and clarity, this course treats the ZT initiative as an atomic unit; in reality, a single organization may pursue a portfolio of initiatives with different motivations and success criteria. In general, larger organizations will likely pursue a portfolio of ZT initiatives based on geography, line of business (LOB), function, regulatory concerns, and more, while smaller organizations may only have a single ZT effort. For example, a multinational, publicly-traded enterprise may pursue three ZT initiatives—one in Europe to address General Data Protection Regulation (GDPR) compliance requirements, another for the firm’s manufacturing business in South America, and a third for its U.S.-based operations. In contrast, a privately held small and medium-sized business may pursue a single ZT project to fulfill requirements when bidding for government projects with ZT-related requirements. 1.2 Initial Considerations A plan for implementing ZT philosophy, approach, and design principles should consider the following five steps, as outlined in the 2022 U.S. National Security Telecommunications Advisory Committee (NSTAC) Report to the President1: 1. Define the protect surface: Identify the data, applications, assets, and services (DAAS) elements to protect. 2. Map the transaction flows: Understand how the networks work by mapping the transaction flows to and from the protect surface, including how various DAAS components interact with other resources on the network. These transaction flows provide insight to help determine where to place proper controls. 3. Build a Zero Trust Architecture (ZTA): Design your ZTA, tailored to the protect surface, determined in steps 1 and 2. The way traffic moves across the network specific to the data in the protect surface determines design. The architectural elements cannot be predetermined, though a good rule of thumb is to place the controls as close as possible to the protect surface. 1 NSTAC. (2022). NSTAC Report to the President on Zero Trust and Trusted Identity Management. © Copyright 2023, Cloud Security Alliance. All rights reserved. 3 4. Create a ZT policy: Instantiate ZT as an application layer policy statement. Use the Kipling Method2 of ZT policy writing to determine who or what can access your protect surface. Consider person and non-person (services, applications, and bots) entities. 5. Monitor and maintain the network: Inspect and log all traffic, all the way through the application layer. The telemetry gathered and processed from this process helps prevent significant cybersecurity events and provides valuable security improvement insights over the long term. As a result, each subsequent protect surface can become more robust and better protected over time. Figure 2: Five-Step Process for ZT Implementation3 Proper risk management should form the basis of any competent cybersecurity approach, as establishing a framework for identifying and mitigating risks is crucial for minimizing project failure and, in the case of already existing system deployments, disrupting existing systems and business processes. ZT migration tactics depend on the organization’s risk profile and risk appetite. For some, ZT design principles will be applied to a limited set of assets; others will apply ZT to all assets across the organization. In either case, the migration to ZT will follow a risk-based, staged approach with numerous iterations culminating in the final transformation into a ZT-driven organization. Frameworks and models such as the Cybersecurity and Infrastructure Security Agency (CISA) Zero Trust Maturity Model4 can provide organizations at the start of their ZT journey with a reference roadmap for charting their transition towards a ZTA. 2 NSTAC. (2022). NSAC Report to the President on Zero Trust and Trusted Identity Management. Table 3: Key Zero Trust Foundational Concepts and Definitions. 3 Figure adapted from: NSTAC. (2022). NSTAC Report to the President on Zero Trust and Trusted Identity Management. 4 CISA. (2023). Zero Trust Maturity Model (Version 2.0). © Copyright 2023, Cloud Security Alliance. All rights reserved. 4 1.2.1 CISA High-Level Zero Trust Maturity Model Figure 3: CISA High-Level ZT Maturity Model5 CISA’s Zero Trust Maturity Model consists of five pillars, three cross-cutting capabilities, and four cross-functional maturity stages that together form the crucial foundations for ZT. In some diagrams (i.e., from the US Department of Defense6), the cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, and Governance), are depicted as foundational pillars. This representation emphasizes the significance of incorporating these capabilities into the planning process as they assist in defining objectives for the five pillars. The five pillars are: Identity Devices Networks Applications & Workloads Data 5 Figure adapted from: CISA. (2023). Zero Trust Maturity Model (Version 2.0). 6 U.S. Department of Defense. (2022). DoD Zero Trust Strategy. © Copyright 2023, Cloud Security Alliance. All rights reserved. 5 In this course, as well as in our other courses, the three capabilities (represented by arrows) are discussed individually due to their frequent need for revision and modification. Additionally, the arrow that lists these capabilities is intentionally repeated several times to highlight the importance of implementing tasks or projects to adapt them as your organization progresses from a traditional model to more advanced security stages. CISA’s Zero Trust Maturity Model also consists of several stages. Traditional, the first stage, is where most companies will likely find themselves before embarking on their ZT implementation journey. Attempting to reach the highest level of maturity in a single implementation is impractical and virtually impossible. By incorporating the maturity model into planning discussions, teams will be able to focus on setting clear expectations regarding the desired outcomes for each iterative ZT implementation they commit their resources to. The four maturity stages, along with a brief example of their criteria, are as follows: Traditional - Utilizes multi-factor authentication (MFA), employs manual deployment of threat protection, and maintains an on-premises network Initial - Implements MFA with passwords, tracks all physical assets, initiates isolation of critical workloads, and employs formal deployment mechanisms through the CI/CD pipeline Advanced - Implements phishing-resistant MFA, tracks most physical and virtual assets, makes most mission-critical apps available over public networks, automates data inventory with tracking, and encrypts data at rest Optimal - Engages in continuous validation and risk analysis, grants resource access based on real-time device risk analysis, establishes distributed micro perimeters with just-in-time (JIT) and just-enough access controls, conducts continuous data inventorying, and encrypts data in use The CISA Zero Trust Maturity Model outlines specific examples of Traditional, Initial, Advanced, and Optimal ZTA elements within each pillar. For example, an organization beginning its ZT journey (e.g., it has not yet implemented ZT) may find itself at the traditional tier. According to ZT principles, the organization still would not have enough protection or security even after moving to the initial tier. The two lower maturity stages fail the organization because they lack essential features for a secure and effective ZTA. In this example, the organization would want to move to a future state of advanced and optimal tiers to manage access control effectively. Which would require implementing authentication and identity management, authorization, encryption, monitoring and logging, data protection, and segregation of duties. In later sections (Gap Analysis, Developing a Target Architecture), the CISA Zero Trust Maturity Model will be covered more in-depth as a tool for moving across tiers. 2 Planning Considerations Planners should consider several key factors and variables prior to undertaking the organization’s journey to ZT. These include, but are not limited to: © Copyright 2023, Cloud Security Alliance. All rights reserved. 6 Stakeholders to engage Technology strategy Business impact analysis (BIA) results The risk register Supply chain risk management Organizational security policies Architecture options Compliance requirements Workforce training These key considerations have far-reaching implications on the organization’s ZT planning efforts. For example, results from stakeholder identification, BIA, and risk register development activities should dictate how subsequent policies are created. 2.1 Stakeholders Though seemingly straightforward, stakeholder identification is a critical step that, in practice, requires a significant, concerted time and energy investment. More than any other, this stage can make or break the organization’s ZT effort. Stakeholders include, but are not limited to: Business/service owners Application owners Infrastructure owners Service architecture owners CISO/security teams Legal officers Compliance officers Procurement officers Once stakeholders are identified, planning efforts should proceed to mapping out their respective responsibilities, and a communications plan should be developed. 2.1.1 Stakeholder Responsibilities Stakeholder identification efforts should result in a Responsible, Accountable, Consulted, and Informed (RACI) chart and communications plan. Also referred to as a responsibility assignment matrix, a RACI chart maps out task roles and responsibilities to streamline project management efforts. The RACI chart should reflect the cloud’s shared responsibility model, as well as the ability to delegate responsibility, but not accountability—the risk register also shares both attributes. IT will likely run the organization’s ZT initiative daily, with sponsorship by business units, risk management, compliance, or the CISO. Both sponsors and stakeholders should be relevant to the ZT initiative’s expected business outcomes. As a starting point, governing documents approved by senior management and the board of directors should designate the executive sponsor and provide insights into reporting expectations. © Copyright 2023, Cloud Security Alliance. All rights reserved. 7 The most critical ZT-specific role is the asset owner, who will more than likely reside in the business units. As part of their data governance role, the asset owners determine valid users, valid roles, privileges, data usage, and more. Because ZT is an inside-out strategy based on asset value, identifying both assets and asset owners is crucial. However, asset owners should not be confused with asset custodians (e.g., database administrators), who are responsible for implementing directives set by asset owners. Asset owners typically exist in the business while asset custodians are almost always part of IT. Organizations pursuing ZT should not lose focus on other internal users and groups in human resources (HR), legal, risk management, audit teams, end users, and senior management. An effective, well-informed ZT initiative must consist of stakeholders spread across the organization and at all levels, including functional areas. Functional areas should be consulted or informed, at the bare minimum. For example, HR should serve as the primary source of truth for the organization’s identity, while procurement should serve as the source of truth for contractors and vendors. Internal audit, compliance, and the CISO office will likely play crucial roles in the go-live approval. Bringing in stakeholders across the organization early and keeping them engaged helps the ZT initiative remain well-balanced and focused. To this end, stakeholders should be well-informed of the organization’s collective mission and ongoing priorities in order to avoid operational conflicts, aid in prioritization, and ensure the most efficient assignment of resources. 2.1.2 Stakeholder Communications A communications plan is an essential enterprise tool and is especially critical to a ZT initiative. Because of ZT’s prescribed, fundamental philosophical changes and enterprise nature, organizations should develop and adhere to a well-designed communications plan; chiefly, the document should serve as a roadmap for team communications with stakeholders, staff, customers, business partners, and regulators. At a minimum, the communications plan should: Define a communication strategy, including tools and any required guidance Establish cadence (e.g., forums, format, etc.) Incorporate mechanisms for setting proper expectations with interested parties Include a means to communicate and document key decisions 2.2 Technology Strategy Most organizations have a technology strategy consisting of the principles, objectives, methods, plans, processes, and budget for using technology to achieve business objectives. At the beginning of their ZT journey, organizations need to ensure that ZT planning activities are happening in the context of the broader technology strategy. In other words, the ZT strategy and planning need to take into account the existing technology strategy and then update that technology strategy. © Copyright 2023, Cloud Security Alliance. All rights reserved. 8 During the planning process, organizations should be asking themselves the following essential questions: How does the ZT strategy fit into the organization’s technology strategy? How does the ZT strategy need to be updated to incorporate the technology strategy? How does the ZT strategy impact existing plans, processes, and procedures? How does the ZT strategy affect existing budgets and investments? How does the ZT strategy affect existing internal standards and best practices? 2.3 Business Impact Assessment Larger organizations operating in highly regulated environments and firms with mature ERM programs are likely to have already carried out a recent BIA. A BIA provides organizations with a list of assets followed by their relative values and owners, valuable information like recovery point objective (RPO) and recovery time objective (RTO), interdependencies and priorities, and an assessment of resources required to restore and maintain each asset. Based on this information, organizations can establish more comprehensive and accurate service level agreements (SLAs), business continuity/ disaster recovery (BC/DR) plans, third-party risk management (TPRM) programs, as well as streamline prioritization and stakeholder identification efforts for ZT planning. 2.4 Risk Register In a similar vein, organizations with a mature ERM or InfoSec program are likely to have developed a risk register containing an inventory of potential risk events, recorded and tracked by likelihood, impact, and description. The risk register should also contain controls for reducing risk levels within the organization-defined risk appetite thresholds, along with the risk owner and the control owner. With a well-developed risk register, organizations are better equipped to understand what cyber risks their ZT implementation will mitigate. However, the risk register will require continuous updating as the organization adopts new technologies and its infrastructure evolves. For example, the ongoing shift to expanded connectivity and the cloud mandates shared responsibility, and while responsibilities can be outsourced or delegated, accountability cannot. In this case, the risk register must be updated to reflect the cloud’s shared responsibility model. 2.5 Supply Chain Risk Management Modern organizations exist as ecosystem players on a myriad of fronts, from retailer order fulfillment logistics to outsourced human resources. When it comes to technology acquisitions and implementation, the same applies—whether software, hardware, or cloud-based services. Solutions on the market are, to a greater or lesser degree, an assemblage of components developed by third parties. As a result, an organization’s visibility into its supply chain is limited by nature, since many components are outside the organization’s control. Attestations regarding the validity, security, and quality of third-party components are typically the primary driver behind the organization’s technology acquisition decisions. © Copyright 2023, Cloud Security Alliance. All rights reserved. 9 Crucially, ZT planning considerations should address supply chain risk, since lack of visibility into potential third-party exposures and security glitches (e.g., coding errors, intentional or unintentional hardware or software back doors, unpatched libraries) could result in a data breach or compromise. In the absence of a ZT approach, supply chain participation requires organizations to inherently trust that the initial processes, degree of scrutiny, and approvals to use third-party components in downstream offerings (e.g., hardware, software, or systems) were sufficient; as a result, the required assumption is that the third-party risk of that technology acquisition was and remains acceptable. Several tools and frameworks can help organizations better understand and mitigate supply chain risk in their ZT implementations. The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-207 presents ZT tenets that apply to a supply chain and its supplier organizations across all ZT pillars, namely Identity, Devices, Networks, Applications and Workloads, and Data. Since 2018, the National Telecommunications and Information Administration (NTIA) has pursued the concept of a software bill of materials (SBOM) as a tool for advancing supply chain risk management, with CISA having announced its intent to support this work. This effort aims to create a mechanism for exposing software components, enabling organizations to make better risk decisions when deciding what software products to incorporate into their products or offerings. Additionally, the following non-exhaustive list of tools and resources can help organizations in determining supply chain risk: CSA STAR Program7 (STAR Level 1 and STAR Level 2) ISO 27001 assessments SOC 1 and 2 assessments Systems audits Bridge letters & attestations Supplier organization and service offering reputation research With these frameworks, tools, and resources at their disposal, organizations can apply ZT principles in evaluating potential supply chain risk exposures more comprehensively and effectively. 2.6 Organizational Security Policies ZT planners should keep in mind that various policies will change across all domains (e.g., HR, identity and access management [IAM], technical, and privacy). Also, pre-existing policies affect how ZT will be implemented. From a ZT perspective, organizational policies affecting identity, devices, networks, applications and workloads, and data should be considered for updates, at the very least. These policies are designed to provide direction across the enterprise. The policies updated (or created) for ZT will be provided to the team(s) for implementation. The most relevant policies will fit into roughly three categories: 1. Policies that dictate or constrain the ZT initiative 2. Policies that require updating due to ZT 3. Policies that need to be created to support ZT 7 https://cloudsecurityalliance.org/star/ © Copyright 2023, Cloud Security Alliance. All rights reserved. 10 While the list of relevant policies and how they fit into each category vary widely between organizations and potentially groups within organizations, the following are common policy types for a ZT initiative: General IT and security ZT Data governance Cloud Key management policy Incident response User and IAM Monitoring Disaster recovery (DR) Business continuity (BC) 2.7 Architecture During the ZT planning process, especially in the early stages, planners should identify the relevant architecture capabilities and components that could impact ZT or require updating due to ZT. These capabilities may include architectural frameworks such as The Open Group Architecture Framework (TOGAF)8, Sherwood Applied Business Security Architecture (SABSA)9, CSA’s Enterprise Architecture Reference Guide10, and other less formal frameworks and standard organizational configurations. It is also necessary to identify key components such as architecture requirements repositories, architecture landscapes, solution landscapes, and standards information bases. Architecture will be discussed in greater depth in later sections. 2.8 Compliance At this time the United States is at the global forefront in the pursuit of ZT. For instance, U.S. government agencies have produced artifacts that provide critical ZT guidance like the NSTAC Report to the President on Zero Trust and Trusted Identity Management, and the NIST Cyber Security White Paper (CSWP) 2011, to name a few. Other jurisdictions like Europe and Asia are also preparing ZT guidance or regulations. However, even without fully realized ZT-based regulations and laws, the ZT approach can be invaluable in achieving compliance with existing cybersecurity and data privacy laws and regulations. A ZT approach will be helpful in two ways: First, it will increase control over regulated data by enforcing controls that foster accountability and by segregating data within dedicated micro-segments. Second, it will drive better overall cybersecurity, which in many cases exceeds most existing legal and regulatory requirements. 8 The Open Group Architectural Framework. (2022). The TOGAF Standard, 10th Edition. 9 Sherwood Applied Business Security Architecture. (2009). SABSA White Paper (W100). 10 Cloud Security Alliance. (2021). Enterprise Architecture Reference Guide. 11 NIST. (2022). Planning for a Zero Trust Architecture: A Planning Guide for Federal Administrators (CSWP 20). © Copyright 2023, Cloud Security Alliance. All rights reserved. 11 Implementing ZT across an organization or system impacts all in-scope architectures. This implies that potentially every system, control, and process will change. These potential impacts across the organization should be kept in mind during the planning phase. Potential impacts, considerations, and updating needs may surface in unforeseen areas (e.g., infrastructure support, incident management, BC/DR, and end-user support). 2.9 Workforce Training As one the most critical aspects for the success of a ZT journey, training is undoubtedly a key component of every cyber security program and represents a foundational component of the ZT approach, despite being often left to the last minute. Because ZT is essentially a paradigm shift, it will benefit from a shift in existing training programs along with the typical user training that accompanies any technology rollout. Your organization most likely has a training and awareness program and a security awareness program. ZT principles should be integrated into the security awareness program in all phases — onboarding, role changes, yearly reviews, drip feed, and termination. Special attention needs to be paid to the training of the: Staff who determines access controls Staff who configures the access control rules Support Team, including the Help Desk, who need to be ready to handle the paradigm shift is paramount to a smooth transition Staff who audit what has been done, including IT audit and security audit Upper management who need to fully embrace the cultural shift that ZT might impose Finally, it is important that the board of directors and CEO have the necessary level of awareness to be able to fully understand the progress and challenges of the ZT project. 3 Scope, Priority, & Business Case As mentioned at the start of this module, the ZT approach should be regarded as a journey of several stages, eventually taking the organization to a state where the business operates on a ZT model. Each stage of the journey should be seen as an individual project. The organization may start its ZT journey with a project focused on a critical protect surface, then expand onto the rest of the organization’s protect surfaces. In the event that the organization has identified several critical protect surfaces, the key questions are prioritization-related: Where does the ZT journey start? How does that define the scope of the initial ZT project? The answers to these questions are discussed in the next section, while protect surfaces are covered more in-depth in a later section. ZT concerns securing the protect surface to reduce the risk of data and process-compromise. To do this, the protect surface’s data, assets, processes, and the identities that access it must be comprehensively understood and mapped out. The organization may choose to include one or several protect surfaces in a project. © Copyright 2023, Cloud Security Alliance. All rights reserved. 12 Regardless of the number of protect surfaces in a project, organizations at this stage should start with the prerequisites for understanding the protect surface, followed by a definition of the ZT project’s scope and priorities, and lastly, a development of a business case. The last section in this unit provides several examples for assessing scope and priorities per use case. 3.1 Prerequisite to Understanding the Protect Surface The first step in defining the priorities within a ZT journey is understanding what the organization wants to protect using a ZT approach. In other words, the starting point for prioritizing ZT efforts is identifying the data and assets that the organization seeks to secure, the location of the data, the asset where data is hosted, and the services, processes, and classifications. To this effect, several prerequisite actions need to take place in order to have a clear understanding of the organization: Data and asset discovery and inventory Data and asset classification Entities/user discovery and inventory 3.1.1 Data & Asset Discovery & Inventory To effectively protect its data, the organization needs to know where that data resides. This can be achieved with data discovery activities. At a minimum, more mature organizations will have a current asset inventory that contains a list of itemized data, devices, applications, services, and more, followed by an assessment of each asset’s value. Ideally, the asset inventory will exist in the form of an up-to-date, automatically updated configuration management database (CMDB) that contains all the relevant information about the assets (e.g., hardware, software, devices, etc.) and the inter-component relationships. As ZT is driven by the asset’s value, the CMDB should be viewable based on these models and parameters. Alternatively, in the absence of an asset inventory, the organization may decide to run a data discovery activity using automated tools, followed by the population of a CMDB with the metadata obtained during the data discovery activity. 3.1.2 Data & Asset Classification With a new or existing asset inventory on hand, the organization must classify data and assets based on the sensitivity of data handled by the business transaction. Data and asset classification activities are meant to be a prerequisite for any ZT project. This helps in the identification of the protect surface and enables organizations to plan for the proper security controls in their ZT implementations. It also plays a crucial role in identifying relevant regional laws and regulations that may apply to the organization. © Copyright 2023, Cloud Security Alliance. All rights reserved. 13 3.1.3 Entities/User Discovery The discovery of entities, both person and non-person users, is another essential prerequisite before the scope of a ZT project can be defined. In order to be able to access the organization’s IT assets and data and carry out business transactions, those entities need to have an identity assigned and eventually a set of different personas. These entities may be person or non-person users (e.g., machines, service accounts, APIs). Organizations should understand whether the entities run transactions in the background and whether they are authorized to run the transactions after being authenticated. The discovered entities should be mapped to all relevant protect surfaces, (creating an inventory of entities/users) and their identities used to define the ZT policies discussed in later sections. 3.2 Scope Once the prerequisites are met, the organization needs to define the scope of the ZT project. Scope would typically include: Success criteria identified for the ZT projects Business units that are identified for the ZT journey Protect surfaces that are part of the business units, including identification of: The data and the assets that are part of the protect surface The identities that access the protect surface The entities mapped to the identities/personas 3.3 Priority Once the scope is identified, the organization needs to determine how and in what priority to implement ZT. Some approaches to this include the following: Prioritization based on complexity: Building from simple to complex, the organization may choose to select a smaller, simpler protect surface as a pilot project and progress to more complex protect surfaces. This approach allows a better understanding of the ZT project life cycle, document learnings, and apply them to the next set of protect surfaces. Starting small and simple makes it easier to apply the relevant planning considerations. Prioritization based on risks: Selecting a protect surface high on the risk register may help in scenarios where the organization has experienced security compromises or incidents involving protect surfaces. This approach may help reduce any cyber risks brought about by access control. After completing the high-risk protect surface projects, the organization may then move on to lower-risk projects. Prioritization based on use case: This approach is suitable for organizations with a definite use case in mind. Use case examples are provided later in this unit. © Copyright 2023, Cloud Security Alliance. All rights reserved. 14 3.4 Development of a Business Case for ZT Planning After the identification of data, assets and identities, classification of data, and the critical processes are identified, the organization can move forward and define a business case that would justify why a certain asset should move under the protection of a ZT approach. The business case is supposed to be briefed and approved by senior leadership and most likely, the board of directors. This will outline expectations, motivations, funding, and any other requirements that the team may choose to share. Most mature organizations have existing business case templates which should be utilized for this purpose. Factors to be considered in the business case would include: The BIA The risks that the ZT program is designed to address The cost of the project (e.g., capital costs, operational costs, resourcing and administration costs) The cost of not doing the project (i.e., the impact of not implementing ZT), to include costs incurred due to any data breaches or security incidents involving access controls What the organization stands to gain through ZT (e.g., ease of access administration, reduction of the visible attack surface, and more) Additional benefits that come about through improving the organization’s security culture ZT adoption may help the organization position itself favorably among competitors. For example, a software as a service (SaaS) provider may include ZT in its marketing collateral and sales materials to demonstrate the optimal security posture of its platform as well as its forward-thinking commitment to protecting customer privacy. 3.5 Use Case Examples The following use case examples can help organizations anticipate priority and scope-related concerns regarding specific access types and environments. 3.5.1 Role Based Access Control for Internal Staff Assuming that the organization has implemented network segmentation, network zones, and micro- segmentation with different security requirements, administrators can define policies accordingly. For example, a soap manufacturing company may place all the trade secrets related to soap recipes and formulas in a network segment that only server administrators and recipe/formula engineers can access. Implementing ZT means that any malicious movement using compromised credentials is preempted with device verification, thus securing trade secrets. © Copyright 2023, Cloud Security Alliance. All rights reserved. 15 3.5.2 Remote Access Remote access is the new normal way of working. Remote access users include (but are not limited to) employees, contractors, temporary staff, suppliers, etc. Remote access also opens the possibilities for lateral movement via compromised access controls. Administrators mitigate this risk with technology like virtual desktop infrastructure (VDI) and/or corporate cloud workstation resources and by publishing applications and resources. However, application jailbreaking may be a residual risk in these scenarios. Using ZT, administrators can define policies such that remote workers access only those applications and resources for which they are authorized. This reduces the attack surface that is available to remote workers. The attack surface can also be reduced with device authentication before granting access to users. As you may recall, device authentication relates to ZT’s “verification before granting access.” Administrators may also integrate opportunistic MFA with their ZT controls for behavior analysis and geofencing. 3.5.3 Services Accessed Using Mobile Devices Organizations subscribe to services that can be accessed from mobile devices (e.g., smartphones, tablets). Services like HR portals, portals for salary/wage slips, and office directories can be accessed via mobile applications and web applications run on browsers. To ensure that compromise of users’ credentials do not lead to compromise of data, ZT policies can aid in authenticating the users and their devices before granting access to the services. Additionally, MFA can be configured with ZT. As ZT policies can be made as granular as possible, separation of duties between the users and administrators help prevent any privilege escalation attacks. A caveat is that it should not be assumed that ZT can prevent access to these services via stolen devices. 3.5.4. Third-Party Service Providers with Remote Access Administrators can leverage ZT policies to authenticate third-party users and their devices to determine the required access privileges for resources while hiding all other assets to prevent any lateral movement. This helps reduce the attack surface for any supply chain risk materialization. 3.5.5 Staff Access to Assets in Hybrid Environments Staff access to root accounts for cloud services such as AWS and Azure should be tightly controlled. Lack of awareness or speed to market may make staff miss out on controls like configuring MFA for such resources. Administrators can configure ZT policies for such accounts and subscriptions, thus ensuring that the same policies are applied to all accounts. In addition, these accounts and subscriptions remain hidden behind the policies leading to reduced visibility in the public domain resulting in reduced attack surface. © Copyright 2023, Cloud Security Alliance. All rights reserved. 16 3.5.6 SaaS & PaaS SaaS and platform as a service (PaaS) require access at two levels. One is access to the service and the second is access to the features within the service. Implementing ZT will help define attribute- based access control (ABAC) for the features within the service. For example, granting database administrators (DBAs) access to the master database in a SQL database-as-a-service but not to data persisted in user databases. The applications are often consumed for managing the organization’s private or sensitive data. It is important to ensure that only legitimate users can access the application, though it is a cloud-hosted one. ZTA can be designed such that access to the application or platform is allowed only for the traffic coming from the ZT gateway. Thus the user and the entity can be subjected to the validations and policies before sharing access to the assets. The design can be achieved via SAML authorization, where the SAML requests from the gateways alone are accepted at the SAML service provider residing at the SaaS/PaaS application. 3.5.7 Application Release & DevOps High-velocity application release practices like DevOps and its supporting automation and continuous integration/continuous delivery (CI/CD) framework require thoughtful integration with ZTA. ZTA can be integrated with DevOps to secure authorized connections to the various deployment environments (e.g., development, test, staging, and production) to ensure proper connectivity to protected servers and applications. ZTA can provide a better developer experience by streamlining access provisioning. Ideally, ZTA should be integrated into the application stack to fully leverage its security features. During planning for ZT implementation, the following usage areas need to be considered: Secure remote access during the application release cycle Access to individual protected servers and applications Integration of ZTA into the application stack Common DevOps practices such as the use of virtualized environments and containers can streamline ZTA integration; that said, security architects must fully understand the chosen ZTA 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 and repositories supported by their ZTA implementation. 3.5.8 Industrial Control Systems, Operational Technology, & Internet of Things Industrial control systems (ICS), operational technologies, and the Internet of Things (IoT) rely on generic non-user identities (service accounts, resource accounts, roles, etc.) to access resources. However, these identities can be enabled with interactive logon rights for users—a feature that can be potentially compromised or abused. Furthermore, investigating security events involving interactive © Copyright 2023, Cloud Security Alliance. All rights reserved. 17 logon rights is challenging, as logging only records generic identity names, not the name of the user behind the generic identity. Implementing ZT in these environments ensures that identities have only the required access to assets for the task at hand, thereby limiting the attack surface in the event the identities are compromised. 4 Gap Analysis A gap analysis is an industry-accepted tool that allows organizations to determine how to best realize their objectives. At its core, a gap analysis is a three-step process that compares where the organization is with where it wants to be and then defines a road map to close the gap. Most organizations have a preferred gap analysis framework like Strengths, Weaknesses, Opportunities and Threats (SWOT)12, the McKinsey 7-S Framework13, or the Nadler-Tushman Congruence Model14, to name a few. Depending on the size of your enterprise, you may undertake several gap analyses for different business units, geographies, and functions. A gap analysis consists of the following steps: Determine current state Determine target state Create a roadmap to close the gap Requirements 4.1 Determine Current State The first step in the gap analysis is to make an objective, comprehensive assessment of the organization. Ideally, prior third-party assessments, maturity models, frameworks, and other existing resources can help inform this effort. For example, the CISA Zero Trust Maturity Model provides organizations with a framework to assess their current state regarding ZT adoption. The following are crucial steps for determining the organization’s current state: Define the current protect surface(s) and the implications for each ZT pillar: Identity, Devices, Networks, Applications & Workloads, and Data List current controls for each pillar, focusing on the protect surface for each respective pillar Determine and declare the current CISA maturity stage for each pillar For example, an organization defining its current protect surface regarding data has determined that most of its data-at-rest is being stored unencrypted. Additionally, the organization is still using traditional password-based authentication for its systems and continues to rely on local authorization for security access to application workloads. 12 Humphrey, A. (1960). SWOT Analysis. 13 McKinsey & Company. (2008, March 1). Enduring Ideas: The 7-S Framework. McKinsey Quarterly. Retrieved 2023, January 20. 14 Nadler, D., and Tushman, M. (1980). A Model for Diagnosing Organizational Behavior. Organizational Dynamics 9, no. 2. © Copyright 2023, Cloud Security Alliance. All rights reserved. 18 Figure 4: CISA Zero Trust Maturity Model: Traditional15 Per the CISA Zero Trust Maturity Model, a firm storing its data unencrypted falls into the Traditional tier; the same is true of this organization’s application workload and identity protect surfaces. Part of this process also involves determining risk appetite, which should feed into scoping activities and decisions when the future state is decided/selected. 4.2 Determine the Target State Once the planner, user, or organization has a solid understanding of the current state, the next step in the gap analysis is to determine the target state. During this second phase, the goal is to: Define the protect surface and the impact for each in-scope pillar across the organization (i.e., what each should look like when ZT has been implemented). Determine and declare the desired target CISA maturity stage for each pillar. The CISA Zero Trust Maturity Model represents a gradient of implementation attributes across five distinct pillars, where minor advancements can be made over time toward optimization. Regarding the previous example, the organization may determine that achieving an Optimal ZT maturity stage, while ideal, may be prohibitive due to several factors. The organization may require more long-term vetting of AI/ML technologies and may be unable to encrypt all of its stored data across each environment. The organization may elect to adopt MFA as its future state to bolster the identity protect surface, and to start with encryption at rest for cloud and remote environments to bolster the data protect surface. Figure 5: CISA Zero Trust Maturity Model: Advanced16 The organization’s target ZT maturity stage and future state should ultimately fall under the Advanced or Optimal tier. However, achieving this requires a gradual evolution through incremental steps, first exhibiting characteristics of the Initial tier, then proceeding to the Advanced tier, and finally reaching the Optimal tier in all areas. As risk appetite was defined when determining the 15 Figure adapted from: CISA. (2023). Zero Trust Maturity Model (Version 2.0). 16 Figure adapted from: CISA. (2023). Zero Trust Maturity Model (Version 2.0). © Copyright 2023, Cloud Security Alliance. All rights reserved. 19 current state, the scope is defined when determining the target state based on those previous assessments. 4.3 Create a Roadmap to Close the Gaps Once an organization knows where it is and where it is going, it should create a roadmap of the required future state across all pillars. During the roadmap phase, the organization should compare the current state and maturity stage to the desired state and maturity stage, listing the future controls required to raise the current maturity stage to the future desired state. For example, the organization mentioned previously must now plan for bridging the identified gaps between its current Traditional maturity stage and target state. By establishing the foundational ZTA, the ZTA can evolve to effectively manage access control, implement more encryption, increase data protection, and add segregation of duties and principles. Once this is integrated into operations, detailed risk assessments can be made, along with appropriate response plans for all risks related to compromised data or access control points. The roadmap should include all the controls and procedures necessary to bring the organization from a Traditional to an Advanced maturity stage. As a simple example, in the Traditional approach, it is perhaps enough to have a login screen and get to enterprise-sensitive data or business functionality with a single password. For your initial ZT implementation (Initial stage), you couple the login screen with MFA requirements. In a subsequent ZT implementation project (an Advanced stage), you add safeguarding technologies so that the MFA process cannot be leveraged by a bad actor for phishing attacks. In a ZT implementation that further advances your login and MFA processes, you add enterprise-wide agents that can track network activity (Optimal stage). Now, your organization can set up monitoring consoles and security experts can be flagged to spot seemingly dangerous activity, enabling them to take corrective measures before a security breach can occur. 4.4 Requirements One of the key outputs of the gap analysis will be requirements for ZTA implementation. There is a large body of work for requirements analysis. The following section focuses on key items unique to ZT. How to define and document your requirements will largely depend on whether your ZT effort is stand-alone or part of a larger effort. If ZT is part of a larger effort, it is recommended to collect your requirements in a ZT-specific section to maintain focus. This may not be practical in all situations but should be the objective. If ZT is a stand-alone effort, you have the luxury of a dedicated requirements document that can be used by the project team. Either way, a primary focus in the early phase(s) of planning will be to solidify your identification, entitlement, and access control infrastructure. At a minimum, you want to be sure you have requirements defined for: Source of truth for unique identities Management of those identities through the full life cycle of employees, contractors, and vendors © Copyright 2023, Cloud Security Alliance. All rights reserved. 20 Definition, provisioning, and management of entitlements Definition, provisioning, and management of access controls Segmentation/micro-segmentation Incident detection and response Reporting and analytics Special considerations (e.g., devices) Concept of least privilege Segregation of duties 5 Define the Protect Surface & Attack Surface The following unit covers the crucial activities for identifying the protect surface and attack surface, outlines how the protect surface and attack surface are interrelated, and provides key considerations for designing the two surfaces to complement each other. 5.1 Identify the ZTA Protect Surface Malicious actors compromise data confidentiality, integrity, and availability via improper access. Subsequently, ZT aims to reduce cyber attacks and data breaches through more stringent access requirements, that is, by requiring authentication and authorization prior to granting access to resources. Hence, to reduce cyber risk in this manner, organizations must understand and identify data and their locations. As data cannot exist in a vacuum and needs a house (i.e., the asset) to live in, the data and asset both need to be identified, as well as their respective criticality levels. Extending this premise to the organization at large, ZT planners should define what needs to be protected in an organization, also known as its protect surface. NSTAC defines the protect surface as the area the ZT policies protect. Each protect surface contains a single DAAS element, and in turn, each ZT environment will have multiple protect surfaces. 5.2 Identify the Attack Surface Along with defining and defending the protect surface, organizations should also define the attack surface—the surface through which data and assets can be attacked. NIST defines an attack surface as “The set of points on the boundary of a system, a system element, or an environment where an attacker can try to enter, cause an effect on, or extract data from, that system, system element, or environment.” 17 Organizations more often experience difficulties in defining the attack surface for defense purposes, since defining an attack surface at a given point in time for most organizations can be a moving target due to the evolving usage patterns of devices and assets (e.g., BYOD, SaaS). In contrast, a protect surface has a defined boundary. 17 NIST. (2018, October). Glossary: attack surface. NIST Computer Security Resource Center. Retrieved 2023, January 20. © Copyright 2023, Cloud Security Alliance. All rights reserved. 21 The diagram below illustrates the Zero Trust Architecture as defined by NIST, originally in the SP 800- 20718, and then further elaborated in SP 1800-35B19 draft. Figure 6: General ZTA Reference Architecture20 Applying the NIST definition to the above diagram, the attack surface is identified as follows: Endpoint Information flow between the endpoint and policy enforcement points (PEPs) Information flow between PEP and resource Information flow between PEP and policy decision point (PDP) Information flow between PDP and policy information points (PIPs) Policies Identity and access management used by ZT End users’ identities API identities The application stack for PEP, PDP, and PIP The solution in the supply chain The identified attack surface can be analyzed for threats, abuse cases, and mitigations as illustrated in the table below, an example of attack surface-focused threat modeling using STRIDE, a common threat modeling methodology championed by Microsoft.21 18 NIST. (2020). Zero Trust Architecture (SP 800-207). 19 NIST. (2022). Implementing a Zero Trust Architecture (SP 1800-35B). Second preliminary draft. 20 Figure adapted from: NIST. (2022). Implementing a Zero Trust Architecture (SP 1800-35B). Second preliminary draft. 21 Microsoft. (2009, November 12). The Stride Threat Model. Microsoft Learn. Retrieved 2023, January 20. © Copyright 2023, Cloud Security Alliance. All rights reserved. 22 Attack Surface Threat Abuse Case Mitigation Information Spoofing A malicious actor can Use TLS certs certifications flow between Tampering perform a man-in- as described in the PEP and Information the-middle attack to Encryption section Resource disclosure spoof the user of the Use mTLS for 2-way Information resource authentication flow between A malicious actor PEP and PDP can intercept and Information manipulate data on flow between the information flow PDP and PIPs channel between the resource and the PEP, between the PEP and the PDP, and between the PDP and the PIP Endpoint and its Spoofing A malicious actor Onboard the ZT endpoint environment (malware/phishing agent as described in the attack), may try to earlier modules harvest credentials Employ user- based / used by the endpoint machine- based certificate to log into the ZT for authentication endpoint agent (as recommended in Introduction to Zero Trust Architecture) Policies configured Tampering A malicious insider Use the supplier due on PIP/PEP/PDP Information can try to add/ diligence process to check disclosure modify policies if this is a possibility in the vendor’s environment- (background checks, RBAC on the backend, etc.) Logging and possible sharing of logs with customers © Copyright 2023, Cloud Security Alliance. All rights reserved. 23 PDP and PIP Spoofing A malicious actor Use MFA to address administration Elevation of may try to spoof spoofing threats via console privileges administrators credential harvesting Repudiation to access the Check for assurance administration from the vendor that an console for policies administrator cannot access the data belonging to a different organization Logging of all actions carried out by an administrator with a possibility of sharing the logs with the customers IAM for ZT users Spoofing Identity providers Identity provider is may become assessed for security compromised to make sure it is fit for leading to the purpose harvesting of users’ credentials by malicious actors © Copyright 2023, Cloud Security Alliance. All rights reserved. 24 Supply chain of ZT Spoofing Lack of governance, Information security Tampering risk, and compliance management system Repudiation in the ZT implemented and practiced Information organization leading in the organization Disclosure to lack of line-of- Conduct background Denial of sight visibility to checks for the staff that Service (DoS) security posture in works with customer data Elevation of the organization. Vulnerability management privileges Insider threat leads program to upgrade and to the exfiltration of update technologies that customer data compromise the ZTA Vulnerabilities in Secure SDLC to ensure the the management management console is plane / software developed securely components leads to Web application firewall the compromise of (WAF) drops any packets policies that can result in DoS at Lack of vendor the management console controls results in Underlying infrastructure DoS for customers components (server DoS at the endpoints, web servers, application layer application servers, Lack of OS containers, etc.) are hardening, secure hardened, secure configuration, configuration is applied, host-level intrusion host intrusion detection detection, and is enabled, file integrity network layer monitoring is enabled, etc. intrusion detection Vulnerabilities on the management console lead to SQLi, XSS, and lateral privilege escalation for customers Table 1: Example STRIDE Threat Model © Copyright 2023, Cloud Security Alliance. All rights reserved. 25 5.3 Illustration of Protect Surface & Attack Surface The credit card example below illustrates the protect surface and attack surface: Figure 7: Attack Surface and Protect Surface: Credit Card Example The cardholder data, personally identifiable information (PII), and underlying assets (i.e., server) comprise the protect surface, since any unauthorized access to the assets may subsequently lead to unauthorized data access, resulting in a data breach. Consequently, these assets should be covered with ZT policy that requires entity verification for asset and data access to ensure that such breaches do not occur. Then the organization permits end-users and administrators to access cardholder data and PII housed on the server via an application accessible through their laptop’s browsers. These laptops, browsers, and servers are potential entry points for malicious actors; any vulnerabilities or lack of hardening on the asset may enable malicious actors to compromise the server and data. Hence, the attack surface encompasses the end-user and administrators’ devices and applications, as well as the protect surface. The attack surface can increase with the addition of another laptop and a cloud service. This is because the entry points to the data increase with added assets and devices. © Copyright 2023, Cloud Security Alliance. All rights reserved. 26 Figure 8: Laptop and Cloud Services Expand Attack Surface However, the protect surface remains the same and is, therefore, more stable and constant than the attack surface. That said, the stability of the protect surface means: At the onset, it essentially identifies all the data and assets an organization should protect Along with data, it allows the organization to identify the location of the data, the assets that hold the data, and the critical services that the data requires to provide business functions Once data, the assets, and the critical services are identified, the protect surface allows the organization to move controls closer to the assets at hand and essentially minimize the risk of compromise for critical assets via attack vectors like lateral privilege escalation and visibility to a public network. In reference to the previous diagram, if a malicious actor successfully compromises the entry points via the application running on a browser, it is only a matter of time before cardholder data or PII is compromised via a vulnerability exploit of the asset. Identifying the assets hosting cardholder data and PII (i.e., the protect surface) enables the organization to move controls like role-based access control (RBAC), system hardening, and secure configurations closer to these assets. For example, the base image of a server build can be hardened before deployment, and the web server hosted on the server asset may be separated from the database host; that is, the database may be moved to another physical server. © Copyright 2023, Cloud Security Alliance. All rights reserved. 27 Additionally, the organization may create two protect surfaces with micro-segmentation while aligning itself to NSTAC’s protect surface definition. Figure 9: Two Protect Surfaces Created with Micro-Segmentation 5.4 Protect & Attack Surface Considerations While the protect surface provides an inside-out view of the organization, the attack surface provides an outside-in view, or a view from the vantage point of the attacker trying to break in. The protect surface and attack surface complement each other in helping organizations identify what needs protection and how to optimally secure the most critical assets. Figure 10: Different Views of the Organization © Copyright 2023, Cloud Security Alliance. All rights reserved. 28 ZT calls for protecting access to any applications or servers shared privately with internal or external users. It is important to assess and plan for each of the assets. Each user should be granted the minimum required access to the assets following the principle of least privilege. The following are crucial considerations for defining the protect surface: Data types involved (e.g., cardholder data, personally identifiable data, health data, trade secrets, by-products of business processes) Data and asset classification (e.g., public, internal-only, confidential, and restricted) Applications and/or services that handle the identified data Critical business functions (e.g., turbine health in a nuclear power plant) Organizations should design ZTA protect surfaces that incorporate the following: The policies defined for ZT access The data defining the users (e.g., username, password, identification of the asset held by a user) The data defining the assets (e.g., servers, required services, and connections) The transport layer Business execution algorithms The logical and physical relationships between the asset at the core of the protect surface and other business and IT functions 6 Document Transaction Flows As ZT planners acquire an understanding of the requirements for the system being built and define their protect surfaces, they should also identify what transactions occur with those protect surfaces and how they interrelate. Understanding and tracing of the data flows, application transactions, and business processes allows the planners to understand if the controls in place are sufficient to safeguard the protect surface. In other words, documenting the data and transaction flows ensures that access of entities to the protect surface happens within the defined risk appetite of the organization. Transactions in a system are often derived from the underlying business requirements as part of solution development. The transaction within a system exists because it addresses a business need and is often tied to maintaining business continuity. Business requirements can change over time as will the security considerations. In the context of ZT, a transaction is any action within a system that needs verification. This could be any component in the architecture from person and non-person entities, an internal or external device to the system, or the process itself that owns the transaction in question. A number of these components are identified in the initial sections of this module. If you are new to transaction flows and the tools available to create them, one way to look at this task is to envision the data’s life cycle. What business transactions occur and what services are invoked to complete a transaction? This could be as simple as the data flow of an online retail purchase, or it could be more in-depth like a customer relationship management (CRM) transaction generating a sales prospect or lead record for a sales organization. © Copyright 2023, Cloud Security Alliance. All rights reserved. 29 6.1 Example Transaction Flow: eCommerce The following is a simple illustration of an eCommerce transaction, tracing the steps that occur when a purchase is made from the perspective of the credit card transaction. In this example the identified protect surface is the payment process components. Figure 11: Example Transaction Flow: eCommerce Payment Process 1. The merchant’s website sends a credit card transaction to the payment gateway via a secure connection. 2. The payment gateway receives the credit card transaction request and submits it using a secure connection to the merchant bank. For accepting payments, merchants need an account with a payment gateway. 3. The merchant bank’s processor sends the transaction request to the credit network to process. 4. The credit network forwards the complete transaction to the institution which issued the card. 5. The credit card issuing bank accepts or refuses the transaction based on the card’s valid card number, cardholder’s name, expiration date, and card verification code and sends back the results to the credit network. 6. The credit network transmits the results to the processor for the merchant’s bank account. 7. The merchant’s bank processor sends the results back to the payment gateway. 8. The payment gateway saves the transaction results and transmits those results to the merchant’s website, which in turn delivers them to the end customer. This is the end of the © Copyright 2023, Cloud Security Alliance. All rights reserved. 30 approval process. 9. The customer’s card issuing institution or bank checks the card number and name, and approves the transaction, sending the funds to the credit network. 10. The credit network sends the funds to the merchant’s bank. The merchant’s bank deposits the funds into the merchant’s bank account and the payment is complete. Several steps occur in an end-to-end transaction, all in a matter of seconds or milliseconds. ZT planners should consider approaching the questions of who, what, where, when, how and why for the steps in this end-to-end transaction, and why each step needs to happen. This will help to ensure that the controls to guard the protect surface fall within the architecture being defined and adhere to organization policies and standards without introducing unmitigated risk. For instance, if the who element is a customer, the transaction may be handling PII. The protect surface must therefore be designed to keep the customer’s PII data secure during the transaction. This analysis should occur at each step in the transaction process. Refer to the previous section discussing how the protect surface and attack surface are defined. When you measure the risk of transactions, the protect surface will need to be already defined. The attack surface could be modified as new transactions are added or existing ones are modified to keep the architecture in line with business requirements. An example is provided below for illustration purposes. The transaction focus and protect surface in the last two right-hand columns are where you compare your risk and validate it against the protect surface discussed earlier in this module. Who What Where When How Why Transaction Protect Focus Surface Focus Customer Person Anywhere 24x7 365 Application In need of Disclosing Customer or entity days a Interface the result the too much PII including initiating a year transaction will unnecessary PCI related transaction provide data Information Merchant/ Selling Online and 24x7 365 Through To make Web front Customer eCommerce things possibly at days a an online money end, customer data in Presence a physical year commerce data, inventory, motion location portal business records and at rest. Entry point device(s), PCI compliance Bank Holder of In a giant 24x7 365 Online Money needs Customer data, PII data, all things vault and in days a transactions, to be deposited PII information, customer monetary the ether year transfers, in or withdrawn account assets and person information, corporate availability, fraud assets alerts © Copyright 2023, Cloud Security Alliance. All rights reserved. 31 Credit Card Provide Everywhere 24x7 365 Online Ease of use, Similar to the PII data, Issuer credit cards days a transactions, make money banks customer and credit year physical card, through assets and/ limits to tied to an interest or corporate consumers account assets, PCI compliance Payment Provides a Between the 24x7 365 API Provide a Inbound PII in motion Gateway connector merchant days a connections mechanism connections and data from the and credit year from for merchants from at rest. PCI merchant card merchant to send credit ecommerce compliance transaction accounts, card data to site, outbound process e.g., PayPal a credit card connections issuer to credit card industry Table 2: Transaction Flow: eCommerce Payment Process Following this eCommerce example, the question to ask is if the protect surface is meeting all requirements to ensure that customer data and financial information is not disclosed. Are you storing any credit card numbers as part of your interaction between the payment gateway and the credit card issuer? Is that transaction of data stored properly with the proper controls around it according to organizational and regulatory requirements (e.g., PCI-DSS)? Putting a matrix together such as this will help validate whether the protect surface is defined, monitored, and enforced properly. More details on data, monitoring, and transactions are discussed next. Additionally, the matrix that follows identifies transactions in your solution which may not be your responsibility, such as the banking institution itself, but that still need to be considered when planning your protect surface. 6.2 Transaction Discovery: Functional Analysis & Tooling A critical, initial step is determining what data flows are involved. Establishing the proper visibility is crucial for discovering the transactions, their data, and data types (i.e., classification). © Copyright 2023, Cloud Security Alliance. All rights reserved. 32 Figure 12: Transaction Visibility & Control Whether the organization is operating in a private, public, or hybrid cloud, the analysis, tooling, and automation to identify what transactions are critical to the business and business processes are fundamentally the same. Below are some key functional areas to consider. 6.2.1 Collecting Data To define a transaction, begin with an initial understanding of the data—what it is, where it is, and where it goes. Start with existing knowledge about the organization’s business process and underlying architecture. It may help to leverage numerous sources such as packet captures, logs, or more sophisticated methods of traffic analysis between the service entities comprising the systems. 6.2.2 Discovery of Known & Unknown Transactions From the data collection methodologies used, organizations will discover what transactions look like within the service or system being analyzed. They may discover unknown transactions they were previously unaware of. For instance, in the eCommerce example, there may be a transaction between the payment gateway and the eCommerce application to determine what tax to add to the full value of the transaction. Perhaps a tax rate changed based on doing business in a new market, or a shipping method changed or was added due to a new delivery requirement. While not specific to the method, this represents an ancillary process uncovered in the data collection phase. © Copyright 2023, Cloud Security Alliance. All rights reserved. 33 6.2.2.1 Transaction Inventory In completely new deployments, transaction inventories will be defined and developed during the architecture and design phase; nonetheless, organizations should create an inventory as part of the planning exercises. If organizations are pursuing an already existing deployment to migrate to a ZTA, they should collect and inventory the known transactions to maintain, highlight the ones that will change or become deprecated, and create entries for new transactions expected to be part of the solution as it is being developed. 6.2.2.2 Transaction Records Transaction records are the historical paper trail of the behavior of transactions and the types of data involved. Recall that at every transaction layer, ZT controls will continuously analyze the processes and compare them to existing policy enforcement rules. Keeping and analyzing transaction records are part of the planning process and remnant samples of monitoring and analytics. 6.2.3 Monitoring & Analytics Once you know what transactions are in your system, you will want to monitor them to collect statistics and profile the behavior. Again, as shown in the eCommerce example, monitoring the payment gateway and collecting analytics from dollar values being processed through your system will start to build a view of the behavior and trends of the process you ultimately want to protect. Monitoring and analytics are covered more in-depth later in this module. However, it is important to understand that ZT prescribes a continuous assessment of all transactions. 6.2.4 Identifying Anomalies & Edge Cases During transaction discovery, ZT planners should identify what behaves unexpectedly or abnormally from the baseline. Edge cases may be greater in number than expected. Does this change the protect surface area as a result? Are new transactions required to mitigate any risks? Do any of them change? For instance, in the eCommerce example, imagine the entire platform was designed at the baseline to allow for free shipping within the United States. The shipping provider charges the merchant for this behind the scenes. Suddenly, due to a marketing campaign in Hawaii and Alaska, there is great demand for overnight shipping to both locations which can’t be met by the current provider integrated into your shipping workflow. Even though it is a small corner case sales and sales transactions, you need to bring in an additional third-party shipping partner to meet the shipping SLA. In doing so, do you need to supply them with any additional customer data? Do you have to set up a separate shipping workflow to integrate with them? Can they maintain the same level of privacy? Do you have to do any additional monitoring to ensure this new shipping partner doesn’t create any new risk to you or the customer? While this seems like a simple edge case on the surface, the seemingly benign act of offering a specific delivery mechanism to a specific subset of customers requires going through this new transaction again and checking all the boxes to ensure that your protect surface doesn’t require additional controls. © Copyright 2023, Cloud Security Alliance. All rights reserved. 34 7 Define Policies for Zero Trust In a ZT approach, the visibility of and access to resources by any user or device is regulated and controlled by policies. Policy planning should be carried out with utmost care, with a granular understanding of who should get access to what resource, which actions are allowed, under which conditions, and for how long or at what time of day. The policies need to be planned prior to implementation as doing so can help the stringent control for each of the user or user groups. The controls and policies allowed for each asset need to be documented for a better organized implementation and maintenance of the policies. Each of the newly introduced changes needs to be tracked down with a separate tracker that is peer-reviewed. The user and the access are trusted after the authorization at the zero-trust gateway as the policies enable the authorization of the access. Figure 13: PDP/PEP & Zone Interactions22 ZT systems enforce validation of the user and the device before permitting any access, hence the ZT policies allow organizations to plan and create access policies based on user or device attributes and contextual risks. By leveraging aspects such as directory group membership, IAM-assigned attributes and roles, location, and device posture, organizations can define and control access to cloud or data center resources in a way that is meaningful to business, security, and compliance teams. 7.1 The Policy ISO 9001 defines policies as documents that include information about a set of standards. Within organizations, policies might appear in a hierarchical structure, and each p

Zero Trust Planning Study Guide PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue