Pulse Employee

-March 8, 2018

Trust in a Secure Access Fabric

This is the first of a series of posts around a Secure Access Fabric provided and orchestrated by Pulse Secure solutions and services. In this entry, we will focus on trust as one of the key pillars in our fabric orchestration architecture.

The increased prevalence and diversity of end-user devices, IoT devices, applications, networks, connections, cloud services, enterprise applications and their information creates a web of connections with different forms and levels of trust and security.  As shown below, such multi-cloud connections or an access fabric extend well beyond the boundaries of traditional data centers and corporate networks. 

The concept of an access fabric or security fabric is not new and certainly not unique. They represent instances of emerging models like perimeter-less security and zero-trust security. Given their primary philosophy to “never trust and always verify,” in principle every access request would need to be checked and authorized explicitly and completely. Any user or device would be considered a remote, “external” user, and all enterprise applications and their information would be considered under threat, always.

From a security purist perspective, this may seem ideal; however, such an explicitly controlled, restrictive, no-trust approach is not really a viable option. An attempt to perform a complete user identification, client application and device reputation validation for each and every access request would be detrimental to performance and productivity. So, what is the solution? You would need to establish, manage and verify some form of lasting trust (however long or short) throughout the identification, authorization, and request handling stages of all secure access events. That means different stages of secure access events will have to rely on pre-established trust from different layers in the model.

For those of us with children, we experience similar considerations of trust on a daily or weekly basis: “Do you really want to check or authorize every action or choice that your child makes every minute or hour, or do you establish trust levels & boundaries with checks and balances?” Ongoing verification however is critical in identifying the actions and impact of bad actors on secure information access. This is no different from getting to know more about the crowd that your children may hang out with to identify any potentially bad influencers.

So how do we structure a trust model that incorporates the good aspects of zero trust? How can we maximize collaboration and dynamically enable access anytime, anywhere, all with a basis of established levels of lasting trust?

One such model defines trust across four access layers that typically are associated with distinct IT disciplines:

  • Identity & information
  • Applications
  • Infrastructure
  • Network

Looking at that model, the overall objective for secure access is to allow the users (or IoT devices) to securely create, store and retrieve information.  In our trust model, this means relying on client-side services and applications that connect to their corresponding cloud and enterprise applications. In turn, this also means relying on client devices connecting to cloud and datacenter infrastructure through wired and wireless connectivity across and into public and corporate networks. Secure access then translates this into “information access based on trust across and between the access layers.

Some use cases rely on implicit trust, whereas others require explicit trust relationships.  For example, a user who logs into a legacy corporate computer that is connected to the corporate LAN used to be implicitly trusted to access most internal applications (email, intranet, et al). In today’s environment, a user may need to authenticate with a mobile application that was installed and secured by an endpoint management solution that uses a trusted device for enabling corporate, Wi-Fi connections to access the enterprise application behind the firewall. A user or device profile would determine which part and what information of the application would be accessible (i.e., trusted to be accessed).

What becomes clear is that key attributes of the trust will have to last beyond the duration of a single secure access event. Rather than a pure “never trust” approach, we must instead provide an orchestration solution whereby the various trust relationships between and across the layers are carried forward, distributed and orchestrated across the access fabric.

In our next post we will look at how we can manage trust in a Secure Access Fabric that is based on both Pulse Secure and third-party solutions.