Risky Business - Risky Biz Soap Box: Why enterprise browsers are good, actually

Episode Date: December 11, 2023

In this Soap Box edition of the Risky Business podcast Patrick Gray talks to Island’s Bradon Rogers about security-focussed, enterprise browsers. You can use Island to do stuff like grant third parties access to corporate applications on unmanaged devices in a not insane way – that’s a huge pain point for a lot of CISOs, and something that is bringing a lot of new customers through Island’s doors. Obviously for devices you do manage, you can roll Island out as your default enterprise browser. There are a lot of security benefits to doing that.

Hi everyone and welcome to this special Soapbox edition of the Risky Business Podcast. My name's Patrick Gray. And for those of you who are new here, these Soapbox editions of the show are wholly sponsored things. We do them like once a month. If you're looking for the regular Risky Biz Podcast, just scroll back one in your podcast feed to one of the numbered podcast editions. They're the regular weekly shows. But yeah, the idea for these Soapbox shows is our sponsors get to come onto the show and talk about their products, more or less, or how they see the world, or what they're trying to do.

And today we're hearing from Brayden Rogers from Island. And honestly, hand on heart, Island is one of my favorite sponsors to talk to because they're actually doing something really quite different. They have created an enterprise browser that is doing really well out there. It's got use cases that directly address some serious pain points CISOs are dealing with. And yeah, not only is it different, but it's ambitious. It's a big idea, not a little idea. And I really admire that so yeah you could use Island to do stuff like grant third parties access to your corporate applications from unmanaged devices and you can do that in a way that isn't insane and

that is actually quite easy and that is a massive pain point for a lot of CISOs I know and it is something that is certainly bringing a lot of new customers through Ireland's doors and obviously for devices that you do manage inside your own enterprise, you can roll it out as your default enterprise browser and that is obviously the other big use case or deployment model, right? Now there's a bunch of security and data protection benefits

that stem from doing that in your own enterprise. And I'm not going to list them here in the intro because Brayden does a great job of talking through that in this interview. But yeah, it is very, very useful stuff. And as you can tell, I like this tech and I am 100% drinking the Kool-Aid, guilty as charged. Now, Brayden is the Chief Customer Officer at Island, and we started off this conversation by talking through who's buying the Island browser right now and what they're using it for. And here's what he had to say.

I hope you enjoy this conversation. So every industry has some common use cases, and there's some very unique ones. So we're seeing a lot of traction across financial services. Obviously, usually they're early adopters. A lot of those guys like to test the waters on emerging technologies to give them an advantage. There are certain use cases in places like financial services that make total sense, things like their contact center environments.

Obviously, they're taking inbound calls from customers who have questions about their services, et cetera, and they've got to solve problems. Well, they need to be able to access sensitive data too, and never be able to do anything with it beyond look at it on a screen, right? So that's... Yeah. And so like, that's a perfect example of the least common denominator they've come up with an agreement on that they could solve with was, all right, security needs to contain the data in the applications while someone has to give access to the applications. So these two teams have to navigate that.

And the thing they navigated it to was things like virtual desktop infrastructure. Obviously, the user experience in those types of environments always suffers. The practitioners don't love it. And honestly, it's just long in the tooth for a lot of folks. And so that's a perfect example of a way to give someone a more natural experience i mentioned contact center because you also have the the overarching issues around things like voip that play into that in the contact center environment where the voice trying to run that through a vdi infrastructure is very painful i've had orgs that have created infrastructure to work the voice over ip around the vdi in some very cool way you you yeah you wouldn't really run it over VDI, would you?

You'd have to have some sort of VDI client sitting next to the VoIP client, and that doesn't sound like fun. Exactly. It's ugly. So just onboarding those people is challenging. But back to your question originally, it's contact centers, client advisors and financial services, where there are oftentimes third parties that have contracted with you to be your advisors selling your portfolio of products. You get into healthcare. It's a very similar type of

story. They just call them something different. Practitioners, clinicians, and others, you know, particularly here in the States where these people, they don't work for the medical organization. They don't work for the hospital. They work in their own practice and they're contracted out to the hospital. They provide their services in the hospital. So they're often using devices the org doesn't own. So, you know, you get into healthcare, you get into manufacturing. Oftentimes there's third party servicing equipment. So that third party use case is very common. And I think the even subtlety beneath that is they're often using unmanaged devices. That's where the challenge, that's where the ugliness comes into play. Yeah, yeah.

