Moving to zero trust architecture (ZTA) and secure access service edge (SASE) is more of a journey than a project. This piece provides a roadmap for moving to ZTA and SASE that goes from choosing use cases and defining scope to establishing a policy model
and identifying gaps—all with an eye toward maturing the environment over time.
Gather Use Cases and Requirements
When getting started in ZTA and SASE it is key to address the common use cases for zero trust based on identity type: people, applications and equipment.
This is a crucial first step, because it narrows down the options for the policy decision and enforcement points (PEP/PDPs). Arguably, the policy engine between every session and every connection is the defining element of a ZTA. In fact, ZTA extends
the dynamic trust boundary, so it is short-lived, tightly scoped, enforced by policy, and informed by trust signals and telemetry. But how ZTA accomplishes this varies by type of identity:
- Risk-based authentication is used for people accessing cloud-based resources
- Application and identity profiling is used for services and application workloads
- Zero trust network access (ZTNA) is
used for workforce access to internal and cloud-based resources
- Microsegmentation is used for internal workloads and equipment
A good plan of attack is to:
- Begin with selecting the use case: Enabling a remote workforce, BYOD and securing cloud access are easier use cases to begin with.
- Define the scope of the initiative: Smaller scopes are easier to manage and may provide more opportunity to build skills before tackling larger or more complex scopes.
- Inventory the people, assets, applications and networks within scope: This can be done manually, but ideally, it should be performed using asset discovery tools or a cloud access security broker (CASB) for applications.
- Identify common data paths for people (user-to-resource), applications (service-to-service) or equipment (device-to-device) within scope for the use case: This helps identify the policy model.
- Identify the policy model: This provides per-session and per-connection control over data paths.
- Do a gap assessment against the ZTA tenets and corresponding security controls: For that, look to NIST and the Center for Internet Security (CIS).
Mapping to NIST SP 800-207 and CIS Critical Security Controls V8
ZTA is defined in the NIST SP 800-207 document. Security architects can implement the tenets of ZTA using existing control frameworks, aligning with the
NIST CyberSecurity Framework (CSF) and following the NIST Risk Management Framework (RMF) [external link to: https://csrc.nist.gov/Projects/risk-management/about-rmf].
The CSF provides the controls objectives and the RMF provides a high-level process for planning and implementation.
For organizations using the CIS Critical Security Controls (CSC), these prescriptive controls are mapped to the CSF functions: identify, protect, detect, respond and recover. The ZTA tenets can be supported by specific CSC control activities (see Figure
1).
|
| |
All data sources and computing services are considered resources. | - Inventory of data: CSC 11: Data Recovery
- Inventory of services: CSC 1: Inventory and Control of Enterprise Assets; CSC 2: Inventory and Control of Software Assets
|
All communication is secured, regardless of network location. | - Encrypt network traffic: CSC 3: Data Protection
- Segment and firewall hosts: CSC 4: Secure Configuration of Enterprise Assets and Software; CSC 12: Network Infrastructure Management; CSC 13: Network Monitoring and Defense
|
Access to individual enterprise resources is granted on a per-session basis. | - Identity management: CSC 5: Account Management
- Access management: CSC 6: Access Control Management
|
Access to resources is determined by dynamic policy—including the observable state of client identity, application/ service and the requesting asset—and may include other behavioral and environmental attributes. | - Identity: CSC 6: Access Control Management
- Application or service: CSC 2: Inventory and Control of Software Assets
- Requesting asset: CSC 7: Continuous Vulnerability Management
- Environmental attributes: CSC 13: Network Monitoring and Defense
|
The enterprise monitors and measures the integrity and security posture of all owned and associated assets. | - Security posture: CSC 7: Continuous Vulnerability Management; CSC 10: Malware Defenses
- Owned and associated assets: CSC 1: Inventory and Control of Enterprise Assets; CSC 2: Inventory and Control of Software Assets
|
All resource authentication and authorization is dynamic and strictly enforced before access is allowed. | - Principle of least privilege: CIS Control 06: Access Control Management
- Principle of least trust: CSC 12 Network Infrastructure Management; CSC 13: Network Monitoring and Defense
|
The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications, and uses it to improve its security posture. | - Collect information: CSC 8: Audit Log Management
- Assets: CSC 7: Continuous Vulnerability Management
- Network infrastructure: CSC 13: Network Monitoring and Defense
|
| | | Source: IANS, 2022 |
How To Improve Zero Trust Maturity
Within the given use case, the first objective is to increase coverage of these ZTA tenets on the people, devices and resources within scope. From there, ZTA maturity can be improved on by following maturity models such as the CISA Zero Trust Maturity Model. Similarly, the first objective with CIS CSCs is to increase control coverage aligned with the ZTA tenets within scope.
The next step is to ensure the controls are not only in place, but are also documented in policy, codified into processes and routinely audited. An organization can gauge the maturity here using the CIS Cybersecurity Maturity Model (CMMC). Make this process manageable by working only on the CIS sub-controls enabled to realize the ZTA tenets and only the controls applied within scope.
CIS CMM mapping to Cybersecurity Maturity Model Certification (CMMC) provides specific
NIST practice identifications. These practices correlate to 14 domains that align with the NIST SP 800-171 families (see Figure 2).
|
| | |
Establish and Maintain Detailed Enterprise Asset Inventory | | - CM: Configuration Management Control
- CA: Security Assessment and Authorization Control
|
Address Unauthorized Assets | | |
Source: IANS, 2022 |
Security organizations can improve NIST maturity by increasing the ZTA maturity (at the architectural level) and the corresponding CSC maturity (at the control level). The trick is to maintain the mappings between these three frameworks.
ZTA and SASE Use Cases
For workforce use cases one implementation of ZTA is ZTNA. ZTNA can be accomplished by proxy, standalone VPN or as a feature of a SASE product. In addition to ZTNA, SASE products often include:
- CASB
- DLP
- Firewall as a service (FWaaS)
- Software-defined WAN (SD-WAN)
- Secure web gateway (SWG)
One potential benefit of using SASE to deliver ZTNA is that it extends the trust signals and enforcement options. For example, downloading specific data to the device (monitored by DLP) or clicking on links and opening malicious websites (monitored by
CASB) may change the risk posture. The enforcement options may increase to controlling interactions on web apps (through CASB), preventing specific data (via DLP) or limiting the trust boundary at a lower layer (via FWaaS, SD-WAN or SWG).
The SASE market is in the early stages and is continuing to evolve. Compared to other approaches for ZTA, SASE should be evaluated more thoroughly to ensure the feature set performs as desired.
ZTA Transitional and Future-State Architecture
Advanced-state architecture for ZTA use cases will have the identity on their device accessing applications through a PEP/PDP, with additional security products providing input into the policy engine. This differs from the reality for many organizations
on the journey to zero trust in two aspects:
- There will likely be more than one policy engine governing multiple use cases due to the differences in enforcement and activity.
- There will likely be a hybrid of ZTA and traditional trust boundaries due to complexities with legacy systems and incompatible architectures.
It’s important to plan ZTA with as few policy engines as possible. In addition, evaluate the possibility for the policy engines to integrate on the control plane, and make sure to avoid policy sprawl.
The transitional and hybrid architecture must be carefully considered to ensure it does not provide adversaries ways to bypass or circumvent the ZTA controls. Some general rule of thumb tips include:
- The rule of compensating controls applies here: The compensatory approach must be equal to or stronger than the control it replaces.
- The people (user-to-resource) use cases may be complemented with traditional VPN solutions to provide ZTA and transitional access.
- The applications (service-to-service) and equipment (device-to-device) cases not in-scope for ZTA may use traditional network segmentation and firewall filtering.
- The journey to zero trust, much like the journey to cloud, will be one marked by a hybrid state. Organizations with strong capabilities to manage hybrid architectures will excel at moving to zero trust as time goes on.
Tips to Get Started on Zero Trust
Successful moves to zero trust will take time and be characterized by incremental wins. To ensure you start your journey efficiently:
- Focus on use cases and business outcomes: Clarify the requirements for zero trust and ensure the approach delivers business value.
- Manage the scope: It is not feasible to thoroughly apply ZTA tenets across an entire enterprise in the short term. Within the use cases, use scope to drive architectural decisions and control implementations.
- Mature: After achieving sufficient coverage within the scope, use maturity models for the architecture (e.g., the CISA Zero Trust Maturity Model) and for the controls (e.g., CIS CMM).
- Beware sprawl and gaps: Implement ZTA with as few policy engines as possible and manage your hybrid environment with strong compensating controls to avoid providing adversaries gaps and attack vectors.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.