What is Isolated Browsing – on the Exploring Information Security Podcast
Solutions

What is Isolated Browsing? Q&A on Ericom Shield™ for Secure Browsing

Director of Product Marketing Daniel Miller discusses isolated browsing on the Exploring Information Security podcast.

Senior Software Security Engineer Timothy De Block hosted Ericom's Director of Product Marketing for a live Q&A on the Exploring Information Security podcast to learn more about remote browser isolation using Ericom™ Shield for Secure Browsing.

Remote isolated browsing is a fresh new approach that uses remote containers to provide users with a browser that is completely separate from the endpoint. This has the advantage of keeping browser-borne malware off endpoints, so it cannot penetrate the corporate environment.

Listen to the live recorded interview to learn how Ericom Shield helps IT and security professionals harness the power of isolation to secure the browsing experience, while allowing employees to enjoy a seamless and native web browsing experience, on any device.
Click here for the full transcript.







Transcript



Timothy De Block: In this episode of the Exploring Information Security podcast: What is Isolated Browsing?

Welcome to the Exploring Information Security podcast, where you will learn, explore and grow your security mindset. I am your host, Timothy De Block, and in this episode we will be exploring “What is Isolated Browsing?” Joining me today to help answer this question is Danny Miller, Director of Product Marketing for Ericom. Danny, how are you?

Daniel Miller: I'm doing great. Thanks for having me.

TDB: So let's go ahead and jump into it. This is going to be the toughest question; I'm sure you've been on plenty of podcasts to answer this. What is isolated browsing?
TDB: So let's go ahead and jump into it. This is going to be the toughest question; I'm sure you've been on plenty of podcasts to answer this. What is isolated browsing?
DM: Isolated browsing is the concept of having a virtual remote browser do all the heavy lifting for you. As a result, the user experience remains seamless, but the actual browsing happens far away. That means nothing is running on your endpoint; no code, no JavaScript, no malware, nothing. Everything is far.

TDB: So when you say remote, that makes me think of the cloud. Is this something that's based in the cloud, or somewhere else?

DM: So it can actually reside on premise or in the cloud; from our perspective, it doesn't really matter. We provide both options, as well as a hybrid mode. The general concept is that you want to put that virtual browser in the DMZ or, as you said, in the cloud, in case there is potential malware trying to penetrate, it won't — because it will never reach the end point.

TDB: And how is that actually accomplished?

DM: Right. I was about to ask if it makes sense. So let's talk about it for a second and try to better understand the technology behind it.

The virtual browser is actually a container that resides in the DMZ. And when the user is browsing the internet — and you can browse normally from your corporate office using any device and any browser of your choice — as soon as you start browsing, the system or your proxy is going to take a decision: whether the site that you're trying to access is blacklisted, meaning, no-no you can't get there, or whether the URL that you’re trying to reach is whitelisted — in that case, if it were, for example, your CRM, then you don't need any secure browsing. But for everything other than that, the system is set up by default to generate a secure browser just for you. So that means the decision is happening on the networking side.

As soon as you go and type a URL, this browser is going to open up in a container residing in the cloud or in the DMZ, outside of your immediate network, and you’re going to actually see a flow of images, a visual stream of images. Because what we do is we take the virtual browser and we render the information from the virtual browser into your local browser. So the user is getting a visual stream of images that mimics a natural, native browsing experience, but in reality nothing is running on the endpoint. And that's the trick.

TDB: So when you say images, to me that sounds like maybe there's some user experience issues. I'm assuming that's not the case, but I just want to double-check that users are still able to interact within the browser pages. So you say images are loaded for the user, but I imagine they're still able to click on links within that image.

DM: So what's amazing in the technology is that we are able to render the pages in real time and deliver high-definition video and audio, so that the user will not feel that they are actually using a virtual browser.

When you think about it, in reality users are not opening just one tab, they're opening multiple tabs, and sometimes multiple browsers as well. We provide a dedicated virtual browser for every tab that you open, because we want to make sure there is no leakage or anything else that can come from one session to the other. So actually each URL that you're loading is a virtual browser, sitting in a dedicated container.

Now going back to your question about the user experience — we came from the industry of virtualization, and we have a lot of experience in HTML5; we were one of the first companies to come to market with an HTML5 type of client. So we have a clientless solution, which has been deployed already in tens of thousands of devices, and we know how to do this. So, when we do the rendering, we're actually able to mimic the exact experience that you have on a regular website. Obviously all the links are operational, the website behaves normally; you wouldn't know the difference.