So, I mean, the idea being that the Island browser actually does have some host integrity checking built into it. I can't imagine it's, you know, I imagine it's comprehensive enough to help you sleep a bit better at night. But, I mean, it does just deploy with user permissions, doesn't it? So it's not really going to be able to, you know, tell you if your kernel's doing something funny.

Yeah, that's great insight. So, you know, there's a duality to that. The installing in user space obviously gives us less friction in installing, as you might imagine. Well, I mean, that's why people are buying it because it's so easy. You can just send them a little package, they double-click it, and then they've got access

to the thing that they need to access. So, you know, I definitely, if you have to pick a way to do it, which is like deep system access and difficult to deploy versus user access and a lot easier, but maybe a little bit less comprehensive on the host checking side, I mean, you're going to do it the way you've done it. Yeah. And you can certainly use it to assess the device to see if some of those things are there though. So obviously if you live in a critical care environment, and you need to know that there's a particular type of control in place, you want to know that it's got full disk encryption turned on. It's got a, let's say a crowd strike or something like that enabled on

the machine and is it current? Those types of things we can assess as well. So a lot of these other checks are there. Yeah, you know, you think about a lot of these third party orgs, though, they do require they sign agreements upfront with their partners that are accessing their environments, and you're going to live up to the standard. And oftentimes, those are paper agreements. In fact, I'm working in one org right now where the part of the agreement is they have things like full disk encryption turned on, and

they're finding a high percentage don't have it turned on shockingly enough. Again, you think about the third party they're working with, not often a technical audience on the other end sometimes, so they don't even know how to do those things. So onboarding them, shepherding through the process, coaching them how to enable it so they do have appropriate access and governance can be an important part of it.

So let me ask you a question now. So in the case where you said, okay, say a clinician, like a doctor, a specialist, like an ophthalmologist, a hematologist or something needs to consult on something for a hospital, and they've been given Island browser pre-configured to access a hospital system so they can access patient records and things like that. I'm guessing that browser instance, it can only access those hospital systems? Is that the way people mostly deploy it? So they're not looking at patient data using Island in the hospital,

and then the next minute they're off reading articles on the New York Times using Island browser. Is it like domain locked usually? Is that the way people do it? It usually is. So think of it separated into two sides of the fence. There's the managed side of the fence and managed side of the fence. Oftentimes we're doing full deployments. Every user gets the browser and that managed real estate. And not only are we protecting the corporate apps, we're protecting the user for when they're going to places that are,

you know, gray area places that, you know, might be uncategorized. Your traditional proxies will block uncategorized or allow uncategorized or send a remote browser isolation. We'll say, you know what, for that situation, go into shields up mode and don't let the user plug in the corporate credential to something that's maybe a gray area or something like that. So we'll protect the user in that place. Go to the unmanaged real estate, which you just called out, Patrick's perfect. The user can keep using Chrome and Edge because it's a device you don't own in the first place. In fact, you may want them using Chrome and Edge because that's what it's a device you don't own in the first place. In fact, you may want them using Chrome and Edge and Safari for their personal stuff and non-critical work. And you may need to enforce when they're going to the critical application that they're using the appropriate path. In this case, it's Island in that case. And therefore, to your point, they may

only use us just for the critical applications, the critical patient care applications. But is that how people typically deploy it in those circumstances so that it is like domain locked to that one thing? It is? Indeed, when you get into the unmanaged real estate. So when you get into the unmanaged real estate, we pre-populate the provisioned applications for the user based on the context of the engagement. Context, usually identity-based,

you know, like the role of the user, for example, the device that they're on, et cetera. So the browser will say, hey, here's your entitlements. No more than you need to do your job, no less, and often pinned down into those areas. And if you want to do personal stuff, great. You have perfect privacy. Go use Chrome and Edge and Safari and whatever you want.

Yeah, yeah, yeah. Go use Edge-ium. Go away, basically. I had a conversation with Adam Boileau, you know, my regular co-host on the weekly show here. i i mentioned that we had this interview coming up and i'm like what are some you know questions that you might have for island and he and he wondered and it turned into an interesting conversation because he said look i wonder how they decide if they're going to cut certain risky features from chrome when they're packaging because you use the you know chromium

