Zero-Trust Security

Overview

Zero-Trust Security is a very misleading term as it exists today. Below are the core principles as they exist today:

• Never Trust, Always Verify: No user or device should be automatically trusted, regardless of whether they are inside or outside the network perimeter. Each request for access needs to be treated as potentially hostile and must be authenticated and authorized. Additional verification is required when requests pass through security and network boundaries.
• Least Privilege Access: Users should be given the minimum permissions to accomplish their tasks. This limits the potential damage that can be done if an account is compromised.
• Encryption and Secure Access: Data should be encrypted both in transit and at rest. Secure access involves the implementation of authentication and authorization.
• Continuous Monitoring and Security Auditing: Continuous monitoring involves realtime alerting of potential security threats. Security auditing is a regular review of security measures and policies.
• Multi-Factor Authentication (MFA): MFA adds additional layers to the authentication process, rather than solely relying on a password.

Nuance

The above principles are great for increasing security. However, it’s funny that Zero-Trust Security does not require zero trust. It’s possible to create an architecture where at least one internal individual needs to be trusted and still call it Zero-Trust. For example, if we have an app where our customers have passwords, and we store this password as an encrypted string in a database alongside our servers, we may need to store a private key somewhere in the Back-End to access those passwords. We could store it in a Back-End datastore and create peer-review and alerting mechanisms for access. This would be considered Zero-Trust because although certain individuals are allowed access to the private key, this trust is not implicit or unconditional.

True Zero-Trust

True Zero-Trust Security involves Zero-Knowledge Proof. This is a concept where a password never leaves the end-user’s device. Instead, a proof is created from the password on the end-user’s device and sent to the Back-End to be verified by the Verifier. Mechanisms exist to prevent using this proof more than once.

User Data

In the case of user data that needs to be stored in datacenters (such as terabytes of emails), this can be stored encrypted and sent to the user encrypted in order to be decrypted on the client side with their locally stored private key. Any data that needs to be revealed in cleartext to operators and support (like names or account numbers) can be stored minimally in cleartext separately. Or better yet, it could also be stored encrypted such that it’s decrypted on the end-user’s device and sent back to the datacenter in cleartext (one possibility). This results in zero cleartext user data stored in persistent storage in datacenters and requires explicit consent from customers to access any data. This type of extreme security measure would not exist in any app where users can search for other users. It would also reduce the ability for any Machine Learning or Analytics to be run on that data, or a user’s own searches for their own data without downloading everything to the client and run any process locally. This poses a problem with web apps, given that the browser operates in a restricted and secure environment. Workarounds do exist for a user’s searches in web apps (for their own data) under similarly stringent security measures, but they would be limited in scope and require a lot of redundancy and complexity with some cleartext stored in the Back-End.

Conclusion

There are tradeoffs when considering how far to go in implementing Zero-Trust Security. Complexity typically increases alongside security. The term as it currently stands may be better served if it were referred to as Minimal-Trust given that it doesn’t actually require zero trust. Evaluating this tradeoff should take into account the scale of the service, as well as the type of customers being served by it.

Updated: 2024-01-30

---

Author

• ← Information Asymmetry
• App Sec →