Ep16 | Bridging the Confluence Security Gap with Virtru Secure Share

Transcript

Alright. Welcome everybody to, the latest in Virtru's Hash It Out discussion series where we just discuss sort of industry topics in a more casual format, just between, you know, two or three parties. Today, our session is called, "Bridging the Confluence Security Gap with Virtru's Secure Shares" talking about a newer product that we are rolling out shortly. I am Trevor Foskett, the VP Solutions Engineer here at Virtru, and I'm joined by my colleague, Daniel Bennion. Daniel, you wanna introduce yourself as a long time listener first time caller here?

That's right. Yeah, great to be on. I've been with Virtru now for about three years, and I've worked extensively with secure share from its inception about two plus years ago, and now moving into integrations is pretty exciting. So I look forward to hashing it out together.

Awesome.

So today, we are going to be talking about secure share for Confluence, which is we'll get into how what it is and how it works in a bit, but can you speak a little bit, you know, what helped us choose Confluence to serve an integration target? To date, we've done You know, more workflows around messaging, you know, we integrated secure share into Zendesk, for example.

Little bit of a different model here. Can you tell me a little bit about the background of how this kinda came about and how we put this on the road map?

Yeah. Absolutely.

Confluence is an interesting opportunity, because it's a place where there's increasing collaboration, especially in a remote first workforce.

The need to have things written down and documented in a place where people in different time zones on different schedules can go in and get updates and make sure that they're documenting processes and procedures, where secure share comes into play is an opportunity to expose sensitive information in a location that may be overly visible. It may be something that hey, the entire organization or entire group has access to this space, but I've got some information that I'd like to associate with a certain channel or space, but I really wanna limit the exposure to that. And so that's where secure, share enables you to, encrypt information and limit the access to that information. So be it a password or an API key or a certain tester account that you may have if you're a software company, that prevents, sort of wide viewing, but enables you to keep all that information in the same locale.

Interesting. Yeah. So we're, you know, a little bit more again around storage rather than really transmission of information, but I think it goes right. Connect the dots with the rest of the things that we do where we're talking about limiting access using encryption to do so and really narrowing the aperture further than what is available in the platform itself.

Confluence, if you have access to the page, you have access to read. The whole thing, which means that if I have sensitive information historically, I would need to go put it somewhere else. And It's been pretty powerful for me already, you know, getting access to a, you know, pre pre release version of it. I was documenting a lot of the processes that we have for my own team, things that we do to manage and sales teams demo environments and different servers that we have set up somewhere.

And as I'm going through documenting these, thinking okay if someone needs to go in and fix this server because I screwed it up probably.

How are they gonna do that? Because I have the SSH key for it stored locally on my device. Well, now I can actually put it right in there in that sort of SOP of here's how you go in and fix this thing. Here's what it needs.

And, oh, by the way, when you connect to it. Here's your credential right here. I don't have to worry about sending somewhere and someone somewhere. And I think that that's sort of a common thread with our our, you know, philosophy as a product organization, of sort of integrating into existing workflows, going all the way back to the original Gmail integration of, you know, don't leave Gmail to create sensitive data because otherwise you're probably just not gonna do it.

Same with Zendesk and now, with Confluence.

I mentioned one use case. Have you guys used anything yourselves? Are you thinking more about developer use cases? Or is the product team, come up with any ways that you guys are actually using this live through your own workflows right now.

Yeah.

But one of the things I'll mention is that the use case for mail, like you talked about, is very much kind of once you send an email, it's over. Right? You've sent it, and we give the ability to revoke that message even after it's been sent, that control.

And similarly, in Confluence, you're living in a world of living, breathing documents. You may have a sensitive SSH key, like you said. But then that key may change. You may roll a new key or a new password, you know, things change.

And we wanted to mirror that with our integration into Confluence. And so when you create this encrypted content, you're able to change who has access to it. You could add users to it. You could remove users as things change.

And you can also update the content, which is not the way things work on that email side and even the file side.

So you can add more users, and you asked about use cases. One common one for us is on the testing side of our software, we have a lot of different tester accounts, and that includes a username and a password and access to a domain, And so that's the place where we will encrypt that information. And so you have the list of what you need to be doing as a tester, but then you've encrypted that blob of information. And it's been around, you know, been tested long enough that we've had to go and update those passwords because, occasionally, we do update the passwords. It's very easy to go back in and update that, republish it just like you would on any other page in Confluence.

Yeah. That's actually really interesting. One that I hadn't thought of, but it's sort of new for us. Usually, as you said, when we are encrypting data historically, we're kind of turning it into this now immutable version of it, which makes sense for email.

You don't wanna be able to send an email and then go in and change it later and say, "no, I actually said this." Right. I think a lot of our vault admins or our compliance folks would probably not love to see that.

But for something like confidence, it makes total sense that you wanna update these things. The procedures change. You've rotated keys. You have a new username and password because you have twelve QA people all sharing one Google account. They make you change it every two weeks.

Yeah. Really interesting. Did we have to make any modifications to the underlying architecture to support that, or is it just just swapping the payload? No. It's just Yeah. Exactly. It's that. It's just swapping the payload and then re-encrypting it, which will modify that for you. So it really feels seamless on the front end experience.

Yeah. No. I've seen it. It looks like it's just a part of Confluence. I mean, with that, knowing, obviously, that it's a third party integration. It looks like it's really baked into the experience.

You know, that editing model is interesting. It sounds like it's almost a little bit closer to the Google CSE model of kind of open, make changes.

Right.

Re-encrypt save again. Obviously, Google's doing all that in their own platform. We are, of course, a shameless plug, happy to support.