uh source, for your renderer. So he's like, well, do they actually chop stuff out to minimize the attack surface? And I said, look, I don't know, but I don't really think that's what, you know, people aren't buying Island to have a browser with a smaller attack surface. It's more about like, as you said, you know, those features that stop corporate users putting their credentials into phishing sites and stuff like that, as opposed to trying to minimize the chance of, you know, zero day exploitation. But I wanted to ask you about that. Like, have you actually removed functionality from the rendering, you know, from the rendering engine when you've incorporated it? Or does that depend on which customer it is?

Is that an option? Like, what have you done there yeah so what we do is we we instrumented mechanics into the browser where we can opportunistically make them available or not depending on the scenarios the contextual engagement so i'll perfect example and i mentioned this a moment ago but i'll use it again and i'll kind of make it more applicable here you know you think about your proxies that we've used for years. Now I came from the blue coat side of the house many years ago and we lived this first, you know, firsthand when something was uncategorized, you blocked it. If you wanted to stop something that was uncategorized until it was properly

categorized by the vendor. So you could trust it or not. Um, when something was uncategorized, you could allow it. And if you allowed it, you would encounter the possible dangers of stuff that was drive-by and popped up this morning. And the users think it's something legitimate and it's not, but you just allowed it. So you create a risky surface area for users to be able to touch. There's been this emergence of things like remote browser isolation technologies, of which our co-founder is one of the inventors, holds a lot of the patent work on that front where you say instead of blocking or allowing uncategorized force it over to a remote browser isolation experience and then now we stream that experience back to the end user with the browser itself we can control all the mechanics in the

browser itself the underpinnings itself so certainly i can govern as i mentioned a moment ago governing the inputs of the browser so i don't want the user to throw in corporate credentials into a place that's not categorized. It's gray. We don't know about it. But I can also do some other things. So I get to control the internal mechanics of the browser as well opportunistically. So what I can do is I can make things that are the general quote unquote attack surface of that browser unavailable. They're inaccessible when a user goes to something that's gray. For example, removing the just-in-time compiler, the web assembly modules, the JavaScript APIs in the browser that, you know, in theory, someone remotely could inject into those processes. I just make them unavailable. I give the user the

ability to go there, but I just make the machinery of the browser itself unavailable. And, you know, in an attempt to make that a safer experience as a user, you know, makes their journey to something, you know, that may be that kind of gray area on the outside. So it gives me kind of this, this nice little area to live in. And then, you know, let's kind of reverse it. Think about while we built remote, remote browser isolation and the like, we couldn't control the internal mechanics very effectively. So we wrapped things around it because they were risky. So when something happened, it was contained in some way or another, whether up in the cloud or on the machine itself with those old safe browsers from many years ago. We've just taken the reverse approach to control

the internal mechanics as a result of that when someone goes to something that may be a little less than desirable. Yeah, I mean, that makes sense, right? I mean, doing a result of that, when someone goes to something that may be a little less than desirable. Yeah, I mean, that makes sense, right? Like, I mean, doing a lot of browsing on something, some ephemeral browser that's going to be blown away, you know, after you're done with it. I mean, that's good. But I didn't realize you were doing that stuff, like, you know, disabling the JIT compiler for certain things.

So is that something that people control through policy, is it? So they might say, like, unless you're going to these allow listed domains, you want to, you know, disable JIT. Is that sort of how people do it? 100%. So, you know, when you're going to your trusty corporate application inside the environment, well, we know what that is. We know what that path is. We know that's legitimately the application. You go to Office 365. We know what those destinations are. We legitimately know what they are. The user can't discern them because, you know, the fake site versus the legit site look the same to the user, but the browser knows the difference between the two. and we know it's not trusted or something that's in that gray area, that just opportunistically gives me a different path

that I haven't had in the past with other technologies that I've, you know, again, my proxy footprint or other things I used before. Yeah, so it's really interesting that we've got these two quite different use cases, right? Where there's the unmanaged device use case where a medical specialist needs to, you know, access hospital data.

So you ship them them yeah a a version of the island browser that is pre-configured and they double click it and bang off they go um you know that's that's real nice and then you've got the other one which is uh the other use case which is it's a managed device and everyone in the enterprise is all of a sudden using the island uh browser and you've got all of these policy tweaks and things you can you can do so i'll have more questions on the unmanaged stuff because i find that one really interesting uh in in a little bit but i wonder as i understand it and i don't know if this is still the case it's been the case that when people first come to island it's usually to solve that

