… and continuous authorization is only possible with real-time device trust and a means to instantly revoke access.
Let’s face it, most professionals in enterprise security would agree that when it comes to secure remote access, Zero Trust is the right strategy for our modern workstyles and modern corporate infrastructures. With the vast majority of both our workers and our resources living outside of the now outdated corporate perimeter, it’s no wonder that there is so much consensus that we must find a new way forward if we intend to support the productivity of our vastly remote workforce while effectively protecting the sensitive resources that support that productivity. The experts have all spoken – Zero Trust is the answer.
Great! Sign me up for some Zero Trust.
But I’m like you, and I do my research to learn just what that means so I can implement the best Zero Trust around. What I learned is that Zero Trust is basically the idea that we should not assume or imply trust as part of any access request based only on history or anything we think we already know about the requestor. We used to assume that our corporate networks were trusted, so anyone able to join that network was also assumed to be trustworthy – the same goes for our VPNs. The corporate laptop we issued with the carefully crafted image was secure when we issued it, so any activities on that device should also be trusted. You get the point – for many years we have relied on historical beliefs and insufficient validation to grant broad access to our sensitive stuff.
With Zero Trust, we take each request for an app, system, or resource as a separate transaction that starts with zero implied trust. This solves multiple issues. It addresses the too-broad access by requiring new authorization for each resource requested, each time, effectively shutting off lateral movement within an environment or network. It also ensures that in case anything bad has happened since the last successful access, we have the opportunity to deny that new request. Maybe credentials have been stolen and the requester isn’t really who they say they are. Maybe their device has been compromised by malware and it would no longer be safe to allow that device to be used for sensitive activities. This sounds pretty good, but have we truly addressed the trust problem?
It occurred to me that bad things can (and do) happen at any time. When I’m out and about, I often move from one Wi-Fi to another and not all are safe. I sometimes discover a cool new app to install. I check my email and browse the internet and click on things while I’m working. All of these are activities that anyone in the security business will tell you are potentially risky, and any one or more of them could add risk to me as a consumer of corporate material. Then I asked myself how often I authenticate into the many systems I rely on to do my work. For many of them, it’s only once a day.
That’s when I realized that one-and-done authorization violates the very principle of Zero Trust everyone now believes in. In the same way that one authentication into the castle perimeter exposed far too much to every user, one authentication into an app then leaves that app exposed and potentially vulnerable for the entire duration of the requester’s access. Trust established at a single point in time does not guarantee enduring trustworthiness.
The logical conclusion is that in order for a Zero Trust solution to be effective in its execution, it not only must establish trust at the beginning of each request, it must continuously verify that the request remains trustworthy throughout the entirety of the transaction. Only then will we have truly lived up to the Zero Trust principle.
So, what would such a solution look like and how would it work? In order for continuous authorization to work in practice, two things are required:
- Continuous Quantified Trust – Constant, thorough analysis of the trustworthiness of the user and their device.
- Instant Access Control – The ability to instantly revoke access if trustworthiness falls, and instantly re-grant access if trustworthiness rises sufficiently.
These are clearly more than mere features of a Zero Trust solution – they rely on an architecture that supports broad integrations and the ability to respond in real time. Let’s take a look at each of these in more detail.
Continuous Quantified Trust
When I think of trustworthiness, it occurs to me that in no situation is trust truly a binary decision. A person gradually earns trust with their peers over time, earning greater amounts of trust as there are more data points that support trusting that person. In the IT world, users also establish various levels of trust through multiple points of verification. For example, entering the correct credentials may set one on the path toward trustworthiness, but most IT security experts agree that that level of trust is simply too low. So, we add additional factors (MFA anyone?) to attempt to elevate the trustworthiness until we are satisfied that the trust is high enough to grant access.
If we were to add a bit of rigor to this process, we could say that we are calculating a Trust Score. We could even decide that a minimum score is required prior to granting access to certain resources. Let’s say that we agree that a higher trust score would be required to access the company’s financial records than would be required to access the corporate cafeteria menu. Just because we don’t trust someone with our most sensitive records, doesn’t mean we need to starve them. Trust is not binary.
Clearly, we want to be thorough in our measurement of trust for sensitive material, and that means verifying that the user is truly who they say they are and the device they are using is authorized and proven to be low risk. Fortunately, most organizations have already implemented a variety of solutions to help with this, and we simply need to tap into those sources so they can all contribute to this calculation of a Trust Score. For most organizations, these tools generally operate in silos, at the most sharing information with a SIEM system. Wouldn’t it be great if we could leverage all of these user and device security tools as data points in a trustworthiness calculation? If we were really clever, we would also figure out additional indicators, like evaluating for recognized patterns of behavior and other circumstantial evidence of trustworthiness.
Zero Trust solutions typically leverage an identity solution as the starting point, but often don’t go any farther. I think it is important to not only identify the person, but also verify that their behavior, location, time and frequency of access, and many other factors are taken into account as well. Next, just like identity, even the Zero Trust solutions that mention Device Trust simply don’t take it far enough with real-time integrations with solutions that are already functioning in most organizations. To establish the best measure of trust, we have the opportunity, and even the obligation, to evaluate not simply the measurable attributes of identity and device, but also the activity, behaviors and transitory characteristics of both. The graphic below shows sample solution categories that may contribute to the Trust Score. Additional logic, including artificial intelligence could further enhance the accuracy of the Trust Score.
So, the first of the two requirements is this ability to collect and continuously evaluate all of the best telemetry from the available solutions in the organization, in real time. That way, we will know the instant something bad happens by observing a reduction in the trust score. Now, if we could only take appropriate action based on that score. That is where the Instant Access Control piece comes into play.
Instant Access Control
Zero Trust solutions already have the ability to mask corporate resources and only grant access once trust has been established, whatever ‘trust’ may mean for each solution. Having the ability to revoke that access at a moment’s notice is another thing entirely. There must be a continuous connection with the Trust Score engine and the policy engine, and this access control tier has to be able to reestablish that cloaked state the instant the trust score falls below the threshold for that resource.
This is clearly the simpler element in the equation relative to the Trust Score. However, there can be some intelligence built in that takes into account the score required for the particular resource being masked. If a reverse proxy is used for this purpose, it can also serve to add additional functions like load balancing and DoS protection. If cryptography is used in the form of a ‘trust token’, then additional characteristics and variables may be embedded to add more intelligence to the decision making, and may even be able to store state in the case of a partial system failure.
Visibility and Self Remediation
One of the biggest complaints I often hear about secure remote access is how much IT resource can be consumed just in support tickets, whether it be users unable to gain access, or they’ve lost access and want it back, or they need access to something they didn’t previously have access to. It occurs to me that this Trust Score could be incredibly useful in reducing that IT burden, if we simply make the score visible to the end user.
Let’s say that we make the score visible on the end-user’s device and include a list of the primary factors that are considered in calculating that score, for example whether the device is running a recent version of the operating system, is using disk encryption, has the required anti-virus programs running, etc., etc. If that user should lose access to a resource they had been using, they would be able to easily see that their score went down and identify which factor or factors are contributing to that decline. In many cases, since it is likely due to something the user just did, like joining an insecure Wi-Fi, or installing malware, they would be able to take corrective action, like disconnecting from the bad Wi-Fi or removing the app.
The same system that detected the reduced Trust Score and revoked access would just as quickly detect that the Trust Score went back up and could reinstate access without any demand from an already overburdened IT department. Users can be in charge of their own security at that point and are now able to remain productive more often, all on their own. In fact, the users may end up better educated on risky behaviors and act in a more secure manner in the future. That’s a win for everybody.
Zero Trust is just a concept, not a product. But it is the right way to think about security in the modern world of flexible workstyles and crumbling perimeters. Based on my studies, if we are to truly benefit from what Zero Trust has to teach us, the principles must be applied thoroughly and continuously. Otherwise, we may be fooling ourselves that our sensitive corporate resources are well protected, when in fact we’ve only secured them for a single moment in time.
As you evaluate Zero Trust solutions to provide secure access for all of your remote workers, be sure the architecture supports broad integrations with all of your identity and endpoint security products. Be sure as many attributes and activities as possible are measured to establish a sufficiently high degree of trustworthiness. And, finally, be sure that the solution has Continuous Authorization, because bad things can happen at any time.
This blog originally posted here – https://banyansecurity.io/blog/zero-trust-is-incomplete-without-continuous-authorization