Zero Trust: Pragmatic policy enforcement - Part 2

In part 1 of my story of experimentation with policy enforcement, I talked about my time as a CISO of a global law firm and past successes and frustrations with the practice.

Back to the present day, I’m reviewing the Seven Elements of Highly Successful Zero Trust Architecture, and I became fixated on the third and final category Enforce - Policy Per-Session Decision and Enforcement and its lone, seventh element – Enforce Policy. As I was digesting this reference architecture and its alignment with other standards and guidance I have read, I recalled my previous role as a catalyst for digital transformation and cloud adoption. It struck me just how much of what we did was laying the foundation for emerging security models such as security service edge (SSE) and zero trust architecture (ZTA). The decisions we made seven years prior provided us with a highly dynamic and flexible architecture, giving us ubiquitous security across a global business arena that continuously allowed:

• quicker adoption of new devices; 
• technology trend and risk exploration; 
• newer usage models; 
• broader third-party user and unmanaged device access; 
• systems of differentiation/innovation – consistent outcomes with continuous reduction of risk;
• automated threat prevention through cloud delivery and partner integrations; and
• the strongest form of control and at the lowest cost. 

But that isn’t what I was focused on now. It was that simple, granular least-privilege access control model based on the tools and systems we used at the time and ultimately modeled after the experience provided by our SWG: Zscaler Internet Access (ZIA). More specifically, I fixated on our policy action of Allow with Limitations or Mitigation. Looking at how modern zero trust architecture performs global policy enforcement for users, devices, workloads, and IoT/OT devices suggested that the technology space had caught up with the theory. My entire presentation turned into a series of anecdotes where not only the Conditional Allow policy actions would have been impactful, but also the additional protection provided by Conditional Block policy actions. 

Access policy is enforced on several conditional Allow or Deny actions

 

Warn: Alert users of potential risk, policy violation

A cautionary policy or warn action relied on the same reasoning behind my idea to Allow with Limitations or Mitigation. There are mixed opinions about this form of conditional allow action, but I have always had tremendous success employing it. That is partly because I don’t overuse it, and I solicit feedback from the business and update based on the threatscape and active campaigns. For example, with uncategorized traffic treatment, we couldn’t globally restrict this traffic because of the volume of legitimate destinations and the burden of exception handling. A cautionary policy provided a good measure to take more control over this traffic without the friction that would be introduced by a deny policy. 

Warn or caution is what I call a “roundabout control.” I live in the Washington D.C. metro area, where L’Enfant architected the original downtown street system with several European city circles in mind. Today, D.C. counts almost 40 city circles or roundabouts within its borders. Behind a wheel, it might not seem like it, but a roundabout typically leads to more efficient traffic flow than a four-way intersection with stop signs, since no one is coming to a complete halt. The roundabout also heightens drivers’ situational awareness as they proceed without stopping when the way is clear. This helps shape user behavior by making them aware of the risks, yet empowering them to decide whether or not to proceed. Similarly, a cautionary control reduces risk without compromising user productivity or customer service when the necessary exceptions are accounted for. 

Warn Policy Action – heightens user vigilance and can be refreshed based on the current threat landscape, fraud campaigns, etc. 

 

Prioritize/Deprioritize: Salesforce gets priority over YouTube when the last mile is congested

While not the concern it once was given direct-to-internet and local internet breakouts, application-based traffic shaping or bandwidth control can still be an important conditional allowance policy. It helps optimize customer service or user experience agreements and performance. I can also see several business use cases to support service continuity or resilience if an organization faces pandemic-like disruption. 

Isolate: Stream pixels to the browser, restricting the ability to download, copy, and paste data

Isolation is a multi-faceted capability, making it intriguing for conditional allowance actions. Isolation provides the capability to distance users from potentially harmful content on the internet. It can be effective for allowing access to potentially risky content that can’t be outright blocked. It will also play an important role in modernizing predictive controls through smart isolation by leveraging AI/ML models for threat protection. Isolation is an ideal solution for uncategorized traffic treatment. It can also be used to access personal webmail in an organization that doesn't otherwise have the necessary controls to minimize risk by other means.  

Isolation can also allow controlled access to critical applications by third parties or on unmanaged devices where, previously, organizations were forced to restrict totally based on their risk tolerance. Isolation has flexible control options depending on what type of isolation profile is required, whether that be internet content protection or unmanaged device access to corporate applications. 

Isolation security control options

Steer: Optimal and pre-defined path selection 

Steering is a mechanism for sending traffic to non-standard destinations. This could be for leveraging an anchored IP address for geo-specific solutions or sending traffic through a more effective path. There are still many services that use IP-source security as an access requirement. Given that users can connect from anywhere, there could be a need to route specific-application requests through an IP gateway where the ability to steer traffic becomes a necessity; even with the prevalence of IP spoofing and route hijacking, some organizations still use this form of control. 

 

 

Traffic steering to use source IP anchoring

Quarantine: Ensure access is limited and protected 

Most of the cyber threats we defend against originate from the internet. Some organizations address this risk with highly restrictive policies that limit file downloads from the internet. The challenge with this is that it actually creates more risk. Users still manage to get the files they need, but without any visibility or controls over the activity. The only other option is to adhere to IT's draconian approach. This option can create systematic business risk where production, innovation, and ideation were stymied, in some cases leading to a slower time to market or loss of market leadership.  

Malicious actors continuously react to new defenses, including constantly innovating tactics and techniques with malware dissemination. Initial compromise for establishing a beachhead can start with a seemingly benign file lacking a malicious payload. The ability to perform inline behavioral analysis on suspicious file downloads is imperative since cloud adoption and mobility continue to accelerate. Aside from being able to perform in-depth, real-time dynamic analysis on unknown files, the capability must provide the flexibility to select different actions based upon risk, including quarantining specific file types from specific internet sources and only releasing them once the file has been detonated in an isolated environment. Balancing security with business velocity and employee productivity is essential for this solution to be effective.

Flexible behavioral file analysis actions are driven by organizational risk tolerance

Enforcement within a zero trust architecture is not simply limited to the two options of “conditional allow” or “conditional block.” Its controls are at the application layer, not at the network layer as with legacy network control solutions. Zero trust is implemented as a proxy for all applications and thus allows for policy control at a very granular level.

The Zscaler Zero Trust Exchange allows for multiple enforcement controls to be applied in policy, not simply a binary decision of allow or block. This multilayered policy enforcement delivers powerful controls for enterprise protection and decisions. Enterprises can build various levels of policy enforcement based on the outcomes of the previous six elements. These policies should enforce business outcomes, exercise risk mitigation, and advance security posture. Today technology can deliver the security and operational experience outcomes that make what I once termed Allow with Limitations or Mitigation a viable policy enforcement decision.

What to read next

Zero trust element #7: Enforce policy

Of exploits and experts: On the professionalization of cybercrime