use case around the unmanaged devices right like? Like that's the thing where they have a burning need and they just come in and go and say, oh my God, please just, you know, we need to buy it for this unmanaged device use case. And then once they've had some experience with it, they start looking at it for internal use. Is that still the case? Is like that how the business is playing out for Island?

It's certainly low hanging fruit. And because unmanaged falls in. Unmanaged, you mean? Yeah, right. It's certainly a lowhanging fruit and because unmanaged falls unmanaged you mean yeah right it's certainly a slow-hanging fruit for a lot of orgs because especially your very very large orgs the the high end of town on financial services or in health care etc they've got a ton of that stuff and they've struggled with it and then you know and then again those unmanaged come in a lot of flavors i mentioned some examples earlier but they continue coming in different flavors sometimes Sometimes they're mergers and acquisitions. You're acquiring a company on the other end and they've got their devices. You don't manage them. They've got controls on their end. They have their own CISO on the other end, but they're not your devices. So how do you onboard

them effectively? Because, you know, you, you ship typically in an acquisition, you would ship them a device. So I, you know, I don't know if Patrick, if you've been acquired before, but I've been acquired many times, and I wind up with two laptops on my desk, one with one company and one with the other, and it's a painful experience. I'm emailing documents from one side to the other side to have them available to me and things like that. This makes those types of onboarding experiences

a lot easier up front in the M&A type scenarios. But again, that unmanaged thing is definitely a low-hanging starting point for a lot of work. But is that where you're getting most people coming through the door? I mean, that's really the question, right? Because it was. I remember it was. It's a combination of that. It's a combination of that. And then there's a subset use case that falls into that, but also falls outside of that. It's VDI. And so VDI is usually an implementation detail for how you're solving a use case,

but oftentimes it kind of bleeds into unmanaged, unmanaged, and people are like, you know, it's incredibly expensive. It's very painful. We're not in love with it. The end users absolutely abhor it. So how do we find an alternative to that? So sometimes it's solved. So people are what?

They're doing rip and replace on stuff like Citrix with you? Quite often. Quite often. You know, let's start with, first of all, they're doing reductions. So at the end of the day, it's kind of the 80-20 rule in your heavy environments. 80% of the apps are web-borne. 20% can be something else. So it's easy to move the web-borne apps off the compute for VDI and just save substantially the effort and the user gets a good experience.

On the 20% side of the house, that's where we do the examination to figure out what fits a browser model appropriately and what doesn't, what could run in our RDP client built into the browser, what may stay inside of VDI rendered over HTML5 in the browser, but the browser can become the client in that front end. But I mean, Citrix, so this is interesting, right? Because Citrix, we were having this conversation

before we got started and I didn't know this, but you can render stuff in HTMLtml5 from citrix right which is which means you can actually access your applications over a browser using citrix but as we well know at this point exposing citrix equipment to the internet uh not really a good time um but you're able to actually act as a bit of a, you know, you're actually able to sit in front of the Citrix gear and, you know, only island browsers can access the Citrix equipment, right? Because you've got sort of cryptographically enforced access control. Is that correct? Indeed. So in theory and in practice, actually, we're doing this in several shops now where orgs have had externally exposed VDI infrastructure. And, you know, call it VDI du jour, whatever it may be.

Yeah, not just Citrix. They're all terrible. They're all equally as bad. But yes. Yeah. So you've exposed that infrastructure to the Internet with, obviously, recent news. You had a variety of different pieces of infrastructure exposed to the internet broadly. And exploitation occurred of that infrastructure and caused issues for organizations.

So one of the vehicles we can leverage is, number one, the fact that the browser can render most of your common VDI infrastructures over HTML5. Those infrastructures, all your modern ones support it. Means the browser can be the client as an alternative to the traditional thick client. So what it empowers you to do is take that infrastructure and pull it back away from the internet out of your DMZ or wherever you have it placed, expose the internet, pull it back to the infrastructure, and then leverage private access vehicles that the browser understands. One we have is called Island Private Access. There may be others that orgs may leverage for their ZTNA capabilities,

