The story of BastionZero

BastionZero is leveraging cryptography to reimagine the tools used to manage remote access to kubernetes, server, application, and database infrastructure across cloud and on-prem environments. The company was founded by a cybersecurity professor and cybersecurity PhD who spent years working together at Boston University.

‍The architecture of BastionZero is inspired by innovations in threshold-based cryptography and developed by a team of cryptographers and infrastructure experts looking to simplify the lives of cloud security teams, while modernizing the security models used in the cloud security space. We are backed by top VCs along with experienced individual operators of cybersecurity and SaaS businesses.

Product Overview

Our Leadership

Sharon Goldberg, PhD

CEO & Co-Founder

Sharon Goldberg is also a CS professor, author of 30+ peer-reviewed infosec papers & contributor to BGP, DNS, NTP & Bitcoin standards.

Ethan Heilman, PhD

CTO & Co-Founder

Ethan Heilman has been a software dev at various startups & inventor of cryptographic protocols & attacks. He holds a PhD in infosec.

Mike Milano

President

Mike Milano is a former SVP Engineering & Product at Cisco and iBoss. He has decades of experience building cloud security products.

Backed By

Read more from the BastionZero team

Cattle Call: Using BastionZero with Ephemeral Infrastructure

BastionZero has been deliberately designed to work with ephemeral infrastructure. When we say ephemeral infrastructure, we mean compute resources that are created dynamically and destroyed as needed, rather than being persistent and long-lived. Despite this, even with ephemeral infrastructure, your engineering and DevOps teams may still require access to infrastructure to support debugging and forensics. Teams need to be able to work through production issues, react to security events, or observe the infrastructure as it interacts with production workloads. Luckily, you can use BastionZero for this.

Introducing PIKAs: Proof of Issuer Key Authority

A few days ago, Richard Barnes (from Cisco) and I submitted a new internet draft to the Internet Engineering Task Force (IETF)’s OAuth working group. (This is the very first step on the long road to publishing an RFC in the IETF internet standards process.) In the draft we introduce PIKA: Proof of Issue Key Authority, to solve a problem relevant to OpenPubkey, OpenID Connect (OIDC) and JWTs (JSON Web Tokens) in general.‍ PIKAs allow us to cache and redistribute an OpenID Provider (OP)’s public keys. In this blog, I’ll introduce the OpenPubkey issue that led me to get interested and start working on PIKAs, explain what PIKAs are, and show how they allow OPs to provide long-lived bindings of public keys to identities. And why PIKAs apply to much more than just OpenPubkey.

Generalizing OpenPubkey to any Identity Provider

When we first released OpenPubkey, it was interoperable with many OPs (like Google and GitHub), but not with all of them. In fact, when we started this project, there was an actual technological limitation that prevented OpenPubkey from working with certain OPs, including GitLab’s OP. And support for GitLab’s OP was one of our most requested features.‍ Well, today I’m happy to announce that last week’s release of OpenPubkey v0.3.0 smashes through this limitation. OpenPubkey now interoperates with any OpenID Provider.

Resources

Read Our Docs

Check Out The Protocol