Understanding zero-trust design philosophy and principles

In this Help Net Security interview, Phil Vachon, Head of Infrastructure in the Office of the CTO at Bloomberg, discusses the varying definitions of zero trust among security professionals and companies, emphasizing its broad design philosophy.

Vachon explores challenges in implementing zero trust, distinguishing between user-end and back-end infrastructure integration. He provides insights into assessing a company’s maturity in zero-trust adoption and shares advice on overcoming challenges and measuring success.

Why does the definition of zero trust vary so significantly among security professionals and companies? How do these variations impact companies’ approach toward implementing zero trust?

Zero trust is a broad design philosophy, distilled from Saltzer and Schroeder’s seminal 1973 paper, “The Protection of Information in Computer Systems.” It described ten design principles (8 fundamental + 2 extras) that must be considered when designing and building systems intended to be secure. The distilled principles applied in zero trust architecture are:

• Always verify identity and authority – Check who is calling, where it is coming from, and if they should be allowed to access a particular resource. Every resource should check authority – no assumptions should be made based on where the actor is.
• Always apply the principle of least privilege – Ensure that any actor in the system has only the exact authority needed to get the job done. Any extra authority increases their capability, as well as the risk inherent in a given system.
• Always assume the endpoint or network is compromised – Treat even your corporate networks as though they are as trustworthy as the open Internet (though they hopefully have a lot more controls in place). Treat your internal services like they are out on the open internet, and design the controls around them accordingly.

So, why do people have different definitions? First, the concept of zero trust is very broad, by definition. After all, zero trust is a design philosophy that applies to every facet of an enterprise’s IT estate – from the laptops and desktops that employees use to do their jobs, right through to the servers or public cloud infrastructure used to deliver services to customers. How you approach a zero trust implementation is very different in each of these scenarios – and implementers and architects in those domains will have different take-aways based on the implementation of controls needed for the environment they focus on.

Because of this difference, the second reason takes hold – every security vendor wants (or at least wanted!) to be a “zero trust solution” vendor. But again, the implementation of this design philosophy varies so widely from firm-to-firm. Because of vendors crowding into the space and using zero trust as a marketing buzzword – and the wide design space in general – implementations and products muddied the waters about what zero trust is all about.

Finally, zero trust in an enterprise is the adoption of a design philosophy and architectural concepts – not as a particular goal as a part of a project or existing initiative. These philosophies impact your decisions about IT service offerings, changing how you design and deliver solutions for your internal customers. This is far more abstract than a “zero trust” silver bullet product that brings in dollars each quarter!

What are the most common challenges you’ve observed when companies attempt to implement zero trust within their corporate IT environments? How do these challenges differ between user-end implementation and back-end infrastructure integration?

Technology teams can have a bad reputation for being expensive and hard to work with, as well as for lacking an understanding of their context in the broader goals of a firm. This creates a culture of distrust between technology and the business – and the need to break down these barriers to enable progress. These challenges rear their heads in some of these very ugly ways:

• Lack of user empathy – Employees who use corporate IT-provided infrastructure are usually the first to feel the pain. User advocacy is core when delivering any new initiative, regardless of whether it is security-related or not.
• Lack of executive buy-in due to the mistaken perception that this is overly expensive – Infrastructure is regularly ignored because of the perception of low ROI/high TCO.
• Lack of executive understanding of firm-level risk tolerance needed to make changes to how the company does business today.
• Lack of foundational tooling (e.g., PKI, cryptographic services, proxies, appropriate automation, etc.)
• Cultural obstructions (e.g., concerns about employee productivity overriding security control deployment)
• “Not invented here” syndrome – too many attempts to reinvent the wheel, especially when a SaaS product often might get you further, faster, and closer to your security control objectives.
• “Hyrum’s Law” – As you deploy something new (or something that changes some behavior of a system), you might break assumptions that other people made about that system. Migrations and adding security controls to a system must be done thoughtfully and carefully.

From your perspective, what are the indicators of a company being ‘mature’ regarding its adoption and implementation of zero trust? How can a company assess its level of maturity in this area?

First, take a deep breath and remember that maturity is tricky to measure – this is a journey of adopting a design philosophy, not a destination! How you take the first step on that journey will vary.

One good back of the napkin metric in evaluating a firm’s adoption of these design principles is to first look at its internal policies and risk tolerance definitions. If the firm has a good understanding of its own risk tolerance, this is a good start. When the firm has policies that define identity management, authentication practices (both the authentication process and the approved systems to use), as well as data protection/data security policies that advocate the above design principles, they’re well on the way. If the company has standards for cryptography, key management and public key infrastructure, they’re even further along. To me, it’s amazing how many enterprises often leave these things as an implementation detail, rather than focusing on how they can become enablers for execution and consistency.