So in reality you have a user that has one tab open with a URL that they’re browsing directly, because it's been whitelisted, and another tab with a site that the user is browsing using a virtual browser, and you wouldn't know the difference.

TDB: So what you're saying is, there is absolutely no lag time.

DM: I'm saying that the performance is so good that it really feels like a native experience.

TDB: Okay, that's good. And so the first thing I think of when you say that each browser or each tab has its own kind of instance is that… you know, that kind of just eliminates cross-site request forgery right off the bat.

DM: Exactly.

TDB: Yeah.

DM: What it brings to the table, though, is the challenge of… Let's say you have 5,000 users in your organization and each one is using 10 or 15 or 20 different tabs; the system has to be very dynamic. Because as I said, every virtual browser is actually not an instance, it's a container. It's a Linux container that's doing all the heavy lifting. So we are able to do a lot of dynamic up-and-down management and orchestration of those resources in order to make sure that there is always a browser available for you.

TDB: Okay, and when you say containers and this is, you know, apologies… I think of Docker, because that's the thing that we hear containers most about nowadays. Is it similar to that or is it a little bit different than that?

DM: No, it's very similar. It's actually the real deal.

TDB: Okay. So what happens when someone actually gets a link that's a virus? Is that something that the solution just goes ahead and handles? I mean, will the users see anything; will they get some kind of alerting; will the security team get alerted on it, that this is a bad link? How is that handled, when some type of malware is run across within this solution?

DM: Okay, this is a very interesting question because when we look at the… I would say, the defense-in-depth strategy of most companies, we see that they have multiple products. But following your question, most of the products that they have in-house are products that are able to do detection and prevention, right? Signature-based or some other type of identification.

The concept of isolated browsing is different. We are not about telling you which URL is good or bad because, as a philosophy, we don't believe that this approach is a good one. Because all you need to do is make one mistake and then you're jeopardizing the organization, you get malware in. So instead of saying, this may be a malicious website or not, we’re just shielding the environment. We're setting that virtual browser in the DMZ, away from the user, and we make sure that all the information coming in is just pixelated, just a visual stream of images, and no code is running.

As a result, it doesn't really matter if this website is malicious or not; because the threat is remediated inside the container and, as soon as the session is over or after a certain idle time, this container is actually being destroyed — with any potential malware that resided in it disappearing.

TDB: Okay. And is there any kind of reporting on bad links? I know you said it doesn't matter but I guess what I'm thinking is from like a return-on-investment type of thing, some people might want to see how well the product… or also [laughter] what sites people are browsing to that might potentially get them infected?

DM: Right. So we do have the logging and the reporting that shows the sites that people went to; so if you want to do forensic work afterwards, that's fine. But we are not in the business of telling you, hey, this site is not good, or this site is good, or beware of www.something, because we feel — and this is what we are getting from the industry — that these approaches actually fail.

When you go and look at some of the statistics today, maybe look at… there's a Kaspersky report from about 18 months ago looking at where are the major attack vectors that are penetrating the organization. And they talk about 62% of the threats are coming through the browser. So the browser in many senses is the weakest link in terms of that. So even if you have, you know, the antivirus and your firewall and all the other components and products that are supposed to be protecting you, they're not doing a good job addressing the browsing attack surface.

So yes, we do have some of the reporting that you require in order to do the follow-up, but at the end of the day the concept of browsing isolation is a new concept; it's even—you know, put a big word on it—it's a new paradigm, saying isolation is just a good way of putting the threats away and making sure it stays there.

TDB: Yeah, absolutely. Because I know a lot of people are probably thinking like virtual machines and Citrix and things like that, that kind of… Those move the whole computer away from the person, but it sounds like you're just moving the browser itself out of the computer and into a different environment, so that it can, like you said, shield it.

DM: Yeah. Let me maybe try to highlight some of the differences in what's happening today in the industry.

