Zero Trust Is Table Stakes, Zero Knowledge Is the Next Evolution

First and foremost, zero knowledge. The next evolution of Zero Trust. So I'll take one step back and talk about zero trust first, because it is, it is a good security practice. It is something that we want to ensure is followed within the industry, and there's some really, really strong benefits to it.

First off, right? When it comes to zero trust, you have the, the concept of you can't have your old defense mechanism, which, which was really close to like a medieval castle where you'd have all your villagers inside and you'd have a wall on the outside and you'd have a moat on the outside of the wall, and everything would be protected from that wall. What we've found now is that there are too many other avenues of attack.

Once that outside wall, once your firewalls are breached, you have insider threat, you have lateral movement, you have a shadow it allowing for additional components and methods of access. So the, the traditional method of, you know, protect the outside just doesn't work anymore. So you have to assume that there's a breach right in, in any access scenario, in any trust scenario, you have to assume that there could be a bad actor in your environment. And how are you gonna do with that?

When an assertion comes in, when somebody says, Hey, I am this person, or I am this device, or I am this api, web service, verify validated. Don't just trust that it's coming from an internal ip, therefore it should be good. Ensure that there is some type of an access token. And then of course, the, the core component of zero trust is ensure the least privileged access, right? In this case, what we do is, it's something that's been in the security industry for many, many years.

Back in the day, it used to be called mandatory access control, used to be called principle of least privilege, and now it's got a better name. Hey, zero trust. The concept is good. If you don't need something, don't get it. If you do need something, only get it for the period of time that you do need it. And if you do need it all the time, make sure that you verify who you are and that you do have access all the time.

So the, the benefits of implementing zero Trust are really, really numerous, right? You, you can ensure that you have less potential attacks from lateral movement or a compromised account, or just in general reduction of your attack surface, which lowers the ability for some, some asset or something in your environment that gets compromised to laterally move to escalates privilege to get somewhere else. So from the zero trust perspective, right?

There's, there's some really strong benefits that make a lot of sense. Even certain compliance frameworks are starting to get updated to require principles of least privilege to be implemented. So many of the older compliance frameworks always had some of the basics around understand who has access. Some of them are evolving now to go more along the lines of continually verify who has access, remove access from people that don't have it, et cetera.

So, really good, zero trust, great way to go fully support that. When it comes to deploying it within your organization, just realize that the, the identity the person is really at the foundation of zero Trust, you're trying to understand is, is this person, is this workload, Is the identity of this object who they say they are? And then if that is the case, provide them appropriate gaps or provide them appropriate access. When it comes to the assertion of identity, you need to be really careful about that.

You know, generally a password as the only validation to protect an identity is not a great idea. You want something else behind that Could be as simple as email verification. Could be geolocation, could be, you know, hardware tokens, could be security code multifactor.

There, there's a hundred different ways to ensure that you have good assertions of identity and a good understanding of is this person or workflow or object who they say they are. And then unfortunately, this is a, it's a policy component. In addition to a technology component, you need to have the, the rigor around understanding who has access to something periodically. If that's every three months, if it's six months, if it's once a year, that's fine. Just periodically go through the access lists and make sure that the people who have access still need it.

The the zero trust component is it's very easy to forget the cleanup and follow up after the fact. Luckily, some compliance frameworks like SOX compliance require quarterly checks to do this. Others do not, depending on your locations, geography or what compliance frameworks apply to you, but the controls around should you have access is definitely one component. But continually monitoring is definitely something that you wanna look into. So that's zero trust, it's really good, fully supported, go down that path.

Zero knowledge is an interesting evolution that that takes the foundations of zero trust and builds upon them, especially for vendors, cloud providers or solutions that are deployed either in a hybrid environment or entirely in the cloud. So first, there's a lot of confusion around zero knowledge. So I'm gonna set aside some of the other components aside from zero knowledge.

First, a zero knowledge proof. This doesn't mean it's vendor supplied. This is in, it's a function of encryption. It's basically a way for somebody who has secret data to prove to some verifier that I know this secret data. But the important part here is that no part of that secret data is exposed.

So, you know, if I guess the number between one and a hundred, I can prove that, I guess the correct number without telling you what the number is, There's cryptographic ways to secure that, and it's typically embedded within any type of public key infrastructure. And modern encryption relies on the zero knowledge proofs is really good, but this is not zero knowledge at the organizational level. This is encryption and proven data.