Of course, there are other signs that a company is headed the right direction – how much they’ve focused on scaling their IT estate implementation on automation-first approaches, a capability/intent-focused mechanism to reason around permissions (rather than focusing on the details of how a permission is implemented), frequent reassessment of privileges (including good maturity in handling movers/leavers/joiners for employees AND systems), as well as a strong decommissioning process.

If you see these signs, they’re on the right track. Of course, this assumes some of the basics, such as whether a centralized authorization/entitlements system tied to a ‘golden source’ identity management system and a single sign-on solution with multi-factor authentication are in place and are operationally mature.

Metrics for success are sometimes brutally simple. For instance, as WebPKI is rolled out for internal websites and services, you can now easily track metrics of which services in your inventory are accessible only over TLS and have a valid WebPKI certificate. Another easy metric: in your inventory, figure out how many sites are using SSO vs. some home-grown authentication vs. no authentication whatsoever. The hard metrics are the user-impact metrics – how much better (or more challenging) is the user experience after a deployment?

Having good design patterns for protecting both green fields and legacy systems is also a good maturity indicator. Using a VPN might be less than optimal, but it’s better than physical access implying system access; you might use VDI or other controls later on, while isolating the services from a network perspective.

Can you provide examples of successfully overcoming the challenges of implementing zero trust? What best practices would you recommend?

Treat your zero trust initiatives as product lifecycles – and don’t commingle your end user, remote access, and data center/public cloud initiatives. Identify MVP iterations for key deliverables, identify your stakeholders, define initial use cases to onboard, and figure out how you measure the impact this has on those users. Showing initial success and the right level of impact on users’ ability to do their jobs is key to overcoming buy-in challenges. This will make your program relatable to most users.

Remember, your customers are your colleagues and employees across the firm. When you deliver a new or updated platform (or a new control that could impact how people work), go into it with well-defined outcome-focused metrics. Be public about your milestones, and be transparent about your metrics. Be clear about the intent of these controls, and why these new requirements are critical. Be ready to pay down a long-tail of migrations, but also be sure to have a good view of the landscape, especially when you have a deep legacy long tail of services. Listen to your users – collect user feedback frequently (i.e., using pulse surveys and other similar approaches) to help shape your product vision, as well as to identify where your roadmap may have gaps.

Some third-party products people use every day to do their jobs may simply not support this type of infrastructure mindset. So, how do you create a moat around these services so they can still deliver business value, while reducing the risk they pose to the rest of the firm? Design patterns are key. Giving people an ideal state (i.e., pervasive use of SSO, public proxies requiring device-bound credentials to reach services), while having some backups (VPN for legacy services that are hostile to proxies, but user-based policy enablement for access to those services) can help build credibility for how the project is keeping business moving, while also improving the firm’s overall security posture.

Finally, don’t treat implementing a zero trust architecture as “yet another IT initiative” through which you have to torture users. Be thoughtful about user-impacting changes, have empathy for your users, and focus on enabling them to be secure, without adding pain.

How should companies measure the success of their zero-trust implementations? What metrics or indicators are most effective?

• Don’t use operational security metrics. They tend to be very service-oriented, but don’t give you an idea of the impact of your new controls you’re rolling out.
• Focus on metrics about enablement, control impediment, etc. Every time a control becomes a roadblock to someone getting their job done, you create a dark corner where Shadow IT can thrive, which can undermine your efforts. My favorite metric is “number of exceptions needed” for a control. If many exceptions are needed, the control might not be defined correctly.
• Many user endpoint projects will have a goal of sunsetting legacy infrastructure (i.e., eliminating a classic VPN). Instead, focus on milestones that reduce the risk of that legacy infrastructure.

What advice would you give to IT professionals and security teams just beginning their journey toward implementing a zero-trust model in their organizations?

Remember that you are taking the first step on a long journey toward a design philosophy. The destination is a state where you are able to focus on continual process improvement and user enablement, and ensure new capabilities that enable everyone across the business to use the same set of design principles.

Do not focus on technology implementation when communicating with executives. Instead, be laser focused on business outcomes. Implementing a new corporate IT platform always looks expensive from the outset, and the cost per user may well not decrease if you look purely at operational expenses and licensing costs. Instead, focus on how these methodologies enable teams to be more agile in serving the company’s customers, while being comfortable knowing they are doing it securely.