SafetyDetectives spoke with Dr. Ethan Heilman, the CTO of BastionZero, about his journey toward co-founding the company, zero trust access, continuous validation, the advantages of single-click passwordless authentication, and more.
Can you talk about your background and what motivated you to co-found BastionZero?
I worked as a software engineer with a specialization in security for around seven years. Watching the ways in which cryptography was solving whole classes of computer security problems got me very excited about cryptography, so I ended up doing a Ph.D. in computer science at Boston University focusing on Network Security and Cryptography.
While pursuing my PhD, I founded BastionZero with Sharon Goldberg, a Professor at Boston University. Our aim is to leverage the large number of breakthroughs that cryptography has made over the last 30 years to solve the critical security problems of the present age.
I often think about the fact that simple engines were around in the time of ancient Greeks but no one used them in industry for thousands of years. The time between the development of a technology and its deployment is much smaller in the modern age but can still be measured in decades. RSA encryption was discovered in 1977, but RSA didn’t see ubiquitous use until 35 years later. What we are doing with BastionZero is solving everyday security problems faced by institutions and businesses by speeding up the process of making available some of the treasures of modern cryptography.
What are some of the top features offered by BastionZero?
- Secure and simple Single Sign On (SSO) access to Kubernetes, servers, and databases. Rather than having to manage SSH keys or database passwords across a large number of hosts and privileged users, you can authenticate your users with your SSO provider, say Google, Azure, or Okta, and then use BastionZero’s policy system to specify which users can access which resource: “Alice@example.com can assume the db user admin on the development and test database server,”
- Auditing and logging. BastionZero logs all of this access, providing independent external logs of who did what and when.
- Ability to organize, tag, bucket and search all the resources protected by BastionZero. BastionZero uses a “phone home” approach, meaning that resources identify themselves. This removes all the headaches of finding a server when an IP address changes.
- Just In Time access with Slack. The traditional model of giving a user all the privileges they ever need results in over-privileged users. We provide a mechanism where users can require time boxed access over Slack. This allows administrators to reduce the standing privileges granted to a user, while still providing flexibility for exceptional circumstances.
Underlying these features are cryptographic technologies that allow us to offer these features in a highly secure way. For instance, our server access uses a protocol we developed called OpenPubkey so that while we policy check what servers a user can access, BastionZero itself can not access that server.
Can you explain what zero trust access means in the context of network security?
The central idea of zero trust is an architecture for achieving least authority. That is, only grant users the authority and privileges they need for the period of time that they need it, and no more.
Zero Trust achieves this by having an authorization server that grants short lived tokens to users. Users, in turn, present these tokens to prove to the resource they are authorized.
How does the concept of zero trust access differ from traditional network security approaches like VPNs and SSH keys?
There are Zero Trust VPNs, but I would argue that while they may obey the architecture of Zero Trust, they violate the goal of Zero Trust, i.e., least authority. The issue with VPNs is that they secure networks rather than resources or applications.
In the worst case, they function like a wall around a network with access checking at the gate. The advantage of this approach is it is simple: simple to deploy, simple to reason about, and simple to manage. The disadvantage is that once someone is allowed through the gate, they are now trusted, and you lose a lot of control over what they can do.
More modern VPNs improve on this by increasing the granularity of the access control. Rather than a single wall around each network, you have a wall around each server. While this is closer to least authority than traditional VPNs it still falls short of the spirit of Zero Trust. Ideally you want to control access to applications where you can say something like: “Alice@example.com can assume the dbuser admin on the development database server.” If you end up doing everything at the network layer as VPNs do, you end up only being about to say “Alice@example.com can send TCP packets to the IP address associated with the development database server and the IP address associated with the development database server.” The network abstract does not match the abstract you want to use for policy control and the gap that VPNs create here results in weaker security.
SSH keys are a whole other can of worms. While there is nothing wrong with SSH as a protocol, the tools for managing SSH keys often result in SSH keys being used in an insecure manner. For instance, SSH is easiest to set up by just pushing a single SSH public key onto all the servers and then sharing that SSH private key with everyone that needs access. This is a fairly common practice and it is also a bad security practice. Not only do you have long lived credentials being stored on people’s computers, but because that credential is shared, determining who was compromised is difficult. Employees may leave the organization and still have access through those share keys.
The reason many organizations do SSH this way is not because they are incompetent or that they don’t know any better, but because more secure patterns of SSH use are expensive and complex. For instance, in AWS EC2 you can attach an SSH keypair to an ec2 instance, but AWS does not connect that key pair to a user identity. As AWS says in their documentation:
“If someone has a copy of the private key (.pem file) and you want to prevent them from connecting to your instance (for example, if they’ve left your organization), you can delete the public key on the instance and replace it with a new one.”
That is the onus of managing these key pairs is placed on the company, not on AWS.
BastionZero lives up to zero trust and least authority in both architecture and spirit. We connect identities directly to the ability to access a particular resource. You don’t need to manage SSH keys, you can just see in our policy system who can access what. If you remove a user’s privileges to SSH via a policy decision that user is locked out, no need to delete keys.
What is Continuous Validation in the context of security posture, and why is it important for maintaining a secure environment?
Continuous validation means scanning and verifying that security controls are working as intended. This is very important to detect misconfigurations or unexpected side effects. For instance consider an update to an access control tool that has the unintended and undocumented side effect of changing the configuration of that tool and as a result disable some security protections you rely on. You might not realize that this has occurred until you test that the controls are functioning as intended. Your window of exposure is as long as the time between tests.
What are the advantages of implementing Single-Click Passwordless Authentication over traditional username/password-based authentication methods?
Requiring that users remember and use passwords across a multitude of services has a number of security and operational disadvantages:
- Users forget and lose passwords which require that companies build, operate and maintain the ability to reset or rotate passwords across a variety of servers and services. These password reset mechanisms are often vulnerable to social engineering and phishing attacks. The annoyance of remembering many passwords can cause users to choose memorable passwords and opens these passwords up to bruteforce attacks. Even worse, users might reuse passwords. Passwordless authentication frees companies from spending money and time on password management.
- Often there is no one-to-one mapping of users to password-based accounts. For instance a database administrator account may only have one password, but a number of users may need to access the database as the admin. Thus all of these user’s know this password. If this password is rotated when an employee leaves, it is often tricky to securely inform all users who need access to that account what the new password is. PAMs and enterprise password managers provide a bandaid to this problem but they don’t always address the deeper issues. With passwordless authentication, you can track and audit exactly which identity assumed which account at which time.
- With passwords, you never know who that password was shared with. The security industry often talks about how users should never share passwords. In many cases, users need to share passwords to get their jobs done. We shouldn’t be blaming users, the problem is not user behavior, but passwords. We need to fix the root cause.
With passwordless, there are no long lived credentials to be stolen or shared.
- Passwordless is just nicer for users. From the user’s perspective they auth once to sign on and they are in. This lets people work faster and maintain a flow state. In the background, their privileges and access is continuously being checked and authenticated, but that happens without interrupting the user.