BastionZero Manifesto

Hello World 

As the new kid in the infrastructure and remote access space, we wanted to take a moment to introduce ourselves. We are a group of cryptography PhDs, engineering leaders, and infrastructure experts and enthusiasts who think the remote access industry needs some shaking up. In fact, we believe everything about infrastructure and remote access needs to be simpler and more secure.

We understand your engineers inevitably want access to your infrastructure. They demand the ability to shell into EC2 instances, use kubectl to make changes to a cluster, or jump into a database to run analyses or look at records. 

You can try to stop them sometimes, but at the end of the day, your business requires you to provide access to infrastructure and manage the risks.

Your trepidation is both real and valid.

That’s why we built BastionZero.

We promise to be your partner in reducing risk. Because at the end of the day, we both want the same thing — to provide your users with exceptionally secure remote access to your infrastructure. 

Keep reading to learn how we’ll do this together.

‍

How did we get here?

The fear is real. Speak with any security engineer or anyone responsible for managing infrastructure and remote access, and if they're honest, they’ll tell you there is a lot to be afraid of. Here’s a few scenarios that we’ve seen first hand...

Mistakes. The most common mistake is giving too many engineers too much access to your infrastructure. Next thing you know, production is broken because someone shells into a server that they should not be touching in the first place. And, if our own experience tells us anything, the access logs are likely patchy or hard to find, making it hard to figure out who’s responsible for that irresponsible “update.” 

Attacks. Starting off, open ports are a favorite attack vector for ransomware propagation. Next, if you hand out VPN and SSH credentials, you need to ensure your engineers don’t lose them, leak them, or even mistakenly share them with an adversary as well. Of course, you don’t want your kubernetes APIs on the public internet and your internal websites accessible to all either. And finally, you certainly don’t want an adversary to attack a bastion host your predecessor installed three years back and no one ever managed to patch.

Compliance. Your customers understand these risks as well. Which is why providing evidence that the the right people in your organization have access to roles and targets is a key part of many compliance frameworks, including SOC2, PCI and others. 

Even sales teams are starting to include this as part of their standard procedure, expecting answers to customer questionnaires that dig into how you manage access. And you certainly don’t want to spend hours gathering evidence for your auditors, only to be embarrassed by your answers (or in some cases lack of).

So we set out to build something with better security and less complexity.

‍

Simplicity should be the goal

‍

Tell us if any of these sound familiar...

• You have tens of engineers connecting to your kubernetes API through a variety of different roles (or maybe just one over-privileged role!).
• You have home-grown bastion hosts to manage. 
• You have a VPN, along with user SSH keys that are dropped on different targets using a homegrown CICD process. 
• You have stitched together your own access system using tools offered by your cloud provider or other third party products (most likely duplicated across environments). 

Just looking at the examples above, to say there are lots of ways to provide access to infrastructure, and as many different types of infrastructure that engineers need access to, is an understatement. And with each approach or scenario more complexity is introduced.

Of course, all of this complexity is hard to manage, and often leads to bugs and security risks. Not to mention, it can be embarrassing to present to customers and auditors as well.

We’ve faced these challenges ourselves. And this is why we built BastionZero with simplicity in mind. This means…

• You shouldn’t have to maintain long-lived credentials for each of your users and targets. 
• You shouldn’t have to disrupt your engineers’ workflows. 
• You shouldn’t have to patch or maintain bastions, jumphosts or VPNs across all your environments.

‍

‍

‍

Remote access a cloud service 

BastionZero is a cloud service offering remote access to all of your targets (servers, containers, clusters, web applications and DBs) across all of your cloud and on-prem environments. Essentially a unified platform for infrastructure access. 

We prioritize making our service easy to deploy into your infrastructure and easy to integrate into your engineers workflows. We won’t ask you to self-host or maintain redundant proxies in each of your environments. We won’t ask you to take six months to roll out an infrastructure access platform across your organization.

It also means you save hours managing all those annoying tasks, like handing out keys and credentials, manually on-boarding and off-boarding engineers as they enter or leave the organization, or searching for bespoke evidence to show auditors and customers that the right people had access.

‍

Zero Trust, not just a buzzword anymore 

 “If you want to allow engineers to access your infrastructure, you really should be doing it in a zero-trust way.” Anonymous

Right. Like us, you’ve heard that one a lot.

OK, so let’s talk about what zero trust really is. It’s a buzzword. Everyone uses it. 

However, regardless of said buzzworthiness, it’s still guiding the way most of us think about cloud security. And that’s ok.

In this industry, zero trust usually means “don’t trust your users with long-lived credentials.” This makes sense. Long lived credentials can get stolen. Users can walk off with credentials, or mistakenly leak them to adversaries. If we want to keep our cloud systems safe, we shouldn’t have long-lived credentials lying around all over the place. 

So how do we get rid of long lived credentials? 

Well here’s where we go from “best practice recommendation” to “checking the box that says zero trust” without actually providing zero trust.

In fact, what usually happens with zero-trust systems is: we put in some highly-privileged authority that issues short-lived credentials to our users. For example, we tie everything to an SSO (pick your favorite: Active Directory, Okta, Gsuite, AWS SSO, etc etc), or we use a certificate authority that issues short-lived certificates to our users.

And this approach is great for removing trust from our users. But have we really dropped trust to zero?

Unfortunately not. 

By putting in a highly-privileged authority that completely controls who gets access to what, we’ve put 100% of our trust into that authority. That’s not zero. 

Making things worse, adversaries know that too. Over-privileged certificate authorities have been a juicy target for attacks for decades, and attackers are starting to clue into and exploit vulnerabilities in SSO providers.

We believe there is a way for “zero trust” to really mean zero. And that’s the premise we’ve built the BastionZero security model on.

‍

‍

A better zero-trust security model

‍

At BastionZero, many of us come from the world of crypto (where crypto means cryptography!), and where minimizing trust in authorities is a simple, achievable and well understood goal. 

So we started with a simple focus: don’t build systems that put all their trust in a single over-privileged authority. 

Instead, we developed a cryptographic security model that splits trust between two different authorities. 

One of these authorities is our BastionZero cloud service. The other is your SSO provider. 

What does this actually mean? 

It means that if one of the authorities is compromised, your targets are still secure because the other authority protects them. And it's unlikely that someone will compromise our cloud service AND your SSO provider at the same time. 

Not only does this provide great odds for protecting your infrastructure, it also means you can finally (truly) provide a zero-trust approach to infrastructure access in your organization.

‍

‍

We don’t have (or want) privileged access 

When we say, don’t give away all your keys to your kingdom, we mean it. BastionZero is a cloud service, which makes it easy to deploy, integrate and maintain. 

Practically speaking, we understand you also don’t want to worry about our cloud service being compromised either. The good news is that we’ve gone to great lengths to ensure that even if BastionZero’s cloud service was compromised, your targets remain secure.

Our cloud service does not have (or want!) privileged access to your infrastructure targets. 

Instead, our cryptographic remote access protocol requires that targets only provide access to users that are authorized by your SSO provider. That means that no one has access to your targets without the permission of a valid user in your organization, not even our cloud service.

So you can rest easy using our cloud service without worrying that we’ll become a single point of compromise for your organization. 

And, if you’d really like to get into the technical details, we’ve written a white paper on our security protocol: the Multi Root Zero Trust Access Protocol (MrZap). We believe our security model is at the center of modern infrastructure access management.