Hey everyone and welcome to another Soapbox edition of the Risky Business podcast. My name's Patrick Gray. These Soapbox editions of the show are wholly sponsored, and that means everyone you hear in one of them paid to be here. And today we're speaking with the chief executive of Island, which is a company that makes an enterprise browser. Now they've appeared on the show a bunch of times before, and we've spoken about the general shape and gist of the product. But there's a bunch of benefits, right? So this is an enterprise browser with a full enterprise feature set, unlike the consumer browsers or the consumer-based browsers that most enterprises are using. But you know, you use Island, you get some benefits like you can do endpoint health checking, you can do secure app delivery pegged to that browser, you can do DLP stuff, you can do cut and paste restrictions that are quite granular. So you can cut and paste between these apps, but you can't cut from this or copy from this app and paste it outside. And there's file system restrictions and just really, really cool stuff and granular controls. But something that's happening with them lately, which I find really interesting, is increasingly people are buying them to tick off various compliance objectives and not just cybersecurity objectives. In this interview, you're going to hear Michael talk about how people are able to comply with like labor regulations by using an enterprise browser, which I know technically isn't a cybersecurity thing, but I just found it so interesting that I kind of zeroed in on this part of the conversation in the edit. So here is Michael Fey to kick things off now about how companies are ticking off compliance requirements with the Island enterprise browser. Enjoy.
We can literally show you every click, every type, and any given moment in any given policy structure. So what does that really mean? You are an IT worker. We don't care about 90% of what you do from a compliance perspective, but you just logged into Amazon and you're setting up new users. I can literally track everything you do in that process, and I can send that to the SIEM or your S3 bucket or wherever else you need that. So I can grab data at a very intricate level opposed to having to do it every application. So you could do things like PAM. You can literally put privileged account management on an app that a CyberArk doesn't even know exists. You literally could give that control in place. I can make it so an end user at a call center, if they want to access something, they got to put in a reason. They have to, you know, 'I'm about to go look at your last purchases.' 'Wait a second, we shouldn't have to do that.' Well, in this case, I do. Here's what I have to do from a compliance perspective to be allowed to do that. I put in the reason, I attach the ticket, it's now recording everything I do in there, and then I step off and the end user gets a warning: 'This is all being recorded.' So it keeps them inside the bounds of that. Also, we get a lot of compliance from data flow. You know, how do we ensure that this data can't be seen, this data can't be taken, this data can't be accessed? We could govern all of that: who can get to what from where, and what geography they could get there. And you know, are my people in Germany getting to the German Salesforce, or are they being redirected to the US Salesforce when they fly to the US? Which Salesforce do they connect to? We can manage all of those elements, and it's just extreme visibility.
And how do you manage that though? Sorry, because that's an interesting one that I wouldn't have thought was immediately obvious, which is I am a German person working for an insurance company or whatever. You know, I go to the United States for a conference, and then just via their CDN or whatever, the way that they distribute resources, I'm winding up kind of logging into the wrong portal. How do you actually enforce that in the browser when a lot of this is done via the sort of content distribution networks for those?
Yeah, that's going to be tricky. So we have tenant control to start with. The trickiness you speak of, which I dealt with my bunch of my career, was based in the networking aspect of it. If we want to force a connection back to a given location, we have the ability to do that with policy very easily. So where it really shows up is which G Suite am I going to? I'm a strong organization, I want to bring in G Suite. Am I going to your personal G Suite or my corporate G Suite? Those are very different tenants to us. The German Salesforce is different than the US Salesforce. They are literally fundamentally different links. We can direct that and control that, and the end user never has to understand that. And we can also then control what data they see.
So that's by domain, is it?
It can be. It could be by domain. We can do it direct IP addresses. It can be URL, but we also have network control. We literally have the ability to do a ZTNA connection and take them back to their data center if we want, or take them back to, you know, source IP address.
So is that via like some sort of what we would call like an identity-aware proxy sort of thing, and you peg certain URLs to those proxies? That makes sense.
Yeah, but I will tell you, it's shocking how little you actually have to use the proxy chaining when you have actual control of the real URL.
Yeah, and I just wondered because I would have thought though, when I was talking about CDNs, you know, it's obviously because you're going to get different IPs for google.com in Australia than you're going to get in Germany and whatever. So I just wondered if you were sort of pegging DNS results, you know, to country of origin or how that all works.
Yeah, so most of the companies that really care about this, they actually have a set of privileged IPs they use that you call back to. So like they don't really go directly to Salesforce, they go to a set of IPs, and then... so we can do that, but we also have our own thing that sits inside the DMZ, and we can call that to get access back to data centers.
And I'm guessing what you're saying is that if a user just tries to enter like salesforce.com or whatever, it just redirects them?
Yeah, just user... so that's pretty simple, like it's just redirecting them to the customer's domain. But let's get a little trickier. So now you're dealing with a French organization, and yes, you have the Google, but they can't work past 4:30. How do I govern that? And any interactions, we can't record what they do, we can only record their violations. But when you go over to the UK, we can record everything they do, and they can run all day long, and they're in the same Amazon bucket. How do you set policies for these different flavors? We give you really strong dexterity on that, where even inside your own company, your own geography, you can pick and choose how all this stuff works opposed to a one-size-fits-all model. Identity-based policy is really hard to do with the network layer, really hard. It is. We can do it at the endpoint and really change the way that works.
Well, it's hard to do in the IDP layer as well, right? Because you're sort of issued with tokens that grant you access. But my mind is boggling a little because you just said French people can't work past 4:30. What's that?
So we actually have a French customer that their edict is their access to their applications has to shut down at that because there's a governance on the hours of work that they allow their employees to do, and they literally stop the ability to access their applications at a certain time of day.
According to them, it's a government regulation for them of how many hours they can have in a work week.
Are they in a sort of specialized, ultra-regulated industry, or is this just like... I mean, you know, are you telling me the French people can't work past 4:30? Because that would be pretty cool, you know.
Not all. Well, hey listen, there's obviously French people do that, but the French have a governed hours of work in a week, and you don't take a salaried employee and have them work 80 hours like we do in the US and just say that you're salaried, it is what it is. And they often have to prove that that can't occur. Now, I'll tell you, we have this in the US too in a different way. We have a wonderful customer that is trying to do really right by their employees. They're a fast-food restaurant, or maybe they think of themselves as not fast food, so or fine food or whatever it is, and their workers can go out on their portal and look at the other stores and take hours at those other stores if they want to compete and they want more hours. Right? They don't have to just get the hours at their local store. And they did this to try to make sure their workers could get to full-time as fast as possible going everywhere they want. If they spend more than 10 minutes doing that, you have to pay them for the full hour in California.
Yeah, so here they were trying to be nice, and then they hit this roadblock that says if you spend a while clicking around here, we have this problem.
We govern that relationship. Yes, you kick them out at 9 minutes and 45 seconds or whatever.
And you know, that's something that company needed. Well, they need it next year, policies will change, maybe that goes across, maybe it goes away, and they want that dexterity. The number of bizarre rules that end up in this is amazing. You know, I'll give you another one. We got traders and investment teams that can't view LinkedIn because LinkedIn has messaging and it's not audited and it's not tracked. So they can't. So imagine you're investing people's money, you can't go out on LinkedIn and see who quit from that company that day, which would be a telltale sign of what's going on, where executives moving, where they go. So what are they doing? Well, we all know they're going to see it. They are taking the risk of having that interaction on their own device outside of the jurisdiction of the SEC and everything else they have to be. They're not saying dumb to that information. We make it so they can go to LinkedIn, but we record that. If they do happen to have a chat, we can record that messaging, or we can block the messaging in the first place. Something you can never do at the network layer, figuring out which stream that is. That actually has been used a lot. We've had others that want to do Zooms and they want to make sure no one can do screen captures on the Zoom, nobody can upload a document or download a document or put something in the chat. And that last-mile control shows up in so many ways that aren't cyber. It's amazing what can be done with that.
Yeah, I mean, you're actually really selling it on the compliance stuff because, you know, just those use cases that you're talking about in finance, I mean, eventually, you know, that can pop up in investigations, right? Like you're being investigated by the government, there's a few screen recordings lying around, you know, that's not good. They shouldn't have been taken in the first place, and they can incriminate people. And even if they're not incriminating, they shouldn't have been taken in the first place and like incorrectly stored and all of that, right?
So Patrick, one of the things we added on because a customer built it and we made it part of our product after we saw it, they put a QR code in the watermark. And the QR code would say what machine, what user, you know, what was going on when that QR code showed up. So if you pull out your phone, you try to take a picture of your screen, and they find it on the dark web or whatever, they know everything about the leakage.
