Ep38 | Virtru + Rocket.Chat: The Last Mile of Zero Trust - Governing the Collaboration Layer

Welcome to Hash It Out, a podcast built by data security experts. We decipher the data security landscape through honest conversations about today's headlines and tomorrow's challenges brought to you by Virtru. Let's dive in.

This episode of Hash It Out digs into the security gaps hiding in classified collaboration because who had access when they joined may not be who's authorized right now. Virtru and Rocket Chat's Christopher Skelly discuss closing that gap with ABAC. Let's hash it out.

Hello. Welcome to another episode of Hash It Out. Today's topic is how the ABAC security model, who closed critical security gaps in classified collaboration environments.

And we have two thought leaders today with us in the conversation.

If you have not heard of Aback or Zero Trust, you are probably in the wrong podcast, or you're gonna learn something today. So, gentlemen, let me turn it over to you to introduce yourselves and tell us about your respective organization.

Chris, let's start with you. Could you please introduce yourself and explain what Rocket Chat does?

Yeah. Absolutely. So hi, everybody. Chris Skelly. I'm the chief product officer and chief commercial officer for Rocket Chat.

And, essentially, what that means, I lead our organization from product road map through revenue growth. I live and work in Washington DC, and I've been with Rocket Chat for about five years. Now to tell you a little bit about Rocket Chat, who we are, why we partner closely with with with with Virtru. So we, as a company, have been around for about ten years.

We began as an MIT open source project and have now evolved into a commercial open source company.

We are the world's most widely deployed MIT open source collaboration platform, and we operate a dual license model. That's where the commercial side comes in with commercial open source. So for anybody who deploys Rocket Chat, you can just go to our GitHub repo, grab our build, deploy anywhere that you want to.

You are then running our open source version.

If you want to enter into a commercial relationship with us, we provide a license key that you don't have to redeploy. You simply apply that license key in your Rocket Chat workspace, and then you have access to premium capabilities.

One of the things I mentioned in there is that you can deploy anywhere. That has been a central tenet to our evolution over the course of the past decade.

We're very much focused on being completely agnostic. You can deploy Rocketjet wherever you want. Where that's led us to is our two primary customer segments. So the first is defense, intelligence, and critical infrastructure.

These organizations often operate in fully air gapped environments or some sort of network, isolated network topology like Sipper or JWICs in in US government operations for for example. And since they can deploy rough chat wherever they want, they have that flexibility. We've gotten a lot of adoption from those security conscious organizations. The other segment is organizations that are very much focused on digital sovereignty.

That is a big driver for us within the EU. Other types of government agencies, commercial enterprises who are focused on making sure that they have full control over the technology that they depend on, look to Rocket Chat because, again, they can deploy wherever they want within their borders, on their own equipment, on their own private cloud.

And because we are MIT open source, they know that they will have continued access to our platform. So that's a little bit about me, a little bit about Rocket Chat.

Alright. Thanks, Chris. That was a a great introduction. JP, same thing. Over to you.

Who are you, and what does Virtru do?

Alright. So, my name is JP I've been here with with Virtru for about four years. I am a product manager here at Virtru. I'm responsible for, for the road map and and future development of the Virtru data security platform.

Virtru was founded way back in, two thousand eleven, and the the official mission statement is that we unlock help unlock the power of data by helping create a world where data is always under your control. And my job is making sure that we get as close to that reality as possible with each new version of our software. It's interesting Chris talked about open source. We have groups in open source too.

One of our cofounders, Will, actually invented a format called the trusted data format when he worked at the NSA. It has since been open sourced, by the ODNI, and we, used that technology, the underlying technology, to build out a a vast portfolio of services around email encryption. But what has really set us apart is this idea that it's not just about encryption. It's about user experience.

It's about making it easy to get to encrypted content. It's not about just making sure everything is secure. It's about making sure that that someone who is meant to receive material is able to actually access it and read it and do whatever they want with it. We have since we have also recently made a made a significant investment in in trying to solve go back to our roots, right, to solve for problems that that are faced by our national security or government customers and try to solve solve issues for them.

