Vault and Boundary vision and roadmap at HashiConf 2023

Learn about the HashiCorp Vault and Boundary value proposition for security and learn more about the roadmap of each.

»Transcript

James Bayer:

Welcome everyone. My name is James. I work on security products at HashiCorp, and I'm really excited to talk to you about the Vault roadmap today. My colleague, Pete, is going to join me in a little bit to talk to you about Boundary. Before we jump into the details of our roadmap, I really want to talk to you about some of the trends that are informing our roadmap because it's not just about us going and building things and staying focused there. Every once in a while (this conference has been a great experience for doing it) we can get a lot of feedback from our customers and our users in the community and really understand what kinds of things are going on for you so that we can feed that back into the roadmap.

»Verizon data breach report

One of my favorite places to get some of this information, and in addition to all these customer conversations, is the Verizon's data breach report. For security products, this is a really great resource to understand what's happening. This latest data was published in June of this year and it looks backwards on 2022 data. One of the key findings that we see in this year's report is that nearly half, 49% of data breaches involve credentials. That is a phenomenal finding when you compare it relatively to the other things like phishing or vulnerabilities being exploited. It's a very big impact to the risk in your organization.

Then, if we zoom in even further and look at web application attacks, these are the kinds of breaches that can happen remotely over the web and it jumps up to 86% of those breaches involved stolen credentials. Then you can see the very long tail of other kinds of factors that contribute. And so what that tells us is that there's a really big issue here that we have a lot of risk that's actually being exploited to cause data breaches. For us, that's actually creating a lot of opportunities to make improvements too.

One of the things that this Verizon data breach report also shows us is that in addition to the various places that these breaches happen, they're happening with a lot of different factors. You might have initially the breach come from a stolen credential, but then that breach gets more complicated as they have multiple phases. When you look at things like employees, contractors, and partners in your organization, there's risks there because that might be their equipment or their computers aren't being kept up to date, they're not being patched. Your contractors are part of your ecosystem now, not just your employees. Then, what about your partners or your suppliers and their contractors and their contractors and things like that? It just keeps on going. Right? Then once there's an exposure there, you might be further exposed to things like phishing, social engineering, vulnerabilities, network scans, and then ultimately credentials and configuration mistakes. All these things interplay together.

»The zero click exploit of 2023

If you want just one example of that, you can look at the month of September. I believe the iOS for iPhones was patched three separate times for security exploits. In this case, this one was a zero click exploit. It means someone could send a text message, actually I think this one was one of those when the tickets show up in your wallet or something like that. But in any case, the user didn't have to take any interaction, click on a bad link or something like that, it just exploited their device. You don't have to have an iPhone for this particular exploit to be particularly relevant either because this same exploit (I learned recently from a CloudFlare post) was the same one that was involved in Chrome. It involved rendering images. Any software that could render an image was likely vulnerable to this exploit.

If you think about your employees or contractors and your partners, and if they're bringing their own device and you don't have controls on them, at some point they're going to be exposed to vulnerabilities that could be exploited.

»Big malware groups

Another example of this is malware. This is an example from a big malware group that was broken up by the US Department of Justice and they explained what they did. But the sheer scale of the malware that's out there is staggering. 700,000 victims' computers were affected by this particular malware, and usually what they're after is money. They were stealing cryptocurrency, but then even more you can see that they had tens of millions of dollars in ransomware. One of the things I've noticed in the last couple of weeks, some very large brands have been impacted by ransomware. We've seen MGM, we've seen Caesars, we've seen Clorox, Sony, so just within the last week and months, there's a lot of impact from these malware groups. A lot of what happens with these malware groups is they just get a foothold in your network. Then that's step one. They're what's called a loader, and then people come along behind and they sell that access so people can take it further.

To give an example of this, let's look at 2022's breach from Okta. I really appreciate that they shared the results of this and we can all learn from what happened because last year I talked a little bit about what had happened in the Uber breach the year before. In this case, what had happened is they used contractors to perform some customer service functions in their organization, and that way they can expand and contract their workforce really quickly. But you'll always want to wait for a new device to show up if you want to expand and contract your workforce quickly, so they might have to bring their own device or use whatever controls they have. In this case, that's what they did and they didn't have great controls on those devices and they had Microsoft Remote Desktop misconfigured to not have a credential. The credential was basically wide open, and this allowed hackers to remote desktop into that contractor's machine, which effectively gave them private network access to the things that that contractor could do for Okta.