but then expose the path of those applications only to our browser in that particular case. So you have to authenticate to our browser. The browser will assess the device, make sure you're living up to the standard, assess the device to see are you on a company-owned asset, have a cert in the search store, et cetera. And then, therefore, the surface area that can access that particular set of resources inside the environment is only limited to the browser itself

in the appropriate authenticated way so you basically got like an island you know proxy sitting in front of it right right yep exactly so if you think of it that way exactly right what private access is indeed yeah yeah because i mean previously i think i had someone from excuse me i had some from ireland talking about how you can restrict access to only island browsers and whatever and they're like oh that's dumb they're just doing it with a user agent string and i'm like no that's not how they do it stop you know it's just amazing to me how many people and i mean like rusted on infosec people who've been around forever just automatically assume that you guys are all idiots

uh because you're creating an enterprise browser and they're like oh they must have done it the wrong way and i think that's because if someone had have tried to do this 15 years ago they absolutely would have done it uh in a really really dumb way but no you are not using user agent strings to restrict uh the type of browser that can connect to a device. You've got some crypto magic in there, right? Well, first of all, I think anybody that's been in the industry long enough knows user agent strings are what they are. They're good for some things, and for many, many other things, they're probably not the appropriate vehicle to validate something

because they're easily spooked. Yeah, and I think a lot of what you're talking about comes from there's a lot of history in the industry, right? I mean, there's a lot of people that were burned 10, 15 years ago by this, that, you know, the earlier secure browsers that were wrapped in virtualization componentry. And then we took browsers or moved them up the cloud and created things like remote browser isolation over time. Which still is quite handy for certain things, right? I mean, you're using it, so yeah. 100%. I think, but the key is, it's no one's really imagined, what if we were to do, take the alternative path,

is leverage the mechanics of the browser. You even made the comment a minute ago, now that I can control the energy of the browser itself, it lets me rethink, now I can deliver services natively in the browser for a cybersecurity practitioner or a data person that has to protect the data in the applications. But on the other side of the house, for people that have to deploy applications, put them in the hands of the right audiences,

give the user a good experience, deploy productivity for the end users at the end of the day. Obviously, you know, I've got contact center workers that move data all day long from point A to point B, copying and pasting the same rudimentary data. What if I could move that data automatically for them in the applications? What if I could give you the ability to have services that expose the performance or the utilization of apps before users ever open up help desk tickets? The powerful part about the browser is

if you think about the strategic position, the physical position it sits in, it sits in a very unique physical position relative to the user's eyes before data hits the glass of the screen. By being able to build mechanics that live at that presentation, the true presentation of the browser itself,

I can govern and do some unique things where policy follows the user, but at the end of the day, I can give unique actions as a result of that as well. So it is something different. I think it usually takes a few minutes for somebody that's been in the industry for a long time to initially wrap their head around. And I always see practitioners, I mean, it happens on almost every call,

practitioner who's dyed in the wool against it right out of the gate and they come around within five to ten minutes of just seeing it. When they see it, then their brains are going off on what other things it could solve in their environment. But it is a fun thing to watch the facial expressions and the change of posture of people once they get a chance to see it. That access through the proxy, though, is that like some sort of SAML-brokered SSO-enabled, you know, sign in with Okta sort of thing, and then you get a session token and off you go? That's how it works? Yeah, there's a couple of things.

So let's put things into two categories. There's browser enforcement, so you're building Force Island. It let's put things into two categories. There's browser enforcement. So you're building Force Island. It is indeed us at the end of the day. And that's the browser and needs access to key application. But it's also that it's an officially provisioned instance of Island, right? And that's done actually with some key material, is it? Yeah, 100%.

So let me flip. So the other side of the fence is the private access vehicle. Yes, yes, yes. So let me, I'll hit both of those. Because private access can be an enforcement vehicle as well. Yeah. First of all, when a user downloads the browser, the user goes through an authentication process

with your single sign-on provider that basically ties the browser to the appropriate tenant and creates an appropriate exchange, a web token to the browser. So the browser now trusts the appropriate tenant in that particular case. The user then authenticates and as they go through the authentication process, the browser gathers its policy. It just basically pulls the policy from the tenant and says, hey, you know, what am I beholden to? In that, it's gathering things like, you know, what type of device do I need to be looking for?

