I recently shared my operational transformation journey over six years as the CISO of a global law firm at a CISO Summit in New York City. I did so in the context of the Seven Elements of Highly Successful Zero Trust Architecture, a book recently developed by a triumvirate of brilliant colleagues. My goal was to convey how several information security and technology projects I was involved in over the past few years were stitching the fabric for the zero trust initiatives many of us have strategically embarked on today.
I didn’t even know what zero trust was back in 2015. As I was preparing to simplify the zero trust reference architecture for my presentation to CISOs, I reflected upon the intense brainstorming and cloud-first enterprise architecture we devised to enable strategic business goals while attempting to shape the path of future risks. In hindsight, I believe we got many things right, but there were also some oversights because we didn’t have complete comprehension of the controls required for cloud adoption, mobility, consumerization, and emerging regulatory requirements.
Zero trust reference architecture depicts the three categories and seven elements represented across multiple standards and guidance
Where I believe we were ahead of the game, particularly in the legal vertical, was the development of an internal access management paradigm focused on granular, least-privileged access. Not surprisingly, we adopted this model from what we were doing circa 2015 with our web content filtering or secure web gateway (SWG) solution. This was the first solution integrated into our identity provider (IdP), and we were able to leverage the same user identities, attributes, and security groups for on-premise access control in a cloud-delivered application for a global enterprise. We were architecting this simple discretionary access control model to be predicated on calculating the trust for the source (we called this the “entity”) and destination to dictate the level of access. We understood why this was inherently easy and seamless in enforcing granular least privileged access and acceptable use in the SWG context, but struggled with complexities and nuanced challenges in other access enforcement initiatives, mainly with on-premise or private applications.
Least privilege access model for private and cloud applications (2015)
That all changed as we added inputs to the entity and, mostly, the destination trust calculation. Our entity or source calculation was based on user identity, device, and physical location. We calculated destination trust with application identity, data classification, and data location. Initially, content categorization services leveraged by our SWG handled data classification for internet destinations but its capabilities grew over the years to include dynamic content categorization through SaaS-delivery, crowdsourcing and AI/ML models, and the eventual cloud access security broker (CASB) application taxonomies that were growing in popularity. That’s it. Vendors took the data classification responsibility from the enterprise, gave us the flexibility to modify as necessary, and automated an otherwise near-impossible process that some organizations still haven’t mastered after decades of attempting to do so with private or internal data and applications.
Once we had the source and destination trust calculations, we could add the access authorizations to the model, which were: Allow, Deny (we used “Protect” to build user trust) or Allow with mitigation or limitations. The Allow with limitations or mitigations was spawned from cautionary filtering policies. We weren’t denying access, but rather heightening user vigilance or potentially restricting malicious code through a warning or a physical acknowledgment. This was the initial authorization we could identify with the Allow with limitations or mitigation level of access.
As technology modernized, this was greatly expanded through what was known as Web 2.0 and what the industry eventually called Shadow IT (eventually mitigated by CASB). Inline contextual CASB controls allowed us to enforce Allowed access with limitations or mitigations that were easy to test, review for potential impact, approve, and enforce. At the time, lawyers were using their business devices for personal matters, occasionally against the rigid guardrails of antiquated device controls, and at the brink of outdated acceptable use policies. They would confess, “I’m a self-admitted Luddite, but the security and monitoring on firm devices make me feel safer than using a personal laptop.” We had others who would routinely leave their business device in the backseat of a rideshare or repeatedly spill diet soda on the keyboard. We limited reasonable personal use and for equity partners of an LLP, “IT can provide me a new device” was the common mantra for firm-issued devices. The problem was obvious. The solution was coming of age.
I recall fondly how well-received information security and technology teams were looked upon when, after years of outright restricting access to personal webmail on business devices and the network, I announced we would be extending reasonable personal use of business devices by allowing access to personal email with limitations. The technology space had caught up with the “Allow access with limitations” authorization that involved a short proof of value and an official change request presented to our Control Board. Recreating that policy in 2015 was a great start.
Contextual CASB policy for allowing access to personal webmail with limitations
This capability allowed us to reduce data loss risk by restricting the ability to attach files from the business device or network. Yet people were still able to communicate with their families and manage events in their personal lives without hauling around a personal laptop or tablet all the time.
Another extension of reasonable personal use that was incredibly popular amongst firm personnel was streaming media. We initially denied streaming media services such as Netflix, Hulu, and Sling due to bandwidth constraints and productivity loss concerns – operational and human resource risks. I had to take the brunt of frustrated partners before I saw the opportunity, but these two direct comments take me firmly back to that time.
“Because of you…I need to travel with both a business device and a personal device because I can’t watch Hulu in my hotel room.”
“You are doing a great job with recreating an MP3 player market in 2016. Who can’t listen to Spotify on a work device?”
After speaking with the chief human resources officer and general counsel, we concluded the operational risk of business bandwidth saturation and the productivity loss risks of people shirking responsibilities were the original justifications for restricting streaming media. Fast forward to that moment, and we now could ascertain user identity, device, and physical location of every user's internet transaction. The policy was as simple to validate and approve as it was for personal webmail.
Contextual CASB policy allowing streaming services when a user was not in the office or connected to our remote access gateway
I was now in a position where I could strategically look for the next extension of reasonable personal use. This time I didn’t need to get punched in the face by an equity partner, but anticipated an inevitable ask given our business. As a white-shoe, high-stakes litigation firm, it would not be uncommon to have a trial team in one of our global offices burning the midnight oil preparing for a next-day discovery or deposition. The primary concerns are static – bandwidth saturation and productivity loss on the business network and in the office. When you take people out of the office, that risk is greatly reduced. Setting up temporary access policies was nothing new at this time, but I did wonder about aligning with acceptable use in perpetuity.
Restricting streaming media based on location (firm offices) and time interval (business hours, M-F)
Next, I added persistent time intervals to the policy criteria. I did not even change the level of access in our original acceptable use policy (deny). I changed the scope of the restriction to when a user was in a firm office between 8 a.m. – 5 p.m., Monday – Friday, in any of our 15 global offices. The time interval was based upon what time the transaction was received by what is now known as a public service edge, which addressed a risk that a crafty user could circumvent this time interval by modifying their device system clock. Before or after that time interval in a firm office, the services were available. I figured this out shortly before March Madness in 2016. An associate called me directly earlier in the day with the exception request for his trial team in our Phoenix office. All I said was, “Enjoy the game and go Wildcats.”
It felt good to build trust throughout the organization by chipping away at a relic of security policy mostly predicated on forcing compliance. Changes like these to internet access and acceptable use policies meant people didn’t feel like they were being policed into compliant behavior. Instead, they understood they had a stake in protecting their business devices, which were increasingly intertwined with their personal lives. I don’t have the metrics to prove it, but I know the number of business devices lost or stolen (and cats being blamed for spilling Chai Macchiatos on keyboards) dropped exponentially as we modernized our business architecture and extended reasonable personal use scenarios.
Why bring all this up? Getting there.
For the next few years, I didn’t rack up many innovative application access anecdotes outside of more “Access with limitations or mitigation” examples. We had decided to move away from focusing on access in and around the network layer, so network access control solutions didn’t meet our emerging legal business usage models and cloud adoption. Sure, these would have provided the requisite temporary control for various projects. It would have been akin to Halloween candy – immediate sustenance but no long-term health benefit to business velocity or risk reduction.
The power of hindsight is welcome at this moment since we didn’t know we were heading into a future with a global pandemic when these capabilities would have come in handy. I want to shout out to all the functional leaders from that time who deserve credit for their multidimensional and diverse perspectives on firm strategy and innovation. This ultimately saved a tremendous amount of careless expenditure, unnecessary costs, and inefficient controls.
What frustrated me, from roughly 2017 to 2019, is that the ideation was there but the technology was too complex and manual, due to a lack of partnerships, underdeveloped integrations, and a narrow focus on winning industry competitiveness. It still didn’t deliver a ubiquitous user experience to the point where we had the control to minimize friction from these new solutions. Specifically, solutions lacked remote browser isolation (RBI), software-defined perimeters (SDPs), inline behavioral threat prevention, cloud workload, and posture protection to name a few. With a bit more R&D here, an integration there, and some further configuration flexibility, these solutions would have fit into our cyber-service mesh and started delivering immediate value. I was always especially bullish about browser isolation because I saw the impact it would have once the user experience was streamlined, and its commoditization would help make it more affordable.
Looking back, I think we did what we could with the policy enforcement tools available to us. In part 2 of my story, I’ll delve into some of the modern policy enforcement options made possible by the zero trust framework and how they can be used to even greater effectiveness. Stay tuned.
What to read next