With that access, they tried to reset the multi-factor authentication request. Luckily, this was caught by their security team and ultimately uncovered the breach and helped prevent things from getting worse. But I think it just shows how all of these factors contribute to the risks of an organization. If you like hearing stories like this and seeing how complicated they can be, I really recommend this book called Sand Worm. It's by Andy Greenberg who's an author at Wired Magazine. It's a really enjoyable book. It's full of stories like those, but almost more from a nation state attacking basis and you can really see the sophistication of the hackers and it helps you appreciate the magnitude of the scale.

All right, so that's what's been going on with some of the breaches, what's been going on with some of the regulatory and compliance environments as a result? 

»New SEC reporting rules

Recently this summer we saw the Security and Exchange Commission from the United States announce new rules that would govern public companies. Now, if you're a public company and you have a material cybersecurity incident, you are obligated to report that incident within four business days. That is going to be a new requirement that organizations will have to deal with. These rules aren't yet in effect, but they are coming. It's just something for all of us to be aware of. These events are going to have to be public and be broadcast with details, and it is going to be coming at us really soon. The other aspect of this is quarterly reporting.

So when a company files a 10K, they're going to have to include cybersecurity details about how they're responding to these risks. And I want all of you for a moment to imagine that you are the CISO or sitting in the chair of your chief information security officer at your organization and the chairperson of your board or your CEO looks down the table at you and says, "Hey, are we ready? Are we protected from these risks? Are you ready to sign up for this?" And the pressure that puts on that CISO as well as their organization to meet these things. You can really understand how that might make people squirm in their chairs. This is what really makes it real for me.

In addition to those SEC rules, there are some good news. 

»NIST Cybersecurity Framework 2.0 - A guide for everyone

The NIST Cybersecurity Framework is now under a 2.0 draft, and this is a revision of a 10-year-old framework that can really help respond to things like the SEC requirements. Because this NIST standard, which was originally set up for mission-critical infrastructure, for defense, what we realized is that it's actually very applicable to almost any organization. That orange yellow circle in the middle is a new part of that framework. What it really means is, yes, all these pieces might've existed in your organization, but to really do this well, we need to have a governance framework that surrounds all those parts and brings them together. Pete's going to mention a little bit more about this, but to me what this is really about is making sure our security teams, our developers, our platform teams, and operations, they all have a way to interact together with their workflows to make everything secure.

»Secret sprawl

All right, so now we're at the point where we can feed all of this information, what's happening with data breaches, what's happening with compliance, what's happening when regulatory environments, and feed that into the Vault roadmap. So one of the things we're really excited about is all the different use cases we can address with Vault.

We use identity based security to unlock these capabilities involved, whether that's secrets management certificates, keys or data protection. But for the focus of today, I really want to zoom in to secrets. And the reason is if you look back on those data breach reports that we just talked about and you see how impactful the credentials are to the recent breaches, it deserves an outsized focus and attention for us, and we really believe we have an opportunity to do better there. Let's zoom in and talk about that.

The way we think about this is a mantra, all of your secrets automatically rotated and easy compliance. Let's see how we can make this happen. When we look at how people use secrets, it's either people or systems or applications. One of the patterns we've noticed is that increasingly, instead of just storing all of those secrets in one place, we've started to see a secret sprawl. 

New solutions are coming up. Kubernetes is a great example of this — secrets built into Kubernetes. GitHub is another example. There's GitHub. It has GitHub actions where people are running CI/CD processes and if they need secrets for that, all their examples show you how to use GitHub secrets for that. What you've noticed is that instead of just storing secrets in one place, like Vault, developers are having a preference and it's not just what they might want to do.

We actually see people doing this, storing secrets in all kinds of different places, in the cloud native solutions, in the big public clouds or in these other software solutions. We know the developers want to use these other systems, but there's an issue with this. Many of these systems do not manage the lifecycle of those secrets. They might store them securely and encrypt them at rest, but they don't actually support versioning. They don't support lifecycle management and rotating the secret. 

»Centralizing secrets and the Vault ecosystem

This is where we've really opened our mind to saying, "I think Vault has a role to play here." Because Vault can give you that visibility to all of your secrets. We can manage the lifecycle and do the rotation of those, and then we can also help with security recommendations about, "Hey, what hasn't been rotated? Where should we put a focus? What is out of compliance because it's being shared amongst multiple things?"