What, you know, is there a geolocation policy around it? Does it have to be on a certain network? So it's gathering all the elements for the contextual nature of the engagement to say, what do I need to govern? And then it makes the decision based on those things, what apps to provision for the user? What do we make available to them? What's permissibility within those apps? What data protection policies? How do we keep them safe? All those things as well. So it's a whole series of things that happen in that process. Going back to the beginning of your question, browser enforcement can happen in a few different ways. Obviously, the browser itself is via single sign-on provider using conditional access policies. So everybody's got it. It's easy to use and it's got a lot of flexibility. So we'll just build policies and say for this group of users going to these applications, you know, so we can do subsets. The browser, the client they use for those applications has to be the

island browser. So the powerful part is, you know, when you get in the managed world, enforcing browsers is really, really easy. There's 10 different ways to do it. You get in the unmanaged real estate, that vehicle I just called out as a really elegant way to do it because they, they can use Chrome and edge and Safari and you can't stop them. But when they go to the key application, the SSO working in tandem with island policies is nope.

You had the browser you have to use as the island browser for that. So we can gracefully glide them over into that particular usage model. Yeah. Yeah. One question I got though is now, you know, I said I had another question about the, the unmanaged stuff.

What if you're a, say you're a hematologist or a, what are the cancer doctors called? Oncologist. You're an oncologist and you consult to multiple hospitals and all of a sudden multiple hospitals want you to use Island. Are you going to have a different instance for each hospital or are they going to be combined? No, it's actually funny you're bringing this up.

This is coming up a lot where we've got multiple orgs. Yeah, I figured it would, right? Yeah, it's coming up everywhere right now. I'll use an example of where it's coming up in business process outsourcers. So when you outsource your call center to this third party, we've got multiple Island customers that are outsourcing to the same call center companies. And they've got a, they've already got an instance of the browser installed on a machine. And this is also coming up in healthcare as well. We built mechanics into the browser. We can have, you know, multiple identities using the same installed instance of the browser at the same

time. In fact, a lot of times in my day-to-day work i'm actually logged into two different environments using the same installed browser so so it's sort of like chrome with different google profiles right yeah yeah i wonder i just wondered if you'd built that feature yet because i'm like i could immediately see people are going to be asking for that yeah i'm i you know in a lot of my demos during the day i'll be logged into my demo tenant where I've got all my policies. I build to build things for the specific user need. And then I'm also over here logged into my Island world of my real applications we use. It lets me create segregation of duties in those ways as well. So that data doesn't spill from one environment over to the

other, et cetera. But it's also very useful. I mentioned that M and a use case where you've got a user that may have to log into two different environments. They don't necessarily want one window yet for the users, so I could do things like that. Or multiple personalities, that clinical environment. You've got users that walk up, use the machine for a moment, walk away. Somebody else walks up and logs in. So you can simultaneously support multiple users logged into two different environments, but also multiple users can use the same shared device in the process too. Yeah, yeah.

Now, I've got another question about what I'm guessing is a feature request, which is in the enterprises where you're on managed devices and you're on a lot of corporate devices, I'd imagine that there are going to be teams working at those enterprises who want to instrument the browser in some way. They want to be taking logs from the browser, activity logs from the browser. Is that something you've come up against yet? Indeed. And the question is, what are they asking for?

What sort of telemetry are people asking for you to provide them out of the browser? Crazy spectrum. So first of all, on one end of the spectrum, they want no telemetry, meaning fully private browsing. The user going to their personal banking, like their chase banking. I want to let the user feel like they've got the, the sanctity or the safety of no, no, no organizational monitoring in this case.

So the browser will say, you know what, you're going to this area of the internet, these types of applications, these categories, whatever you have full private browsing, but I can keep corporate data safely from safely spilling over there. You get into the middle area where you say, you know, I've got users that live in this particular geo. So contextual contextual awareness is really important here. So a user operating, let's say in Germany, for example, if I want to anonymize certain engagements,

I can get telemetry off the user's engagements. Maybe I need to know things like the, the, how often people are using certain types of apps, what is their use of the apps, et cetera, but I don't want to know who the users are. Doing things like anonymizing those types of engagements can be quite important. And then, you know, you go to, back to your question, you know, you go to really highly regulated, you know, privileged environments. You may want to know exactly what the user touched. You may want to know the screens they engaged. You may want to capture where they click their mouse, or you may even want to capture their