Google CSE is a key provider, of course. Yes, we are. But an interesting model, this sort of data in use and sort of changing data is interesting to see how that kind of evolves.

Yeah.

That part you said about editing just to add on to that is you know, some of the early feedback from early doctors has been, "hey, what if I wanna edit it like I do a Confluence page? I want headers, and I want to actually recreate almost an entire page in an encrypted payload."

We can support that now as well, and a lot of those editing capabilities look very similar, thanks to Confluence and their APIs so that when you're editing, you can kinda recreate that look and feel that you're used to in Confluence, but now it's encrypted and protected. With policy. Very cool.

I'm thinking probably, you know, we've mentioned a lot of these developer use cases, API keys, passwords and things like that, but I'm I'm imagining, and this is I'm I'm learning. Obviously, we've sold a lot of tools for collaboration and data sharing. This is sort of a new one for us, the new use case in general. So I'm still figuring out where exactly the fits are, but I imagine there's also a case for we have things that we wanna store in Confluence that not only do we not want certain members of our organization to see, but probably we don't want Confluence to see either. I mean, was that a consideration about more compliance based or was the developer journey sort of the impetus here, and then and then we get that as a bonus.

No. Absolutely.

And Confluence has some interesting new AI or artificial intelligence features where they can read a page and tell you what's on the page in a summary, which is very cool. And if they're adopting more of the LLM Model, they're bringing more of that value to Confluence.

We've done testing to make sure that that AI cannot read the encrypted payload. So I've taken a page with a lot of content that's encrypted. I decrypted it and then I run that model and it still cannot read it. And so we've been able to kinda confirm through that validation that this is sensitive information to the level that even confluence cannot access it and cannot cannot view it, cannot summarize it in AI summary.

Yeah. The last thing you want is an LLM, you know, spitting out your API key or something because it got confused. I mean, this is an interesting use case and it's not one that we've heard unique to Confluence, actually. We've had a few people mention, you know, Google now has their duet product, which is going to you know, probably look at your Google docs slide sheets and people have said, "Great. But if I'm putting, you know, PII in there, I don't want that Social Security Number getting committed to the model, and then, you know, potentially be, pop back up sometimes."

So this ability to descope against some of our data from training models, which ultimately are gonna help us with productivity, but have the ability to filter on what it has access to rather than filter what it spits back out later.

You could move up the pipeline,it's probably the safer way to go about that. Exactly. I did not know they had that. That'll help me be a little bit more of my own Confluence Workspace and can use updating some expansion.

So we may rely on the LLM to help us a little bit with that. Yeah. Because you know, one of the things this makes me think of, and we're gonna do another kinda shameless plug for something else that's coming down the pike from the Virtru Product and Engineering Team, this concept that you mentioned earlier about kinda narrowing the scope of access. We have a whole Confluence space.

If you're in the space, you can read all the articles, but we wanna be able to descope, you know, an API key and have it available to three people, for example.

Sounds like a similar story to another integration that your team is working on. Can you guess where I'm going here, Daniel?

Are you driving towards something? I am driving towards something. If you can't figure it out, you may wanna Google it.Yes, We're here all week, folks. This is great.

That's right.

Have a deal.

Hash It Now is now just a series of terrible puns that we're gonna work on.

But no, getting back to the thread, is Google Drive. We hear the same thing. If we have things you know, either in drive that we wanna make sure that some people can't see or Google's only giving me sort of two ends of the Spectrum when it comes to how I'm able to restrict or allow sharing. Do you wanna touch a little bit on secure share for Drive and that sort of philosophy we've taken there as well.

Yeah. Absolutely.

So in Google's ecosystem, it's very much an all or nothing with Drive Sharing. You can lock down your drive and you can say, hey, we don't want this to be external. This is internal documentation.

So we're gonna not allow external sharing, or you turn it on and you allow external sharing.

And anything in between that is actually quite complex and difficult to create let alone maintain.

And so what we've done with Secureshare is we've built a Google Drive add on, which works anywhere you have Google Drive, and you can add that to your instance of Google Drive, and you select any number of files, and then the drive plugin will take those file IDs and open up in a new window in Secure Share and encrypt those before it even, before that doesn't download them or anything. It will just take those file IDs, client side encrypt them for you so that you can then share those files. And so you can keep your Google Drive locked down to external Sharing and collaboration. If you wanna have that protection, but then on a limited basis with this Drive add on, you're able to then take those files, encrypt them on the client side. We convert docs sheets and slides into the Microsoft format equivalents because those don't live outside of Google Drive in the Google ecosystem.

And then you're able to share those with policy, with protection. You can pre configure watermarking and expiration, and all these pieces that Secure Share offers natively, you can now get that benefit, for any of your drive files to be shared.

Really cool. Love the idea of using, you know, my credential rather than some sort of external credential to retrieve the file and share it in a controlled way. It's kind of an elegant solution to the two options that Google offers as well as to stick on the very lockdown version.

But because it's just me pulling the file to share, I can go you know, I kind of go through that, but only in this controlled way. It's something we hear a lot about with Google Drive is we wanna let people share if it's protected, if it's encrypted, but historically, we really haven't had that capability. This is kind of a really cool way of achieving that. I'm very excited to get my hands on it.

So, more to come on that for our audience.

Well, I'll probably have a big teaser.

Sessions to talk about that. Well, Daniel, thank you, for joining me and participating, in the terrific pun off.

Hopefully, we didn't scare away too many listeners. They'll wanna come back for the next one. But, if you did tune in today, thanks for joining us. Hope it was helpful. And, we'll see it for the next edition whenever we get around to it. Probably, not until the new year. Daniel, thanks again.

Alright. Take care. Thank you.