In order for us to be able to do automated rotation, we don't want to just give you a notice that says, "Hey, your secret hasn't been rotated. Good luck." What we really want to be able to do is help you automate that rotation so you don't even have to have a manual step there. But in order to do that, we need a very large ecosystem to be able to create a new secret on demand for all the different secret types you need to support. HashiCorp really knows how to build a large ecosystem. Terraform has 3,500 providers or more for Terraform, and we've been working on building out the Vault plugins as well. Lots of authentication methods, lots of secrets engines, and we're going to be very committed to this because it's critical to maintaining and delivering on this vision.

When you look at this, we believe Vault has a place to play in this entire lifecycle from all the places you're going to be using secrets, Vault can be behind the scenes, managing the lifecycle of those secrets and then interfacing with all the places that you need to get those secrets from.

»Unmanaged secrets

Now, let's go back to the CISO that we spoke about earlier, right? This is the person that the chairperson at the board or the CEO is looking at and saying, "Hey, do you have a handle on secrets?" And the way we've been thinking about this is you can categorize all the secrets in your organization in different ways. It starts at the very top with the highest amount of risk. For secrets you're not really tracking we call those unmanaged secrets. These are secrets that could be in source code, they could be in an unvalidated or approved location, and we want to help you uncover those things. But today, we'd categorize those as unmanaged secrets, and there's lots of them out there.

»Static secrets

The next place that we have is static secrets. This is how a lot of organizations start their journey with Vault. You can put them in Vault, they will be stored securely, and you can really understand who has access to those secrets. That way it gives you good visibility that you have controls on those, but they're typically long-lived. 

»Dynamic secrets and sessions

Increasingly what we see our customers want to do is have automated rotation. Say, "Give me a schedule and help me rotate these secrets on a regular basis so that at least I don't have to do a bunch of manual rotations for that." Then we also see what we call dynamic secrets. These are the kinds of secrets that are issued just in time, and they have a very short time to live. Examples for this is, if I'm doing a continuous integration run, the secret might not exist before the run starts. I start my continuous integration, I get that secret created from Vault. It only is valid for the lifetime of that run. When the continuous integration run is over, the secret's invalidated.

A Boundary session could be another example of that. Boundary actually uses this pattern today. These are the categories of secrets that we believe are out there, and I'm really excited to talk about how BluBracket is going to help us with this. 

»HCP Vault Radar

BluBracket was an acquisition we announced earlier this summer, and it really focused on finding these unmanaged secrets. It was initially focused on source code, but we've expanded the amount of sources that it can look at, and there's a demo outside in the hallway track. I highly encourage you to find Prakash and Sridhar if you haven't talked to them yet, but we can demonstrate this to you. We are going to be calling that HCP Vault Radar.

If you look at our ability now to address the entire category of secrets in your organization, we're really excited about the potential for Vault Radar to find these unmanaged secrets and now bring them into full Vault lifecycle management. This is something that's going to help us realize our vision. HCP Vault Secrets is another aspect that we're really thrilled about. We announced this as generally available yesterday in Armon's keynote. One of the things we're really excited about is it's very simple to use. 

After this session, Kelly and Sam are going to showcase this in the next session. I highly encourage you to watch that, but I want to talk about a scenario about why this can be relevant. Imagine that I'm a developer and I'm maybe a hobbyist or a small medium business. I'm probably going to be starting my development using GitHub, and I might be doing my continuous integration with GitHub actions. I need a secret there. Might be in that previous slide, I showed a Slack token that I might interface with a Slack bot or something like that.

»Secret sync

Then I'm going to, in my test pass, I want to deploy that application into production, and I might be deploying that to a public cloud and maybe I'm using some function to run my application, and it might just be natural for me to store out that secret in the cloud native secret solution like AWS Secret Manager, Azure Key Vault or GCP Secret Manager. When I run my GitHub action, I want my secret available in GitHub secrets. With secret sync, and this is supported in HCP Vault Secrets as well as Vault Enterprise, we can store that secret centrally in Vault and then synchronize it out to any of those locations. This means that if I change that Slack API key, I change it in one place and I have visibility to that and it gets pushed out to all the places that I need it. We're starting to realize this vision I was talking to you about.

»Uninterrupted secret auto-rotation