The big thing for us, other than the fact that we are relying on a open source standard called the OpenTDF, which was built based on what was published by the ODNI. It's also that our platform doesn't just do TDF. There's a lot more that goes into it.

It it leverages, the the concepts of attribute based access control. And attribute based access control is a big topic. So there's we have written blog posts about it. There's definitely, a lot of links out there that you can that you can reference.

At a very high level, we built the platform to be a policy decision point, the place where you can define policy and that other systems can reach out to to get, access decisions or any other policy decisions on whether a subject should have access to a specific resource. That's at a very high level what we do. Again, we can go into greater detail as we this conversation. That's it.

Okay. Thanks, JP. Thank you, Chris.

I'd like to start today's conversation by reading something that I pulled off the Rocket Chat website.

It says security has to be proven, not promised. Access should reflect who someone is right now, and every claim should be backed by evidence.

I thought that would be a good way to frame today's conversation because it hits a lot of the things we're gonna be talking about. So with that, let's get going. Virtru and Rocket Chat recently announced a product partnership, and that's generated a lot of interest in the market. And I'd like to ask each of you to describe the partnership from a product perspective.

What is it? What does it do? What's exciting about it?

What value does it deliver to the market? So, Chris, if we can just start with you, then we'll move over to JP.

Yeah. Yeah. Definitely. And and, you know, one of the the things that you mentioned in that quote is, determining who you are right now.

And that's the basic reality. Our customers see this. They live this every day. An access authorization event can't be simply made at a point in time. It has to be continuous.

The real question is, does this person, in JP's words, does this subject have the authorization to access a particular object, a particular resource at that moment in time? And it's a fast moving world, for our customers. You can have personnel who are shifting in terms of their security classification. They can be shifting their the programs that they're assigned to.

You can have really rapidly moving attributes where decisions are made about what data they can have access to if they are on base versus off base, for for for example. So it's always point in time. So the reason that we partner with Virtru is it enables us to deliver that capability. Using the terms that JP was what what was referencing before, we are basically the policy execution point.

We don't wanna provide the the the the decision. So the simple way to look at it is every time an individual who is operating within Rocket Chat is trying to access a particular resource, a room, a file, etcetera, we make a call to Virtru and essentially say, hey. Does this person have the authority to access an object with these selected attributes? If the answer is yes, then we're the policy execution point.

We let them in. We give them access. If the answer is no, we don't ask why. We simply deny the access.

So it seems like a simple round trip, but that segregation of duties where Virtru and j JP will speak more to this, I'm I'm sure, is really the gold source for those attributes in the identity that can, again, can be rapidly changing. All we have to do is ask for a yes, no that's provided back from Virtru, and then we are able to enforce that policy and make sure that we're only providing access to resources that an individual has the right to see at that moment in time.

Yeah.

That was a great description of a lot of zero trust concepts powered by ABAC. Jp, what can you add to that?

I think from a value proposition perspective, what what Chris was mentioning is is exactly what what we're trying to solve for too. There is definitely the policy enforcement point piece of Rocket Chat is making sure that whoever needs access to a certain room or channel or well however you call it, has the right authorization or entitlement to access it at that given point in time. The good news is that Virtru's data security plot platform does exactly that. It actually is able to handle that from from a stateless manner, which means that at when it's asked, hey.

Does this person have access to this room? It actually goes out and gets the right information and makes a decision in real time. So Rocket Chat is providing information about this is the room. Here is here is the level of clearance that someone needs to have to access this room.

There is logic within the word data security platform to go out and and get entitlement information from whatever source is configured. So it could be an ICANN system. It could be an entity platform. Whatever that is, grab information, specifically, like, for example, if JP is trying to get into a room, get to see what JP's entitlements are, validate that, and then provide a response back to Rocket Chat saying, hey.