So first of all, Ericom has been in the business for more than 20 years and, as I said, we came from the virtualization space and are very familiar with this market. So we actually have what we call our first-generation secure browsing, which is based on Microsoft RDS technology, based on our… We have a robust platform called Ericom Connect, and one of the use cases of this Ericom Connect solution is secure browsing. We actually have more than 60 deployments of secure browsing solutions using Ericom’s “generation one”, and it is based on having a browser installed on Terminal Services, and enabling users to go to that remote browser. Our customers actually call it the Double Browser solution, and this is very similar to what you just described about Citrix. So you can have a terminal server as a VM and have, let's say, Internet Explorer installed over there, and you are accessing it from your remote computer, whether it's through a client or in clientless mode — as I said, we’ve pioneered clientless, so we kind of always like that option. But at the end of the day it's working, and it's working well.

But we decided to take a different route and say: it's working, but now we want to create a dedicated product. And in this new product, in Ericom Shield, we're not using Microsoft licensing. We're using proxy-based traffic; we're using Linux-based containers. So we've taken away some of the licensing cost aspect and also the remote connectivity. So what we're doing is based on proxy, and that's the difference between the products. So this is to relate to what Citrix is doing in terms of remote browsing or isolated browsing.

By the way, there are some other companies in that space who are doing local isolation. So they're doing that virtualization on the endpoint, and using this virtual machine doing the browsing. And again, using the same concept of having a virtual browser do the heavy lifting. But in this case they cannot say that nothing is running on the endpoint. Because in reality it is on the endpoint; although in a VM. So what happens if something goes wrong; you already have that malware within the endpoint and within the organization. We feel everything should be far—far and protected—so nothing gets inside the Local Area Network and nothing gets to the endpoint.

TDB: Okay. So how… When someone brings this in-house, and sets it up in-house, how is that accomplished?

DM: So in terms of deployment, as I said… Let's talk for example about on-premise deployment. All you need to do is you need to make sure that in the chain of connectivity, your network connectivity—between the firewalls and secure web gateway and proxies, whatever you have in place—we would like to be on that route; I would say, as close as possible to the exit to the internet. And you can set your policies with us; we have an admin console where you can set the admin policies. But most organizations already have proxies, they already have policies, so we just execute these policies. And the only thing that comes into play is, we take the information on… if this is whitelisted or blacklisted, it's going to be managed by our proxy, and everything else by default is going to go through the virtual browser, through Ericom Shield.

TDB: Okay. And so if, say, the network or the server guy comes through and unplugs that solution, the product… Does that take everything—every browsing session—down, or will that failover to just using the web proxy again, or how does that work?

DM: You mean if you take out Ericom Shield all of a sudden from the mix?

TDB: Yeah.

DM: So it's going to just work normally. It's going to do, you know, black, white, and everything else is going to go normal.

TDB: Okay, except for you've now opened… you're not getting that shielded protection anymore for browsing sessions.

DM: Exactly. And if you're using, for example, a cloud solution then, again, you need to make sure that you install it in the cloud. It takes really a matter of minutes, but you need to make sure that you open the right port, so internet traffic goes through that port through the cloud.

TDB: Okay, cool. I'm curious what are the hardware requirements for this? Or is this like something that you send and then they just rack it and mount it?

DM: Okay. So let's talk about the components. First of all, you need one server—again virtual or physical—that is going to do all the, as I said, the orchestration; being able to understand who's coming from where and how many browsers you need to manage. So this is what we call the Shield core.

We also have… part of that Shield core is a component called ICAP, which is the standard protocol managing the connectivity with a proxy. As I said, we have a built-in proxy in the system, but most organizations we speak to have their own proxy, so the ICAP is the one doing the communication with them, and is actually going to do the brokering between the people browsing and the available browsers.

Which brings me to the other component of the system. You need a server, a Linux server that has plenty of containers in it and is going to do all the virtual browsing for you. So one server for the containers, one server for management.

We have also a management console that you can install inside your organization, and is accessed through the web. So these are the components.

When you actually ask, What is the horsepower that I need? What's the actual architecture or the hardware component? How many RAMs? and all that... The answer would be, it really depends. If your users are constantly doing 4k video viewing on YouTube, you might as well gear up for some serious hardware investments. But if your users are doing what would quote-unquote be normal browsing—which means, they’re going to do mainly web browsing, news, research, accessing Salesforce, you name it, and occasional viewing of videos or audio—then you would need something else. So we work with every organization to understand their needs.

You'll be quite surprised; some organizations forbid streaming. We've been to a large financial firm… They said, well, 5% of the organization is able to stream, the rest should do their work. So there are many different approaches, it's not like ‘one size fits all’. We have different kinds of setups, and we work with your organization to understand the best setup for them so the investment makes sense.