The next thing we're really excited about is secret auto-rotation. We have this ability right now to have a secret that has a time-to-live, but what we really want to do is absorb some of the complexity around automating the secret. As an example, imagine this secret v1 exists, and at some point we're going to revoke the secret. Well before the secret is going to be revoked, we want Vault to be able to automatically create v2 of that secret. It's a brand new username and password. The thing you notice is that there's an overlap in time when both of these secrets are valid. This allows applications to pick up the new version of that secret and not have any service interruption, and then it goes on and on. Version 3 will come on and then so and so on.

We believe that this is an innovative way that we can advance the adoption of automated rotation and really improve secret rotation because when we talk to lots of customers that are still using static secrets, this is the thing they're after. ‘Help me automate the rotation of almost all the secrets in my estate.’ 

If we look back on what we covered with Vault, we started talking about all the data breaches that used credentials. We talked about our vision for being able to address that with dramatically simpler ways of interfacing with Vault, and Kelly and Sam are going to talk about that next. Then we talked about putting those secrets wherever the developers want them and then helping with the rotation. That's what we're going to be focused on in the year ahead with Vault, and please stop by the booth and talk to us about your needs there. With that, I'm going to turn it over to Pete, who's going to talk to you about Boundary.

»The insider threat - Compromised accounts

Pete Pacent:

Thank you, James. Hey folks, my name is Pete Pacent. I head product management for Boundary here at HashiCorp. I'm really excited to talk to you today and build off of the themes that James was talking about and keep the thinking around what trends are we seeing out in the space and how that is informing what we do within Boundary. To go back to the Verizon Data Breach Report, I think one surprise, or maybe not surprise for those folks in the industry, is that most incidents of privileged misuse that James had talked about are actually sourced from misuse by privileged insider users. Your internal folks, those may be both your standard employees with a basic level of privileges that get their accounts and access compromised, or even those developers, systems administrators, privileged users that have their access compromised. Then James really articulated how those breaches can just snowball and then end up in the report of an SEC filing for your organization.

There's a cognitive dissonance here though, because I feel like most of the time with these types of breaches, when we talk about privileged misuse, these are not new concepts. They are vehicles for breaches in organizations. The question becomes, why is it that even today? After all of the recent thought pieces around zero trust, all of the tooling out there that can help you achieve managing this privileged misuse, why is it that today many organizations still face challenges with this? I would posit that most of that comes from difficulty in actually operationalizing these aspects of zero trust. It's one thing to talk about the idea of least privilege being enforced throughout every single layer of a transaction, but it's another thing entirely to actually go about that.

»Challenges of operationalizing zero trust

I would also posit that it's never been harder to operationalize this. As we talk about organizations moving to the cloud, the complexity of managing resources that are more ephemeral in nature becomes more complex than ever, especially as the concept of the datacenter network breaks down, as Armon had talked about. Then, similarly, a shift with employee management is that your identities that you need to deal with are more ephemeral than ever. This trend was only accelerated with Covid where you have employees or vendors logging in from any network. There's not a constant framework that you can have your human identities follow. All of this is just from the administration side. On the end user side, ultimately, a security tool needs to be as frictionless as possible and not impede velocity. Otherwise, users just fundamentally will find a backdoor to that.

The question becomes: how can we help organizations operationalize zero trust? That's really the vision for Boundary, making it as easy as possible to achieve this secure access, both on the administration side as well as on the end user productivity side. What we're really trying to do is help end users, so your developers, your technical users within organizations, have as easy a process as possible to connect their infrastructure endpoints with all of the advanced, least privileged security controls just fading into the background of a transaction. 

If I think about some human user, some developer connecting to infrastructure, this could be as part of a break glass workflow where maybe your SRE needs to connect to production resources. This could maybe be a vendor coming onto your network, like Verizon talked about yesterday, with partner solutions and external employees coming into their lab environments and having to manage the lifecycle of those users coming on and off of it.

»Boundary workflow

What you ultimately want to do is provide least privilege controls at every single layer of a transaction. With the Boundary workflow, what we're trying to allow organizations to achieve is for them as a first step to authenticate with their identity provider of choice, this is a continuation of that shift from location of the employee being the source of security controls to their actual identity in question, and then moving to a model where they have attribute-based access so that their level of access that they receive reflects the business context that they log in with. When they actually get authenticated and authorized, they should have a set of services that they can connect to. What we're really trying to achieve here is basically enabling almost like a browser bookmark bar of the different infrastructure endpoints that you can connect to. When a user actually selects a host or service to connect to, that's when they get a network session to the actual endpoint.