This person is allowed. The big thing, though, is that customers don't want to have to go and create policy that applies only to Rocket Chat and then try to create a copy of that and apply it to email, create a copy of that and apply it to SharePoint or file sharing. They want one pane of glass for managing policy for access to data in general and and not just data, but data to any resource in general. And Virtru provides that capability of making it possible to have one policy plane or control plane and then allow multiple applications to talk to the platform and use the same logic to get determination of whether something is allowed or denied.

Yeah. It's a great point also, JP. And, you know, Will, we were talking earlier today about an opportunity that involves a lot of different vendors. The standard is not for each of those vendors to manage policy policy administration and policy decisions.

That needs to be lifted up to a single source of truth, and that's what Virtru provides.

Got it. Thanks, guys. That's a really, really clear description. So Rocket Chat is the policy enforcement point.

Virtru is the policy decision point and the policy store that stores a single, control plane for all of the the pets or policy enforcement points on top of that. What, Chris, as you look at, so you guys did a really good job of describing the current product partnership, and I think you mentioned, you're leveraging Virtru's PDP for access to files and and rooms. How do you think about future features? Other you know, what are the next problems that you're trying to solve?

Yeah. Yeah. Great great question. A few of them come to mind.

JP had mentioned OpenTDF. So, open PDF is something that we are new to but starting to to to dig into. Really, paths that we consider when we're dealing with files. One path, of course, is, if our if the users are posting, let's say, attachment files into a particular room from a TDF enabled store, that makes it very easy for us to make a determination based on the the attributes in the TDF files manifest of whether they match the room object required attributes. That's straightforward. That's one of our one of our next steps that we're working on. We also, though, are investigating cases where customers are not using a TDF document store, if that's the right term.

And what we're looking at as a result is if an authorized user is posting a file to a particular room I'll give an example. Let's say that I'm running a program called FluffyBuddy, badass program called FluffyBuddy. And everyone in that room has to have access to has to have the Fluffy Bunny attribute plus apples and bananas. Right?

If they're authorized and they post that file, there are use cases where because they are posting that particular file, we are then going to tag that file with those attributes. This is the reverse flow. So that's one of the things that we're looking at. How can we then TDF that document, add those attributes to the manifest so that if it's shared elsewhere, those those attributes travel with the document.

So that's one one area.

And, you know, two other things that we're we're actively looking at right now, the customers that we work with, the the the the the mission operators, what we often see is not all attributes are created equal. Right? We have public attributes, and we have need to know attributes. Right?

There are certain attributes relating to, let's say, a coalition partner that you know. Everyone knows who that that partner is and the attribute name, but there might be other programs, SAPs, where they are designated as need to know. So we're looking into how do we manage the administration of room settings when there are need to know attributes involved. That's an interesting challenge for us.

And then lastly, know, another problem that we're look that we're studying to determine the best path is object inheritance. Right? So for Rocket Chat, not to get too far into the weeds, but we can have a channel, which is an ongoing, ongoing conversation.

And then you can create discussions, which are children of those channels. So we're enabling the option for the discussion to inherit the attributes of the parent channel, or in cases where that's not appropriate, turn that off. So those are a few of the things that we're we're actively digging into right now.

Got it. Thank you.

Usually, people If I can add to that, Will, a couple of things that that we have We've already thought about and and implemented, which would be awesome to kind of work with Rocket Chat on on figuring out a good structured way of implementing it would be to to play on continue on the the the path that Chris set me on.

So let's say there is this project called fluffy bunny. But let's say that, there is another group that is also collaborating with us, but they don't call it fluffy bunny. They call it, fleecy rabbit or something like that, which is same thing, but it's slightly different in a different language.

And so when if if this were not using a virtual data security platform, just using regular regular ABAC and tags, The the the importance associated with Fluffy Bunny would be so much that VC rabbit would not be able to be recognized as something being equal.

