The Benefits and Components of Zero Trust


It’s inevitable that building a security program based on Zero Trust will drastically decrease an organization’s risk exposure. 

While North/South traffic was traditionally controlled by firewalls, this strategy has failed. Today, one of the biggest challenges within an organization’s perimeter is preventing lateral movement of both threats and data. Network-based vendors focus mostly on network segmentation capabilities, however that is just one of the many benefits Zero Trust provides. 

Other common benefits and use cases of Zero Trust include:

  • Providing strong authentication
  • Resource access governance
  • Protecting customers data
  • Protecting organizational intellectual property
  • Achieving lower breach potential
  • Minimizing any reputational damage
  • Helping with compliance audit initiatives
  • Supporting company’s transition to cloud
  • Aiding in security program transformation

More often, enterprise organizations are adopting a Zero Trust model in order to provide both full visibility and control over users and devices that have access to a growing number of cloud applications and data services. This includes both managed applications within an enterprise’s ecosystem as well as unmanaged applications used by lines of business within the enterprise.

Components of Zero Trust Programs

Assuming the relevant technology and processes exist, a security program must include the following capabilities in order to address the architectural principles of Zero Trust. This includes the following components:

  • Identity attestation
  • Endpoint interrogation
  • Application verification
  • Data access validation

The output of these components is analyzed against a contextual access policy, providing a risk score where an organization can implement an adaptive enforcement with an isolated session to its desired destination (this is often referred to as “Adaptive Access Control”). Some would argue that if just one part isn’t satisfied, reaching the desired destination, such as a SaaS application, would not be allowed. However, this determination is based upon an organization’s acceptable level of risk and the parameters that are used to build a proper policy. 

It’s time for a mindset shift. The traditional thinking of “Allow” or “Deny” will not work in a cloud and mobile first world. Risk is a continuum.

Context is KEY!