But unlike something like a VPN, they don't have standing network access to all of the endpoints throughout a datacenter network, throughout a cloud network, but rather get specific connections to granular services. Then ultimately, when they go to connect to that endpoint, maybe that's SSHing into a Linux host. Maybe that's connecting it into a SQL database. The actual secret that provides the authentication mechanism to that target endpoint should be generated on a single use basis. So that's where something like Vault comes into the picture, where Boundary plus strong integration with Vault can help ensure that every single secret that gets created or used in a session is uniquely generated for that session.

Furthermore, Boundary's capabilities around credential injection get exposed from the end user client device so that it never actually ends up on their laptop where they could take advantage of that. If we think about this set of security controls, the really core idea is that at every step of a transaction, you have a defense in depth strategy where you have attribute based authorizations, you have dynamic credentials that are never actually exposed to end users. Then even at the network level, the specific route you received to your endpoint is granted on a just-in-time basis. If we think about this, the core idea is making all of these security controls just blend into the background of the end user experience. That's a theme that we've worked on throughout this most recent release 0.14 that was launched yesterday.

If we think about this though, this nirvana vision that we call ephemeral access with Boundary, many times it takes a maturity or time to mature this model, and there's almost a crawl, walk, run to it. When we think about how an organization can actually go about achieving this vision, many times it's about focusing on specific use cases, building up a set of security controls, until ultimately you establish a high-level maturity and proficiency in your controls. 

If we think about what that crawl, walk, run looks like within Boundary, the first step we really think about is ensuring least privilege access, so creating software defined controls around what assets a particular identity has access to.

From there, bringing in some of these just-in-time controls around limiting network access, integrating with Vault to generate single-use credentials for your particular sessions, and even moving to an attribute-based authorization model away from standing privileges towards using user context from an identity provider. Where are they logging in from, what intra groups they may be a member of, as an example, and using those security controls to provide just-in-time controls for your session.

Then ultimately, when we think about the most realized vision of this privilege access management workflow, we think about defense in depth where at that point you're not just having these least privileged controls, you're incorporating things like session recording so that you get a full audit log of your user's activity and things like multi-hop sessions where you can actually connect to remote systems that may be at the edge, or networks that may be more than just one hop of a network away from an end user. 

»Boundary roadmap

When we think about what comes next within Boundary's future, and what the things are that we're really going to be investing in, there's three themes that you'll see us work on over the upcoming releases.

The first is just to continue on this trend of simplifying the user secure access experience. With 0.14, we launched the ability to have an embedded terminal in Boundary Desktop. As a user, you can just connect to your target, click connect, and launch a shell of choice for SSH sessions. We'll continue to work on this to simplify that experience, incorporating things like advanced search and highly performant search, and then just a whole initiative to basically ensure that the Boundary workflow bleeds into the background of a user's common tasks that they do.

On the second piece, when we think about this vision of ephemeral access, we've most fully recognized this within SSH sessions. Within Boundary, we now support single-use credentials for SSH sessions, injection of credentials in SSH sessions, and then ultimately recording of that activity. We want to expand that defense in depth approach to all of the types of endpoints that you may access. That'll include things like Windows RDP devices as well as web endpoints. That'll be a continuous theme of work where we can build that ecosystem of endpoints that we can provide this for.

Then lastly, a key point is just making sure that Boundary's workflow can be carried out in even the most highly compliant environments. Making sure that our cloud service has the compliance program attestations that you may need to do business. We'll be working on PCI as a first pass of this and then continue on for other types of compliance programs in addition to the SOC2 that we already support today.

»The intersection of security, platform, and application teams

As we wrap up on this talk and expand out, not just from Boundary, but really think about the pieces that James talked about on Vault Radar, really what we're trying to do with our secure portfolio is work on this intersection of application teams, platform teams, and security teams work. Application teams ultimately need tools that don't impede their workflows. Platform teams are really looking to standardize the operations of their tooling for their application teams. Then, security teams ultimately need the governance controls that give them the ability to monitor and manage corporate policies across their entire IT landscape. We think that today, walking through this vision for Vault, Radar, and Boundary, we're providing a comprehensive suite of offerings that allow these three stakeholders to really succeed. Thank you very much for the time today and enjoy the rest of HashiConf.