And in inside of the Virtru data security platform, we have our tagging service and a bunch of different functionality that actually makes it possible to do this mapping of what is equal into something else. What we call secret in the US is tagged as n one in Australia, for instance. Yep. And those things don't directly match up if you actually look at documentation and try to pull information from it. Even AI will not be able to do a good job of actually matching those things up. If you're able to put together a set of rules upfront that that make equalencies possible, then it does not matter what the source of the documentation is, what how Rocket Chat is actually choosing to tag something. It will just work seamlessly across, enclaves, enterprises, countries, how we wanna call.

Got it.

I'm used to hearing Paris instead of Fluffy Bunny and Fleetsy Rabbit, but I I like that I like that name. Let's let's drill into a specific problem that pops up consistently. We've nibbled around it a little bit already, but who had access when they were added is not the same as who is authorized right now. Can you can can you guys explain this problem? And is is that gap closed now with with this partnership and this approach, or is it still open? Are there still things to be solved? Chris, let's start with you, then move to JP.

Yeah. Yeah. I I I would say it's it's definitively closed and and addressed, but an area that we that we need to continue to explore as well. And so, again, access is at point in time that an event a data access request occurs, that that's when you evaluate.

We send a call to Virtru. We get a yes or no. So so so that is very much solved for. We do have an interesting case where, again, operation Fluffy Bunny has hundred participants in there.

I'm the commander. I'm I'm I'm posting an an update to the to the team. What you don't want that individual is posting message to be thinking at any moment is, Wait a second. Are these hundred people still accessed, or still approved for this program?

Right? So, an event hasn't occurred. I haven't actually posted the the message, but we need to be able to drive confidence that at any point in time when I'm posting that, only people who are authorized will actually see it. Right?

And it's about kind of speed of collaboration, speed of communication. So one of the things and I think, you know, JP, we've talked to your to your team about about this, is how are we doing that even pre event scanning? So what we actually do in Rocket Chat is we have a regular polling process that is updating based on changing attributes so that if there let's say it's overnight, there hasn't been any activity, attributes have updated for ten of those individuals, and they're no longer part of the program.

What will actually happen, even though no communication event has occurred, we update the room membership.

And that way, it can drive confidence in the people who are communicating that they are communicating to the to the correct set of authorized individuals. So we've really addressed it, and I think we need to also continue to collaborate on the user experience that reinforces that confidence.

JP, anything to add there? Mean, I think that was that was pretty clear. And that Yeah.

I think Very cool.

Yeah. Yeah. Just to pull on or or continue on on Chris' thread of of thought, we've we've modeled the problem as being what could potentially change that could stop someone from being able to access something, and it could be either something has changed on the identity side, which means their entitlements have changed, your attributes have changed, which the source is outside of both Virtru and Rocket Chat. It's coming from some sort of access management or credentialing system.

So we should be able to pull that and gather information about it. But what if someone actually goes in and changes policy inside of our platform that could potentially impact someone's access? We have we are currently working on being able to deliver an event based method of of letting people who might be interested know about the fact that something has changed on the on the policy side. So for example, I'll use a commercial example here.

Let's say that financial, reports are currently accessible to everyone in the finance department, everyone manager on about in an organization. But suddenly, we're going through an m and a, and for a brief period of time, I want to make financial reports only accessible to the c suite and no one else. New stuff that comes out, only c suite. At that point in time, current we our access will work.

Everything will work. The the policy will take effect right away. But any downstream systems like Rocket Chat that has actually created rooms that are based off of these attributes need to be notified of the fact that, hey. Policy has changed.

You should probably go and, like, repole and make sure that everyone who's in your in your room right now should continue to have access. That is something that we're currently working on building out.

Got it. Thanks, JP.

And I know we've we've we've hit this a little bit, but let's let's just be really clear. And, you know, can you guys explain how attribute based access control works at the collaboration layer and, you know, the separation between Virtru, Rocket Chat, and the IDP. The IDP is, you know, not here to represent itself, but just describe what the separation of those roles are.

