Dogfooding your own product is a long-standing tradition in software development. The benefits are many – from finding and fixing glitches before any customer rollout to developing empathy for the end user (since that end user is you). Great stories arise from the efforts to deploy and use your own product and not surprisingly, our Banyan @ Banyan dogfooding program has yielded these benefits too. I’m going to share a few stories that explore our experience and help unpack the complexity of building a Zero Trust environment. The first in this series will cover how we approached compliance, and later posts will cover remote access for engineers, InfoSec, and finally productivity.

Part I: Compliance without a VPN or MDM

I love compliance.

Yeah, you heard me, I love it, it’s great. How’s that you might ask? Isn’t it the pain in the tuckus that we have been fighting with for decades while still trying to be productive?

I love compliance because it’s the right thing to do. Security compliance standards are all about best practices. They help your customers have confidence that you are taking security seriously and making a true best effort. Sure, there will often be some annoying aspects that just don’t seem to be relevant to your situation, but that’s a discussion for another time.

At Banyan, when it came time for our compliance efforts, I dove in headfirst. I knew it would be a straightforward exercise – mostly documentation – as we are already mature in our internal security posture for a young company. But where is the fun in that? We decided to up the challenge and use our own technology as much as possible. We’re a secure remote access platform and compliance has everything to do with securely accessing systems that contain sensitive data.

Hypothesis – could we become SOC 2 compliant without the presence of a VPN or UEM/MDM, solely by leveraging our own platform?

We wanted to avoid deploying a VPN because we believe it’s an artifact of a bygone era and wanted to have our systems start off secure from day one.

The UEM/MDM though was different. Our employees are very security and privacy conscious, values we hold dearly. Many of our employees want to use personal devices, whether it’s using Slack or email, or checking production system health status while on the move. Installing UEM/MDM agents on personal devices that give an administrator the ability to wipe or lock a personal device was deemed unacceptable to all involved. Having a UEM/MDM that only covered corporate devices to provide inventory of devices was also insufficient as it leaves out many of the devices that access our corporate resources! As a result, we chose to use the Banyan Security Zero Trust Remote Access platform for Inventory Management requirements, and relinquish our dependency on the UEM/MDM.

Could we do it?

Challenge accepted. The following is an overview of what we did to achieve compliance in our production environment.

This diagram illustrates connecting to each of the 5 interfaces: Product Console, Containers, Kubernetes, Databases and Cloud Infrastructure.

The primary part of SOC 2 compliance that is relevant for this discussion focuses on how we control and limit access to sensitive information. In the Banyan platform, our SaaS component has a database that contains all of our persisted data, and while it’s not super sensitive, no PII, credit cards, etc, it does have customer data. The SaaS component has a range of interfaces that users can leverage to access sensitive data, a web interface for the administrative console, Public cloud provider console, SSH, Kubernetes, and the database itself. These all need to be protected by a small set of privileged users. These users are identified in a group definition in our identity provider, and then protected by Banyan using a number of different techniques:

Product console – Administrative interface to configure system, view usage and monitor security events. This interface is available via HTTPS, so we configured it as a SaaS application with our identity provider leveraging Banyan’s Device Trust continual authorization capability.
SSH Microservices– Containers that host our application microservices. This interface is SSH, so we enabled the hosts behind a Banyan Access Tier and end users would establish connections from our App Proxy using HTTP_CONNECT mode.
Kubernetes – IaaS managed Kubernetes. Leveraging the standards-compliant OIDC Provider, it natively provides the ability to authenticate and authorize users against K8S clusters. This gives end users the ability to connect to K8s clusters without a VPN, authenticate against the cluster directly through the Banyan app, and authorize users with RBAC using Banyan Roles and Policies.
Databases – Cloud DBaaS instances. This interface is TCP, but cloud-provided so no SSH directly to the host. Here we AllowListed the IP range for accessing the SQL instances to be the Access Tier, then let end users connect from our App Proxy using TCP_MODE.
Cloud resources & cloud console – Public cloud provider’s console and APIs. For the cloud provider’s console itself, we put it in our Identity provider to use our SaaS Continual Auth, and for the Cloud APIs followed the same strategy as with the databases. We limited the IP range to our Access Tier.

This approach allowed us to comprehensively provide secure remote access to our entire production environment. However, there is an interesting nuance. If we are using our own production environment to limit access to our production environment, what happens if our production environment encounters a true disaster? If it’s not available, we would not be able to get into our production services to fix our production services!

The answer here is not super clever, we just created a second production cluster to protect the first. We use this cluster for non-customer activity but still treat it with production standards. During our compliance audit, we all had a good chuckle about this irony.

Moving on to the audit process itself, there were some key bits of evidence that we relied on the Banyan platform for:

List of corporate assets (hosts & devices) – Instead of using an MDM, we provided the list of hosts and devices, both mobile and desktop, from Banyan.
Ensure EDR – The compliance standard calls it AntiVirus, but nobody says that in the industry, instead it goes by Endpoint Detection and Response (EDR). We demonstrated for the auditor that we could show that access was not granted to a sensitive resource unless both EDR was installed AND no critical issues were on the endpoint. The auditor loved this capability, they hadn’t seen it before.
List of access activity – We provided the auditor a list of access-granted events for each time an end user attempted to consume a sensitive resource. Again, the auditor greatly appreciated this visibility as they hadn’t seen this independently collected outside of a SIEM, and even then the SIEM list was often obtuse and hard to understand. Also, being able to show access events to a specific service broken out by personal and corporate devices was a big plus.
Evidence of least privilege access – Auditors want to see evidence that only certain employees are allowed to access sensitive data. We not only showed this via our policies in the administrative console, but gave them a full view of a least privileged access model for all services, employees, and contractors.
Evidence that 3rd party contractors could not access sensitive data – Finally, we were able to show via policies that our 3rd party contractors are all beholden to Banyan policies, with no shadow IT set up for them to work around our standards.As I mentioned at the beginning, I enjoy the audit and compliance process. Am I nutzo? Perhaps. But using our own product and pushing the limits of the norms of our auditors? That was fun. Heartily enjoyed by all involved.