Again, going past that, implementations of zero knowledge encryption are also not entirely zero knowledge for an organization, for a business, but it's much, much closer. And you find some of these terms show up in, in products and solutions in, you know, best practices and guidelines, which is things like end-to-end encryption, right? Do we care about end encryption? Why is that what's important with it?

And in this component, the this is much, much closer to an ideal zero knowledge situation where if a, if a person or a business has some secure data that they need to maintain and it gets sent to the cloud for storage, maybe using Salesforce, maybe using Google Drive, maybe using whatever product. In an ideal world, the data that you upload to the cloud should never be decryptable. It should not be able to be red or viewed or processed by whichever cloud vendor you sent it to from, from the end to end side with zero knowledge encryption. That's the case.

Ciphertext is created on the endpoint, it is sent to the cloud. It is never decrypted in the cloud. And the only time any, any type of decryption occurs is when it's back to another client or the same client if you need it, like whomever is using it. The advantages here are if the cloud vendor were to get compromised, similar to the Solar Winds hack, or maybe you have a malicious insider, kind of some of the things that Uber ran into recently, you have some amount of protection against those types of attacks.

If somebody in the vendor's location does either get compromised or becomes malicious, they still can't extract your data, they can't pull it out, they can't do anything with it. And that is really a great foundational component for zero knowledge. And so this is where it really comes into understand how zero knowledge vendors work, right?

You've got your end to end encryption, you have client side uploads, so the, whatever data you have, if it's a file attachment and Excel document that is encrypted locally, the encryption keys are generated locally, Nothing is generated and controlled by the cloud or the vendor. That way they, they can't create a perfect environment where they know the encryption key that's getting generated, it's outside of their draw.

Some things you'll realize when it comes to understanding if there is zero knowledge is you won't be able to do things like antivirus scanning of files or machine learning and behavioral detection of the, the data and searching for like personal information and addresses in the data. Because that means the vendor has access to the data, they can process it, and if they were malicious, they could extract it. So this is a good way to understand if a vendor does support this, and just like I mentioned, the administrators and engineers within the vendor don't have any access to the data.

They can't get it. But that can also be extended to the product. So if you have a cloud deployed product that is cloud managed by default, does the administrator in your organization, maybe you use 'em, I don't know, CrowdStrike or Rapid seven or something, does the administrator in your organization have access to every single credential, every single finding, every single bit of data that's found? The ideal scenario is no, even an administrator doesn't get access to the data unless they need it. And that's fairly common, right?

An admin is somebody who's going to set up the environment, configure it, deploy it, they're usually not as intimately aware of or have a need for all the data. Now, day to day practitioners, yes, if you log into the solution and you manage vulnerabilities all day long, you have to have access to the data. But ideally that is decrypted client side and can be accessed. The benefits of zero knowledge are very similar to the benefits of zero trust. They go a little, they go further, such as minimizing the attack service. In an example, if for a keeper as an example, right?

If we get a request from the government that says, Hey, we think that person XYZ has done some suspicious activity, please send me their data. Our answer becomes no, we, we don't have the data, we can't decrypt the data and we can't send it to you even if you believe that this person has done something you disagree with. So it's further mitigation of the attack surface, further risk reduction, and it's data privacy in the hands of the people that own the data as opposed to administrators of the data vendor compromise insider threat.

Those are more and more popular nowadays as defenses occur in other parts of the infrastructure. Attackers typically find, you know, who's the weakest point to attack and sometimes the, you know, bribing an employee becomes a little easier than trying to find a zero day on a firewall. So that is the quick overview. I tried to blow through this as quickly as possible to stay close to my time, but I did want to provide any time for questions that the audience may have on the topics of zero knowledge or zero trust. Thank you.

Zane, are there any questions from the audience? No questions.

There's, there's one question online and the user is asking what is advantage over classical B Y O K H Y O K? Not sure what this user is referring to, but, So this may, I'm guessing here, but this may relate to bringing your own key, like bringing your own encryption key.

And there's the, as long as the encryption keys are derived client side, as long as the, the, the secret to decrypt the data is generated outside of the vendor's environment, outside of the administrators environment, which they could potentially have control over, that is sufficient for a proper zero knowledge implementation. Okay. Thank you. Are there any other questions from the audience?

No, all thank you San Alrighty. Thank you so much.