TDB: Got it. Okay. So what other resources are available for learning more about isolated browsing?

DM: Isolated browsing is actually a topic that was pushed by Gartner about a year ago. There is a very interesting article talking about the cesspool of the internet - I can't remember right now the exact name, I’ll go find it in a second, but very easy to go and find it on Gartner—and this is really where I'd say the discussion started. Since then we see more companies going into the space, we see a lot of talking about isolation; it's becoming a hot topic in all kinds of workshops and trade shows.

So definitely isolation is not a new topic—I mean, sandboxing has been around, and also containers, for quite some time, but there's more and more discussion about harnessing that power of isolation for security.

And again more podcasts — I have been doing some talking myself, and other people from the industry have been also contributing to this, to building that body of knowledge about isolation.

TDB: Yeah, I know it's a fascinating topic, and something I hadn't heard about before. I know working in a team that users can find some pretty interesting stuff online and get their machines infected, so if there's a way to limit that…

I also like the idea that—we talk about segmenting and this is just one step further—segmenting your user browser sessions from pretty much the rest of their computer, which can be considered the most dangerous part of a user's role within the organization, as you said, the research and finding stuff. And I've had people who are going to tech forums to look for answers and they get their machines infected. So I think it sounds really great, and it's a really interesting topic.

DM: Two points that I'd like to make.

One is really about, as you say, the human factor. It doesn't matter how high up you are in the organization, there's always a person who’s going to click on the wrong link. And if you think about the fact that, by default, the system is going to say, if it's not black and it's not white then I'm going to go secure — that really means that even if you make that mistake, and you happen to be the CEO of a company, you're going to be protected.

Another thing which maybe I failed to mention before but is very important is that even though we may not be crazy about the fact that people are browsing and downloading content, this is part of the browsing experience. So we would like to make sure that even if you're now a researcher or an analyst doing some work and you need to download content, we want to make sure that you can do it safely.

So as a result we've actually integrated in the product —it comes pre-integrated—a sanitization solution, what's called CDR, Content Disarm and Reconstruction. This is third-party software that actually knows how to take apart the document or PowerPoint or Excel, whatever it is, clean it from macros and JavaScript and stuff, and rebuild it in a clean and flattened way that maintains the functionality of the file, but making sure that the file is clean.

So the process is that when you browse using your virtual browser and you are trying to download a file, the file is actually being downloaded to that virtual browser container. From there it's taken to be sanitized and, only once it's cleared for use, it's going to be downloaded to the end user device. In this way we actually make it a full-circle, ensuring the browsing experience is complete but yet the organization remains safe, because this file is going to actually be downloaded to your desktop eventually.

TDB: Yeah, I know, that's a great point. It actually made me think of another third factor, which is phishing sites. Is there any sort of detection on those?

DM: Again, phishing is a great example why isolated browsing can really save the day. So let's say you're getting that innocent-looking email from your CEO telling you something, and eagerly you enter the email and click on the link. This link is malicious; it's going to take you somewhere, a site, which actually may have a phishing attack, maybe a drive-by download that's going to come down to your computer, whatever it is. Because this URL hasn't been identified as blacklisted, but for sure hasn't been white-listed, by default it will open in a secure browser. So whatever they're trying to do is now happening inside this disposable container and, as a result, this phishing attempt is not going to be successful.

TDB: Okay. So this has been a fascinating discussion and we're pretty much at the end of our time. What would you like to plug?

DM: What I’d like to promote is, I’d like people from the industry to understand that, as part of the defense in-depth strategy, there's definitely room for a new and fresh approach — isolated browsing is it. It’s definitely not replacing some of the great products that you’re already using, but it's a very important addition that addresses a very significant attack vector, which is the browser, that is currently not being addressed effectively.

I urge you to go to EricomShield.com, and see for yourself, download the datasheet, come speak to us. We would love to hear from you and to let you try it out.

TDB: Awesome. Is there any way people can reach you directly, are you on any social media sites?

DM: Sure, you can reach me on LinkedIn or at Daniel.Miller@Ericom.com. We obviously have a @TimothyDeBlock. Show notes can be found at TimothyDeblock.com/eis. If you enjoyed the show, share it with others and rate it on iTunes. Have a good one!