Sure. I I can yeah. Yeah. Actually, JP, we'll have I will dive into that, I'll I'll add on.

Yeah. Okay. So I can I in my mind, I draw this picture of two halves? Right?

That is the the entity or the subject that is either a person or some sort of agent that is running on behalf of a person or just a process that is running. And then there's the resource on the other other side, which could be a file. It could be a room. It could be, maybe potentially another process that is running.

And as long as both of those things have attributes associated with them, we have the ability to make a clear determination of whether this person or this this entity should have access to this resource. The the way it's modeled in our current integration is that we do have to talk to an external identity provider to figure out what someone's, what a person and what his or her, credentials are or entitlements are before they before we get access. And then Rocket Chat is able to provide us information about the resource that they're trying to access. For example, if it is a person is being added to a room, Rocket Chat has information about that room to provide us, which I'm hoping Chris will provide more details on.

And then we are the virtual data security platform is may able to make a determination of does this room should this room allow this participant in or not? It's pretty that that's pretty much it.

Yeah. Yeah. Exactly. We we we simply when someone is trying to access a room, we provide the user's unique ID, the resource ID, which in that case is the is the room ID, and the associate associate attributes.

We get a yes or no back, and we enforce the policy accordingly. So really simple round trip that adds a ton of value for our platform and other vendors that we integrate with as well. Because as Will was noting before, that way all of the decisions, the administration of the policy is consistent across the entire application layer, whatever that application layer might might be. And then just to note one other integration point that we have is the administrators, the users on the Rocket Chat side.

If they are creating a room and they're attaching the required attributes, we don't wanna store those attributes. Right? We they're they're they're not ours. We wanna access them.

So we do also make calls to Virtru to provide the appropriate list of attributes to the users so that they can set up the attributes on the room appropriately.

That is where our current need to know versus public attributes consideration is coming into play.

Peter?

Hey, So we we've talked a lot about access decisions for people, around people. JP, you just mentioned agents.

How do you think about protecting resources, data, rooms, etcetera, in collaboration platforms when agents are in there?

So I think, I'm going to real there's going to be a lot of recency bias.

I I read a bunch of stuff this morning.

The the creation or the presence of AI in our workforce now has kind of made it made everything faster. It is not okay for us to sit around and wait or or have a delay in a process that makes it possible for us to go and inspect something for security issues.

Agents, as soon as they have access to something, will start will devour all of the data that is there and and basically take it away. So if you don't if you're not making sure that agents do not should not have access to something and they you deny that access at the point of entry, you are potentially going to lose access to a lot of data or or, you know, lose have data spillage happen. So from that perspective, again, we treat from a data security, platform perspective, we treat all entities as the same. It's it's, it doesn't matter if it is an agent, if it is a person.

As long as you have the right entitlements and the attributes associated with it, you will get access to data. Otherwise, access is completely denied. So it's not a reactive measure of we will log you getting in, and then we'll go back in and audit whether you need access to this or not. It is if you are not set up to access this data, you are not going to get access to it at all.

It is it is proactive. It's like we we operate a door, a upfront, before you can get in. The good thing is it's also it can be very fine grained, which means that you can actually set up it's not about this agent cannot access any Rocket chat room. It's more about setting up this policy to say anything.

You can potentially say something like, anything that is unclassified, these agents can access. Anything that is secret and above should have you you're not allowing agents, for instance. And you can actually enforce that policy using Virtru's data security platform, and not rely on, you know, one by one actually verifying whether this person should be added or this agent should be added to this room or not. And I don't know, Chris, if you have more.

Pretty sure you've given more thought to it in the collaboration side.

Yeah. It's a it's a really interesting problem that that we're seeing. We see a few different variations. Our our current base case, we have an agent development kit that can be used to create and deploy an agent in a particular room or multiple or or multiple rooms.

