The complexity of securing applications is staggering: users accessing applications from everywhere, multiple layers of security stacked on top of each other, speed and performance issues, and endless customization requirements that make every deployment feel like starting from scratch. Organizations find themselves managing VPNs, VDI infrastructure, proxies, DLP solutions, CASBs, and remote browser isolation tools, all while delivering an experience that frustrates both security teams and end users. The tools designed to protect us have created friction at every turn.
The fundamental problem is that the web browser, the most common vehicle for consuming applications on the planet, was built for consumer-grade needs. It wasn’t designed with enterprise security, data protection, or access control in mind. They are primarily intended to serve up ads well. This mismatch forces organizations to bolt on layers of complexity that compromise both security and user experience.
In this episode, Braden Rogers, chief customer officer at Island, explains how their enterprise browser platform rethinks application delivery by building security services natively into the browsing experience. Joining him are Nick Ryan, former CISO, and Janet Heins, CISO at ChenMed.
Want to know:
- How can you explain browser-based security to your CEO without getting lost in technical details?
- What’s the actual architecture when delivering applications through an enterprise browser versus traditional VDI?
- How do you roll out a new browser to 20,000 users without creating change management chaos?
- What happens to your existing security stack, like proxies, DLP, CASBs, and RBI tools?
- Can you give users the freedom to use personal applications while protecting corporate data?
- What does the offline experience look like when cloud services go down?
- How does browser-based security handle the explosion of AI models in the enterprise?
- What’s the difference between browser enforcement and deploying a full enterprise browser?
- How do you balance different security controls for different applications without overwhelming users?
- What does vendor support look like from proof of concept through deployment?
Check out the episode for the answers you need.
Got feedback? Join the conversation on LinkedIn.
Huge thanks to our episode sponsor, Island
Full Transcript
[Voiceover] Connecting security solutions with security leaders, Security You Should Know starts now.
[Rich Stroffolino] Welcome to Security You Should Know. I’m your host, Rich Stroffolino. Today, we’re going to be talking about Island and what they’re doing in cloud and application security. Now, the problem that they’re addressing, it’s a biggie, it’s securing application delivery.
Helping us better understand the problem are our panelists, Nick Ryan, CISO at RSM, and Janet Heins, CISO at ChenMed. Janet, I’m going to start with you. Why is securing application delivery still a problem?
[Janet Heins] Well, it’s very complex and you’ve got people coming in from everywhere and trying to access a lot of different things and you’re forced to use a lot of different layers of security in order to make it work. So, something that would be more simplified and straightforward and in our hands would be best.
[Rich Stroffolino] Nick, I’m going to come with you. Why are we still struggling with securing application delivery?
[Nick Ryan] Yeah, I think a big piece of it has always been speed. So, you think about Microsoft Remote App and tools like that where users from different geographic locations are getting a different experience. And then of course, the customization that everybody has and wants with their different tools and plug-ins and all those kinds of things just make it a very sticky problem.
[Rich Stroffolino] All right, well, today we’re going to be talking with Bradon Rogers, the chief customer officer over at Island. To start out, we’re going to need the answers to three essential questions. These are not trivial. So, Bradon, I hope you’re up for the challenge here.
Number one, how do I explain the value of your solution to my CEO? What does your solution do? What does it not do? And what is the pricing model? Can you help us out? Give us the basics.
[Bradon Rogers] Of course. Well, first of all, Rich, thank you for having me today. So, think about it. The most commonly used vehicle for consuming applications on the planet is the web browser. The dilemma is the browser we all use every single day was built for consumer grade needs.
It was not built for practitioners like yourselves or for industry. So, it creates this cascading series of effects. We have to stand up virtual desktop infrastructure, stand up VPN infrastructure. We have to put things in place to give the users access to our application resources.
Then we have to stand up a cybersecurity stack with proxies, DLP, CASBs, remote browser isolation, mobile device management. Take those deck chairs, flip them around, call them Secure Service Edge if you’d like. But we give everybody a really tough experience.
The practitioners delivering apps and services, cybersecurity folks, the line of business have a hard time delivering a service to the users and most importantly, the end user gets a terrible experience.
So, we said, what would happen if we could rethink the browser in context of the enterprise? So, you know what? Build services natively into the experience, giving the user a very natural experience. At the end of the day, it’s an application delivery platform.
What it’s not? It’s not remote browser isolation or the virtualization or pixel streaming, pushing pixels across the internet. And back to your question a moment ago, it’s just very simple pricing. It’s price per user. We don’t care how many devices a user has or how many applications they use.
At the end of the day, make it very simple for an org to consume it.
[Rich Stroffolino] All right, well, we’ve gotten a taste for this solution, but I’m sure there are a lot of questions. The devil is always in the details. So, Nick, I’m going to start with you. What other questions do you have for Bradon and for Island?
[Nick Ryan] My mind immediately goes to the remote app experience from Microsoft, right? So, maybe help me in that context of, hey, you’re pushing, and you did say it is not a in-browser VDI, right? But if I have an on-premise application, can you walk me through what the architecture would look like of how delivery would be given to a user?
[Bradon Rogers] Sure, yeah, so first of all, you think about how the user accesses apps. The first thing they do when they launch Island, they install it on the host. So, let’s say I got to provision a user. They install Island on the host, just like you do your existing browser.
So, you don’t have to train an end user. The interface looks identical. They’re going to log into the single sign-on provider for the organization. So, Entra ID, Ping, PingFederate, whatever it is. And the provisioned applications are going to appear right on the homepage of the browser.
Those apps can be in a variety of different form factors. They could be apps that are SaaS apps naturally.
When you think about a browser, it works naturally with SaaS apps. It might be virtualized apps. You mentioned a minute ago, you might have apps sitting in a place like Azure Virtual Desktop. You might have AWS app streaming. You might have virtualized resources in your existing VDI infrastructures and your environment.
So, we can do published apps, synchronized published apps on the homepage there for those apps that are the thick apps that you want to virtualize. You might have internal resources that are sitting behind private firewalls, that are web apps or command line resources.
So, you’ll use built-in private access, built-in Island to access those things. And then also, you may have some certain thick apps that live outside the browser, and you want a local experience. We can use services that we deploy with the browser to reach outside of the browser to specific thick apps to give both a data protection strategy for those thick apps to put them inside of the policy of the browser, but also connectivity as well for the back-end needs.
[Rich Stroffolino] All right, Janet, I’m sure you have some questions. Let’s jump in there. What do you need to know?
[Janet Heins] Yeah, I mean, I always like to start with the user experience. I know you touched on it a little bit, but the thought of my entire company rolling out a brand-new browser and the people change management. Can you tell me about that?
[Bradon Rogers] That’s also critical in the whole process. And the user’s often the forgotten taxpayer for the things we’ve done to them for ages in cybersecurity. Guilty as charged for some of the previous things that we’ve sold industry that made their world harder.
At the end of the day, first of all, it’s a very natural experience. It looks and feels just like the browser they already know at the end of the day because it’s built on top of Chromium. So, you never have to train a single end user at the end of the day.
So, it’s super important so there’s not any user friction in the process, but we also provide the ability not only to have a full browser but also have an extension that can live in their existing browsers. So, we use that early in deployments often to get visibility and some early control as we figure out the path to get into the full browser.
But there are use cases both for extension and for a full browser, and we provide both of them to the organization as part of their licensing. They don’t pay extra to get one or the other. But again, we can help an org understand what are the optimal reasons for an extension versus a full browser.
[Janet Heins] So, are there currently products on the market that you’re finding yourself replacing?
[Bradon Rogers] Yeah, 100%. Replacing and reducing and integrating too, depending on what the org wants to do. But in cybersecurity, there’s a common stack of some of the legacy type technologies, the proxy infrastructure and data loss prevention technologies and CASBs and remote browser isolation technologies, even mobile device management technology is just not needed for posture assessment, things like that.
A lot of orgs have taken the path of moving from the on-prem resources, so many of those things, they’ve moved more toward cloud-based resources. You think of a lot of providers that provide Secure Service Edge or SASE technologies, seeing both integration to those, so we can tie into those things natively if an org has a big footprint of something they like, but also an alternate path using our own private access without the need for those things.
So, giving a different path where most of the apps go direct to net without having to backhaul through a cloud. So, again, it’s another alternative path and VDI’s a big one. So, “I love my VDI,” said nobody ever at the end of the day, whether they be the end user or the practitioner.
So, that’s been a big one for us.
[Nick Ryan] Bradon, the other thing I’m thinking about, so we have 20,000 users, right? You already know that the friction of the individualism that people want to have and how security is seen as often the bad guys for, “Are you serious? I can’t have my bookmarks?” So, there’s that side of it.
And from a security control perspective, there’s things that we’ve decided not to fight a big battle on. So, for example, printing at home while you’re connected to the VPN, right? So, we’re split tunneling, but then there’s certain applications where we cannot have that and we have to lock that down.
So, I’m kind of curious about how you layer in the different controls based on maybe there’s a token that should only live for X amount of time for this one application, but not everything else. And how you would kind of honor those and then also give the users kind of some of the freedoms that we’ve agreed to.
[Bradon Rogers] Yeah, it’s funny, if you think about the history in my 25 year in cybersecurity, 25-year career, I’ve had a history of working around environments and delivering technology that had this concept of almost a “say no” philosophy. We have to say no to a bunch of stuff.
And when you say no, the end user is trying to find creative ways to get around the system. And at the end of the day, we always said it was important, let’s understand why they wanted to use it so we may provide them an alternative path. But what if we could open things up and say, “You know what?
We have a say yes policy.” You can say yes to personal Gmail, you can say yes to personal ChatGPT, but what at the end of the day, the mechanics inside of the browser in this case, create boundaries between corporate and personal where the user can work with corporate data, they can move data across corporate applications inside of a boundary, but they don’t spill data to personal.
So, they get the freedom to use personal stuff without the risk of corporate data spilling over, and it’s the best of both worlds. The user’s not a taxpayer would say no. At the same time, they get the freedom, and the org doesn’t compromise in the process either.
So, it is really kind of that perfect balancing act where there’s not a compromise that has to be made in that process. And it usually comes at the expense of the end user.
[Janet Heins] It almost sounds too good to be true. So, no friction for the users, reduces my footprint for what I need for security. So, what would you say would be the challenges?
[Bradon Rogers] It’s often when we do a demo of the product for somebody and they see it, they’re gobsmacked. Because it is, it’s a very novel idea. The foundation of Chromium makes that possible now at this point. At the end of the day, I think one of the first things that makes it a challenge right out of the gate is someone that misunderstands what we’re doing.
The idea of this is it’s certainly a safe experience. We build it to live on a device you don’t manage to be able to live safely. But the core concept of it is not hardening the browser. That’s not the problem customers have at the end of the day. They’ve got hardened devices.
The core concept is giving people easy access to the application resources and giving the user a friction-free experience while the org gets a simplified way to deliver the applications and then asserts its will inside of the browser to protect the data, to protect the user as they go to the broader internet for phishing and things like that.
And then also in the world of AI, giving them many of the tooling vehicles that are being promised with things like agentic AI and automation resources, etc., and then multi-model as well, because no org in the future is going to be a single model org.
Everybody’s going to have 15, 20 different models in a large org, like you mentioned, 20,000 users. That’s going to exist all over the place, different parts of the org are going to have different needs. For us, the empowerment part of the story is probably the most unique.
[Nick Ryan] Yeah, I’m curious about the offline capabilities. Do you require an internet connection for this to happen? And then with that, is there a phone home concept for Island? I mean, is there anything that you’re taking back? Because I’m thinking obviously about, we’re putting everything through it.
There’s going to be some data concerns, privacy, and all that.
[Bradon Rogers] Really good question. I think, Nick, at the end of the day, the most unique part of the architecture is the policy lives locally. And a perfect example, a few weeks ago, when the big disruption happened in the world of AWS. Global services were interrupted, people couldn’t get to applications, cybersecurity vendors that had pinch points in the cloud where they’re doing inspection in the cloud suddenly lost the ability to inspect and couldn’t pass traffic.
For us, that disruption, the users just kept working in Island because the policy lived locally. As long as the application provider upstream wasn’t impacted by that or their ISP locally, they could get to the application.
But for the user, the localized experience matters a lot. That really gets into an important part, Nick, that you were leaning into as well. When you get into things like the concern over privacy, the data that we’re seeing, the data we’re managing, we as a vendor, we don’t see the organization’s data because it’s all living locally on the device itself.
So, at the end of the day, the audit events, etc., can either be passed to your Island tenant, enriched and sent off to your SOC, or go straight to your own storage. We don’t ever have to even see the audit events in the process. So, it’s a direct relationship between the user and the app that they’re engaging in that process.
[Nick Ryan] All right, I got another one. I’m thinking about from a practical brass tacks, rolling this out, how does it get rolled out? I mean, you mentioned earlier, there’s kind of a onboarding learning phase, which would make sense. At what point do you uninstall Chrome and remove Edge as a feature for all the user computers, right?
Or do you keep them because they actually might need to tap out and tap in? What does that rollout process look like?
[Bradon Rogers] It depends on the use case a bit, but I’ll give you kind of a basic here. So, we think of things in terms of crawl, walk, run. One thing that’s really important is for the user to onboard themselves, they simply need to know how to go to an app store and download a browser, and most users have done that in their lives.
So, it’s a really easy thing for the user to onboard themselves. Now, one of the things we can do is when the user onboards themselves based on the given use case. This may be a contractor, for example. The contractor use case, you don’t want to remove their existing browser.
That’s their personal browser or their firm’s browser if they work for a third-party firm. You use Island in that particular case for the user to access just the key apps they need to do their job.
So, we’ll use something called browser enforcement we can opportunistically enforce based on certain audiences of users going to certain applications. So, the user keeps using Chrome and Edge and Safari. And in that case here, they’re using Island for critical apps.
But in some orgs, we’ll deploy the extension for getting visibility over the apps and things, how people are using, etc. And then ultimately at the end of the day, using your standard deployment methodologies, SCCM, Intune, Tanium, they deploy the browser to the right audiences of users.
And we may even restrict out certain other browsers entirely further down the path in the process. But it’s a crawl, walk, run. We don’t try to overwhelm the org. You don’t have to deploy it for everybody all at once.
[Rich Stroffolino] All right, we’ve got time for one last question.
[Janet Heins] I was going to ask, what does support look like? So, I’m talking about internal resources. Should we bring Island in, what do I need inside to help?
[Bradon Rogers] I think it’s really important to think about how you’ve worked with other vendors in the past. Your prior vendors in the past, when they engaged you, they brought in a sales team that helped you learn the product and get to know it. Everything was great, the POV went really well.
And then all of a sudden, you transacted and another team of people showed up, and they parachuted in, called professional services. And man, they know nothing about your environment. They don’t know the people. They don’t know the tech. All that six months of institutional knowledge was lost.
And then when you go to support, 1-800-GET-HELP, it gets even worse because they don’t know your environment. They’re asking you basic questions like did you reboot the machine?
So, in our world, we do something a little bit differently. From a service delivery standpoint, the engineer that works with you in the pre-sales world, the POV, things like that, they become your deployment engineer. They already know your institutional stuff.
They learned your SSO. They learned your people. They learned your process. They then own your deployment. And then when they deploy, they own your transition into support as well as the tier one support in your world. And they work with tier two and tier three support.
But throughout that entire experience with Island, your support experience is always shepherded by somebody who knows your environment cold, that isn’t asking basic questions six months down the road about your environment. They’re almost like one of your own people.
And honestly, they become family. You know, in a lot of our deployments, really good friends with people that are involved in the deployment in the customer and our side.
[Rich Stroffolino] All right, Brandon, well, what’s one thing we didn’t ask about that we need to know?
[Bradon Rogers] We didn’t really talk about AI very much. I’m hearing that conversation quite a bit. There’s the starting point, again, crawl, walk, run for an organization, even in AI. There’s the kind of initial conversation is, I got to stop everybody from going on to these random AI sites and stuff.
We’re just a Copilot shop. Well, you may be a Copilot shop at the moment. In the next year or two, you’re going to be a Copilot shop. You’re going to be a Gemini shop. You’re going to be a Claude shop. You’re going to have tools like Lovable and things like that in your environment.
And at the end of the day, you’re going to want to bring those tools to the right audiences at the right time. But you know what never left the environment? What never disappeared? Was all the enterprise requirements to protect the resources and the data.
Just because you decided to adopt all these models, the same things that bind the end user, we want to leverage all those same policies. And guess what? The best part about AI for me is AI’s natural habitat is a browser. And so, when we bring together identity and device awareness and policy and data protection policies, AI fits nice and neatly, very cleanly in that process, regardless of the model being used for the organization.
[Rich Stroffolino] Well, that’s just about it for this episode of Security You Should Know. To learn more, head to island.io. If you have any feedback for us at the CISO Series, send it to us, feedback@CISOseries.com. A huge thanks to Nick and Janet for helping us learn more about Island, and a big thank you to Bradon for your time and being game to answer all of these questions.
And thank you for listening to Security You Should Know.
[Voiceover] That wraps up another episode of Security You Should Know. If you like this program, please subscribe, tell your friends, and leave us a review. All companies showcased on this program are sponsors of CISO Series. If your company would like to be spotlighted and interviewed by our security leaders, go to our contact page on CISOseries.com or just email us at info@CISOseries.com.
Thank you for listening to Security You Should Know, connecting security solutions with security leaders.