keystrokes. So those types of possibilities are in play as well from audit logging. So it's not, unlike a lot of environments I worked with in the past, where it was kind of a very fixed state that the logging was in for the entire real estate, and you gathered everything for anybody that went through the proxy, you got the same level of logging this one will dynamically adapt based on this the situation but also for the user it's important because a lot of the a lot of the places we're working the users have this proverbial right to know so the ability to communicate to the user proactively so you're engaging here here's the level of monitoring that's going to be engaged for you just making sure you're aware of this where there may be some legal requirement to do so one thing i wanted to bring up though because it's something that i haven't

brought up previously in conversations with people from ireland and i actually think it's one of your cooler features is that you can create rules for where data can go through the browser right so so this user can download data from a business application and they can send it to dropbox because their job requires that but other users can't or they can send it to g drive but not dropbox or whatever so you can actually start creating uh policies and rules based on uh what the browser can do with data like i can grab this data save it into some what is it like temporary storage uh just start explaining how all that works yeah so so first of all let's talk a little bit about data protection and this is coming for somebody's work with dlp for 20 years um oftentimes we would engage a dlp project for you know our goal is to protect the data but

we would say all right let's let's talk a little bit about the things we want to protect. There's easy stuff, Canadian health ID numbers, social security numbers, the U S you know, credit card information. Okay. We hit these little things. We build regexes all day long and dictionaries. And we kind of run out of those things at some point to build. And then someone gets clever and says, let's train on the documents in our environment. We're going to train the documents and hopefully it gets intelligent about identifying the right documents. And 10 years later, we're still training on documents and we're still failing and feeling like we're struggling. And part of that is that we're starting with the most difficult part of the process first.

We're starting with the actual pieces of data. There's trillions of possibilities of data in many environments, right? So what you call out is a great starting point, starting with the application footprint. So what I'll do is I'll build a policy that says, look, what's the footprint of corporate applications that this user is working in? And internally and externally, we use language. We call it, what is the island they're working in?

Kind of a cute little language there. But it's, you know, I want organizational data to remain on the island. I don't want to. I think I just remembered the way you handle data locally as well, right? Which is you can write it to disk, but it stays in the island sandbox and you can't like USB it out or do anything that's not allowed by policy. I just remembered. Sorry, I had a brain fade. So this is great. So good segue there. So obviously the user, I want to let them use things like copy and paste and file movements and engage the right printers at the right time, et cetera. Context will drive that. I mentioned earlier. So who the user is, geolocation, all that stuff. When they engage the corporate

application footprint, I can let them freely move data, copy and paste data from a corporate app over to a person or a corporate app over to another corporate app. When they try to take the data beyond that over to something like instead of corporate G suite to personal Gmail, you know, I can say, no, you can use personal Gmail, but you can't bring the corporate data there in that particular way. Um, so that's a good example of copy and paste. We can do similar things with secure storage. So I can leverage things like, there's several different vehicles for this. Obviously orgs have invested a lot of resources in their own storage vehicles. Things like OneDrive and G drive and, you know, box and other things like that. So I can have

Island tied in natively when the user clicks to download a file. Instead of the file hitting the disk of the machine itself, the browser will force a redirect to the corporate storage standard so the user can access the file but only via the secure storage standard in question. We also obviously build local storage. So instead of save to disk, it's save to Box

or save to Drive or save to OneDrive, yeah. And that's one alternative. And then there's local storage. So instead of save to disk, it's save to box or save to drive or save to OneDrive, yeah. And that's one alternative. And then there's local storage as well. So the ability to secure, send the file down to the disk, but to encrypt the file locally where our browser only has access to that. And then obviously some of the work we're doing

around how other external clients can access that. That's some really interesting work that's underway right now. All right, Braden Rogers, thank you so much for joining me for a discussion about Island. I mean, I think, you know, listeners would know that I generally like to work with sponsors who are doing things that I think are, you know, kind of different, right? And Island certainly is that. And, you know, I find it a really, really interesting product and real curious to see where it's going to go. Thanks a lot for joining me for our last Soapbox of 2023. It's been a real interesting conversation. Absolutely. My pleasure.

Thank you, Patrick. That was Brayden Rogers there with a talk about Ireland. Big thanks to him for that. And big thanks to Ireland for being a sponsor of the Risky Business Podcast. And that is it for me today. I will be back tomorrow with the last weekly show of the year. But until then, I've been Patrick Gray. Thanks for listening.