Retour 
For a concept that represents absence, zero trust is absolutely everywhere. Companies that have explored how to embark upon zero-trust projects encounter daunting challenges and lose sight of the outcomes a zero-trust approach intends to achieve. Effective zero-trust projects aim to replace implicit trust with explicit, continuously adaptive trust across users, devices, networks, applications, and data to increase confidence across the business.
The primary goal of a zero-trust approach is to shift from “trust, but verify” to “verify, then trust.” We cannot place implicit trust in any entity, and context should be continuously evaluated. A secondary goal of zero trust is to assume that the environment can be breached at any time, and design backward from there. This approach reduces risk and increases business agility by eliminating implicit trust and by continuously assessing user and device confidence based on identity, adaptive access, and comprehensive analytics.
The journey to zero trust might not be exactly the same for every company, but zero-trust adoption can generally be broken down into five key phases.
Phase 1: Don’t Allow Anonymous Access to Anything
Once you classify user personas and levels of access within your organization, inventory all applications, and identify all of your company’s data assets, you can start with shoring up identity and access management (including roles and role membership), private application discovery, and a list of approved software-as-a-service (SaaS) applications and website categories. Reduce the opportunities for lateral movement and conceal applications from being fingerprinted, port scanned, or probed for vulnerabilities. Require single sign-on (SSO) with multifactor authentication (MFA).
Specific tasks for this phase include defining the source of truth for identity and what other identity sources they might federate with, as well as establishing when strong authentication is required, then controlling which users should have access to which apps and services. This phase also requires organizations to construct and maintain a database that maps users (employees and third parties) to applications. They also must rationalize application access by removing stale entitlements (of employees and third parties) that are no longer required because of role changes, departures, contract terminations, etc. And they must remove direct connectivity by steering all access through a policy enforcement point.
Phase 2: Maintain the Explicit Trust Model
Now that you have a better understanding of your applications and identity infrastructure, you can move into access control that is adaptive. Evaluate signals from applications, users, and data, and implement adaptive policies that invoke step-up authentication or raise an alert for the user.
Specific tasks for this phase require organizations to determine how to identify whether a device is managed internally, and to add context to access policies (block, read-only, or allow specific activities depending on various conditions). Organizations will also Increase use of strong authentication when risk is high (e.g., delete content for all remote access to private apps) and decrease its use when risk is low (managed devices accessing local applications for read-only). They will also evaluate user risk and coach classes of users toward specific application categories, while continuously adjusting policies to reflect changing business requirements. They should also establish a trust baseline for authorization within app activities.
Phase 3: Isolate to Contain the Blast Radius
In keeping with the theme of removing implicit trust, direct access to risky Web resources should be minimized, especially as users simultaneously interact with managed applications. On-demand isolation — that is, isolation that automatically inserts itself during conditions of high risk — constrains the blast radius of compromised users and of dangerous or risky websites