In this model, the the agent is generally completing certain skills on behalf of users. So we treat that truly as the agent as the proxy for the user. And so it's got essentially a look through. So any access to data or an action that will be completed by the agent is governed by the attributes of the user that the agent is acting on on behalf of.

That's the model we're following right now. We're seeing in it another interesting challenge, though, where Rockchat also has the capability to be an MCP server. So let's save a slightly different case where the agent is retrieving data from from a particular room. Right?

At that point in time, if that agent is acting on behalf of a group of users in another room, all of those users need to be evaluated so you get to a least common denominator approach in order to determine whether that agent can access the the data, the the resource, the object in question.

We have specifically been holding on that use that that use case because of the fact that we have a very tight security model, and we're, you know, really trying to to make sure that we have all of the different vectors covered that could come into play.

Yeah. Got it. I think that I think all the insight you guys just provided is gonna be really interesting for the people listening today.

So we we talked a lot about about a lot of new capabilities today powered by a back in Zero Trust, you know, sort of adding new things to the mix. There's an axiom in cybersecurity that, adding security adds friction. Is that the case with any of this that we discussed today?

On the collaborate yeah. On the collaboration side, from from our perspective, it's exactly the opposite. Going back to what I talked about where you have particular participant in a room, if they have full confidence that they know at any point in time that all of the people in that room are authorized to see the information that they're sharing within that room, it reduces friction. It reduces uncertainty.

Also, we, you know, we we support a lot of coalition operations where you have members of different programs, missions, units, militaries for for for that matter who are operating within the same the same workspace.

ABAC continuous evaluation of access actually enables those conversations. So what we're seeing is expansion of use cases where previously those organizations would have to have their own distinct workspaces that creates barriers to to communication. Those barriers are now coming down because you can more easily manage a group of people with heterogeneous credentials all within the same environment knowing that the data is continuously protected.

You mentioned something that, I was thinking when you said it, which was reduction by simplification. So, I think that's that's a that's a clear explanation. JP, how about on your end? Anything to add?

Yeah. I think I would I would echo what Chris just said. Anyone who's familiar with, like, national national security in general knows about the fact that if you have if you're working on a project and you need to bring a new person in, the amount of paperwork that you would have to do to get that done is significant. So I'm sure that this the ability for us to be able to say, alright.

We're just changing we're allowing changing an attribute on on a person's entitlement store, and they automatically now get access to and to all the all of the program material is significantly different than what we've been doing in the past. And and I I know, Will, we've talked about this in the past that there have been exercises where we've gone with the the work through data security platform value proposition of we can reduce the amount of time that it takes to interoperate or, you know, collaborate between, networks from a few weeks down to a few minutes. So definitely from a user experience perspective, I think, first off, peace of mind, you are sure you're ensuring that everyone who is on this channel should be should be able to access this channel and access all of the data.

But, also, adding new people is not that hard. I do have to say, though, it's not all it's not all that easy because there is discipline involved. There is this idea that everything has tags associated with it. All these attributes are defined.

There is a there is a lot of prework that goes into making sure that you have a defined policy, and then there is discipline that each time a new resource is created, a new room is created, a new document is created, that someone is actually accurately marking the those resources with the right attributes. That is not something that comes easily. It is a it's it it's a training problem. Someone has to learn everyone has to learn how to do it.

The good news is, at least for for armed forces and and the ICE the intelligence community customers that we work with, that comes that is already trained. That's part of their regular job, so it it truly works out.

Okay, gentlemen. I think, let's wrap up there. First of all, thank you so much for joining today. I I learned a lot from both of you guys. I think that was a really interesting conversation. Hopefully, the people watching this learned as well. So I'm really grateful for your time today and thank you both.

Terrific. Yeah. Thank you for the time. I've also been advised that operation fluffy bunny is being renamed operation eagle fang. So Okay. Thank be a lot tougher on the next one.

Much much better name. Alright. Thanks, guys.