Managing Access@Risk: Is Zero Trust a Must? New Approaches to Secure Business Enablement

Back in my days as an industry analyst, I was able to meet the identity management and security teams at Nordstrom—very delightful people, just by the way. When the manager of the security team took his turn to introduce himself, he politely gave his name and then said, “I put the 'No' in Nordstrom." That was such a great line! It made me think more companies should incorporate "No" into their names.

It’s of course the role of the security team to say “No” to a great many things, but it’s also the role of the business team to say a lot of "Yes"-es. That’s because there’s an important balance between productivity—which is the whole reason for the network to exist—and security.

That said, in my view, the term “Zero Trust” is problematic—both for semantic and technical reasons. Foremost, Zero Trust, if truly achieved, seems as though it would result in Zero Work. Also, the term “trust” (at least in a security context) often refers to cryptographic trust, through PKI and other techniques—so, it feels like saying “we’ll have none of this trust business!” And of course, interpersonal trust is something we’d really like to promote, rather than fostering an environment of pure paranoia all of the time. So, Zero Trust conjures up a lot of confusion and even some blatant inaccuracies.

Of course, Zero Trust is a turn-of-phrase from the former “trust, but verify” mantra, which applied to a vastly different network topology in the pre-internet era. As a philosophy, the core tenets of Zero Trust make a lot of sense. In an article on this subject, the individual who coined (or turned?) this phrase, John Kindervag, explained: 

Zero trust should be thought of as a strategy or framework. It requires companies to rethink their philosophy and approach to trusted network users and devices.

As a way of approaching security, Zero Trust is a powerful rubric.

As a practical matter, though, many problems arise when pursuing a Zero Trust strategy, stemming mainly from the fact that cloud systems aren’t very integrated or particularly integrate-able. Is it really possible to re-check security at each query to a database, as some have suggested? Is continuous verification sufficient for establishing Zero Trust? Or are managing identities and requiring MFA going to meet the goals of Zero Trust? 

We all agree that Zero Trust isn’t a product, but so many software and consulting companies attempt to offer it at least a solution. Unfortunately, the industry’s ability to create a “right-sizing access” product has a terrible track record. Many great minds have worked to solve access issues and many great products, standards, and practices have emerged—but with each solving only a handful of access problems. What does that say about the nature of the problem? It says the problem defies a business model. For clarity on that point, let’s review a few of the popular notions on how to actually constrain access:

• Provisioning products rely on approval & recertification workflows, which often generate a lot more work with little security benefit. These products were built to satisfy regulatory requirements for user access reviews and so are meant to establish responsibility, not security.
• Role-based Access Control (RBAC) approaches lead to a sprawl in arcane roles that are difficult to implement and leave holes for non-human access. (If anyone reading this has implemented RBAC successfully, please reach out to me).
• Attribute-based Access Control (ABAC) features require robust input data and often don’t support control over certain services. In practice, it’s hard to source this data consistently, when you can even find it.
• Authorization engines require connected applications to support their proprietary APIs to talk to it. And of course, there are so many of them to talk to. Who’s in charge? It’s like saying, “if only everyone—literally everyone—would just listen to me!” This is the same sort of centralized thinking that plagued X.509, because everyone wanted to be the Root CA.
• Custom solutions, whether built in house or through contracted projects, these types of solutions are scoped, inflexible, and difficult to maintain.

The Trustle approach: manage access at risk

At Trustle, we've taken a different approach. Borrowing from work done in financial markets around managing assets at risk, we've turned that phrase to managing access at risk (although it seems more modern to write it as "Access@Risk," so I'll probably do that more often). The difference is that the goal is to recognize your risk exposure and take the necessary measures to de-risk the situation.

Some of the solutions to de-risking access come from using a blend of pragmatic and programmatic techniques to secure cloud systems. For example, in support of audit and regulatory requirements, Trustle provides approval workflows and documents a digital trail of responsibility. For ongoing access activities, Trustle uses a combination approval status, risk score, duration, and policy to determine the appropriate action. In either case (approval workflow or automation), Trustle makes actual changes to the connected systems, by updating a group, a role, a policy, an attribute, or whatever the appropriate action is at the target system. Of course, all of this activity is available as a history for certification and audit.

With this approach, AWS doesn’t need to suddenly run on Azure AD or Google IAM; there’s also not an avalanche of “rubber-stamping” approvals introduced by provisioning products; there’s no wondering whether the IdP got the attribute just right—or that the IdP is even aware of the account (such as with contractor and service accounts). Our aim is simply to do the unavoidable heavy lifting that comes with access management, while taking that burden off your shoulders.