View Live Q&A with Security Weekly on Isolated Browsing by Ericom

The Secret Sauce — Q&A on Ericom Shield® for Secure Browsing

Danny Miller, Director of Product Marketing at Ericom Software, joins Paul Asadoorian and friends to discuss secure browsing for the enterprise on Paul's Security Weekly

Paul Asadoorian, Larry Pesce, Joff Thyer, and Jeff Man hosted a live Q&A on the Security Weekly podcast with Ericom’s Director of Product Marketing to learn more about Ericom Shield® for Secure Browsing. Ericom Shield, Ericom’s isolated browsing solution, enables organizations to deliver a seamless and native browsing experience, while protecting endpoints from potential hazards such as malvertising, ransomware and drive-by downloads.

Watch the live recorded interview to learn how Ericom Shield’s holistic, multilayered approach to web security protects the enterprise from browser-borne threats while ensuring that employees can browse freely on any device. Click here for the full transcript.


Paul Asadoorian‏ : Danny Miller from Ericom Software is here with us. Danny, welcome to the show.

Daniel Miller : Thank you guys; thanks a lot.

PA : It's nice to have you. So you’re the Director of Product Marketing and you also have a Bachelor's degree in behavioral science and a Master's in psychology. That's awesome. I'm told Jeff is going to talk with you about such matters, but we're really here today to talk about isolated browsing. So Danny, just kind of put it in perspective for our listeners: what do we mean by isolated browsing and what's the problem we're trying to solve?

DM : When we look at the enterprise and we look at what employees are trying to do — they're trying to browse the Internet. So whether they do it for their leisure, or whether they're doing it because they actually need to do their job — doing research, doing training like you just mentioned — they're browsing the Internet. And as we know, if you look at the current attack vector through which malware and exploits are penetrating the enterprise, it's clear that the browser is the weakest link. So in that sense you want to try and address the browsing experience: on the one hand, give your employees a positive browsing experience—a native one—but on the other hand, you want to make sure you protect the organization from all these potential hazards. So browser isolation actually means that you're going to let your users browse, but they’re going to do it using a virtual browser.

PA : So how do we accomplish this isolation in the browser? Obviously there's operating system protections, but they fall short of the mark of isolation. So what are some of the techniques for actually isolating the browser?

DM : So, when you look at the current products that are doing all kinds of network detection and prevention, whether they are signature-based or other types of solutions, they're all focusing on identifying the malware and then blocking it. When we talk about browser isolation, we actually shy away from saying that this kind of traffic is good and the other traffic is bad. So we’re kind of going away from all this white- and black-listing and we basically say, we don't know what it is, and as a result we want to enable a secure browser.

Now the way it works is that when the user requests to browse, it goes through an organizational proxy. The proxy determines whether it's right or wrong, whitelisted or blacklisted, but the default of the system is that it goes through secure browsing. Secure browsing meaning that we actually have a dedicated container—many containers—that are available in the DMZ. So we have a pool of browsers sitting in a server in the DMZ, and they are the ones doing all the heavy lifting. So as a user you request, let's say I want to go to for some reason, and the virtual browser inside the container is going to do the browsing for you. And the information from that virtual browser—that resides outside, away from the Local Area Network and away from the endpoint—this virtual browser is going to do all the heavy lifting, and the information is going to be rendered back to the end users.

This really means that nothing is running on the endpoint; no code, no nothing. And in the case that there is any particular malware that is trying to penetrate, it actually remains in this disposable container. Now these containers are temporary, so they're just executed based on a request for browsing. And at the end of the session, or after a certain idle time, they just explode—so there's no remains of that browsing session. That means any potential malware that may have been accumulated in this session is actually now discarded.

PA: So when you say it's rendered back to the user, does it get rendered back to me as an image or static HTML or is that configurable?

DM: Actually it's all images. So the user is getting a visual flow of images. And because we have the know-how and the expertise, the user gets a native user experience; they don't even know that on one tab they've been surfing using regular browsing while on a different tab they've been using a virtual browser. So it really looks exactly the same, and we render the information in a picture mode.

PA: So what happens if I need to fill out a form?

DM: Well first of all you have to do it very cautiously. You know, everything works exactly the same as for any experience using a web browser, so we know how to encase it. Let's say, let's give an example, if you want to go and use a certain cookie, or you’re going to your Google Drive, or you want to try and fill out your details somewhere—you said filling up a form. So we have a way of checking those credentials, making sure the information is passing only in text mode, and as a result nothing malicious can actually go back from the virtual browser into the local browser.

PA: So this protects against things such as cross-site scripting, correct?

DM: Yeah but not just that. I mean you can think about phishing attacks — if you're trying to do phishing and the phishing is actually done in the container, and the user is now let's say… a drive-by download that came as a result of going into a certain site, all these things actually remain in the secure container and at the end of the session they disappear. So there are a couple of these types of malware there that are handled.

PA: So it's not gonna protect against any kind of credential stealing, right?

DM: Right. So when you talk about spear-phishing, if the user ended up clicking… Let's say—let's take a real life scenario, a user is getting an email from someone who is so-called CEO of the company and they click the link… Based on how the system is set up—as I’ve said, the default of the system is that if it's not blacklisted or whitelisted then it's going to be opened in Ericom Shield as a virtual browser. So if there's any malware on this website, it's going to be contained. However, if the user has been tricked into actually putting in credentials, I guess unfortunately this is where we stop; this is where we can't really help the user.

PA: Gotcha. I'm sorry, Larry, did you have a question?

Larry Pesce: No, I was going to ask about the form field stuff.

PA: So that's pretty cool. So, are you going to pull any of the malware off of those containers, for analysis?

DM: Right so as a philosophy, using isolation is really all about saying, we don't want to play the game of what's right and what's wrong. Because all you need to do is you need to make one mistake and then the malware can penetrate. So instead of saying this is maybe a good website, or a bad website, all we do is we say we don't know, and as a result we're just going to keep it in isolation. That's the concept of secure browsing using isolation.

PA: I got it. So you're not detecting if it's bad or not, so you don't know if you need to preserve a container to do some kind of analysis.

DM: Exactly. Let's look at what's happening right now in the industry. If you're using an antivirus or you're using a secure web gateway, or any of the others — or even a firewall —you need to have some information saying this one is a good one, this one is a bad one. You know if an employee has just been on a week’s vacation and you're late to install the latest updates, then you’ve got yourself a walking vulnerability. So right now, when you look at the defense-in-depth strategy of all the organizations, they have a pile of products, and each one of them is doing something. We see browser isolation as another layer in this defense-in-depth strategy. So we actually cover that aspect of the human factor, of users just clicking a link. Now maybe one more thing to mention is, when you go into any innocent-looking website and you just look at the page source you're probably going to see hundreds and hundreds, sometimes thousands of lines of code. Some of them being malvertising, some of them with JavaScript running all kinds of other things that are happening in the background. When you right click and check the view source in an Ericom Shield website, that means the virtual browser, you're going to get very few lines, which are really the lines calling the rendering engine. So no code is running on the endpoint, and this is why browser isolation is so powerful.

PA: Yeah I like that; that's good. What about for things that need to make calls out to the web, like for an API or software that needs to get software updates, that has to actually parse the results coming back from a particular web site — is that stuff that needs to be whitelisted?

DM: So some of the solution, some of the of the web pages like you described, may need to be whitelisted initially, but we have certain mechanisms that help us identify and transfer cookies between sites and as a result, kind of verify that the site is safe to use. Also a lot of the websites now are using HTTPS, so when using HTTPS obviously with the built-in encryption, some of these updates are actually quite safe.

LP: Some of my other questions—you know, I have so many questions like, “How do you do that?!” Then other ones like, “How do I watch a YouTube video if it's doing rendering somewhere else?”

DM: Okay, that's really how the magic happens, right? So maybe that’s a good opportunity just to give a couple of pointers about Ericom and who we are. The company has been operating for more than twenty years in the fields of secure remote access and virtualization. As part of that process, as part of the know-how in the company, we actually developed an HTML5 client, I would say six or seven years ago, so we were pretty much the first one to the market with a solid HTML5 type of solution. So with our remote secure access solution we have tens of thousands of devices in the field that are already using that kind of technology. Coming from a virtualization background, we know a few things about how to deliver and how to create those virtual browsers, and how to do the rendering in an efficient way. And as a result now when you're going on Ericom Shield and you try it out and you're looking at videos, it's quite amazing to see how smooth it is. You know, audio synchronized, video looking great—also in HD. And the R&D team is really working very hard in making sure that this is transparent to the user. Because at the end of the day, for this solution to work, users need to be totally unaware of what's happening in the background. And that's a challenge.

LP: Speaking of being unaware, I know that there are those wonderful developers out there that design their sites for Internet Explorer only, and you mentioned some containerization. How do you deal with some of the containerization that requires a specific browser engine to operate?

DM: Right. Because we are using HTML5, basically any browser that uses HTML5 is going to be fine. We don't really care which device or which browser you're going to use, as long as it's HTML5. And we do the magic in the background. So we actually have a specific engine that we're using in the container, but from the user perspective it doesn't matter. We just deliver the same experience whether you're using your Mac now, or using Chrome, or using your Windows laptop with Internet Explorer.

PA: How difficult is it to tune those containers so that they can accurately render all the websites — so if a website requires this technology or this particular browser… Do you emulate different browsers from the container itself?

DM: No we actually do all the rendering on the server side; as I said, there's a server running in the DMZ. What we do is we have actually a pool of containers, so when you think about user experience, as soon as the user is clicking on a URL, it doesn't need to wait for a browser, there is a pool of browsers waiting for the user. All we do is just create the connection between that browsing session and the virtual browser that's doing the actual browsing and the rendering, so it really doesn't matter from our perspective.

PA: So in your virtual browser… If the site's requesting Internet Explorer, do you have the kind of smarts in that virtual browser to emulate Internet Explorer, for example?

DM: We are using Linux containers and Linux as an operating system, but we do have tricks to make sure that it looks okay on Internet Explorer as well.

LP: Excellent. I'm just thinking, “Man, this is great, and this very much sounds like an enterprise solution.” How can I get this for my wife and kids at home? [laughter]

Seriously, have you considered a potential home market or consumer market for something like this?

DM: Definitely, and we actually heard it from different kinds of analysts and others, but I have to admit that right now our focus is on the enterprise. We're about to launch the product in a matter of weeks; we already have the product in place as part of our first generation, which is based on Microsoft technology, and we're kind of doing now our second generation. And as soon as we get comfortable in the field with all the right companies buying into it then we will definitely look at the household market. Because it's very clear that you can protect your computer at home and all the different devices—and we can blame our kids for hitting on all the wrong links, but that's true also for adults. So if we can just try to save the world from clicking on those wrong links, that would be great.

PA: Danny, what's the underlying container technology—is it like core OS with Docker or is it some other kind of container technology?

DM: I'd say the latter. It's more using Docker technology and on top of this using a specific Linux operating system that we trimmed down to make sure it's a very lean and efficient Linux with a browser and that's about it.

PA [whispers]: That's the secret sauce…

DM: You have to remember that, because this is an enterprise-wide solution and because, you know, Monday morning at 9 a.m. people are probably going to be firing up five, ten, fifteen different tabs on their computers, you have to be ready to scale. That means that there's a very dynamic system with browsers going up and down, and people shutting down, and moving, up and down… so you've got to be very effective in how you manage your pool of browsers. And we do a lot of checks and balances to make sure that we always provide the best user experience, so that they won't be in a situation where, “Hey, there's not enough browsers for you.” I don't know what situation you're in, but I have probably fifteen browser tabs open right now on my laptop, and every tab is a virtual browser. Because we make sure there's no leakage between sessions, so every tab is a virtual browser.

PA: They always have that one window that has like 25 tabs open, and you forget that window is there and you just create two new windows with all the tabs open, and you're like, “Why is my browser running so slow?”

LP: And where did all those other tab go? Where’s that website I was on? [laughter]

It's very much the ShmooCon ticket sales problem. It's like, you know, the ShmooCon website runs great all year long until they go to do ticket sales, and they have half a million people trying to hit their website all within this three-minute period.

Joff Thyer: I have a couple of questions, real quick. So one is: How do you do with the situation when the browser user wants to download some sort of content, like a PDF or some sort of zip file or something like that? And the second question is: Have you done any studies over the long term as to the impact on the client-side? Is your technology actually lighter weight in terms of resource utilization and overall efficiency on the client-side?

DM: Okay great questions, thanks for that. So first of all, as you clearly stated, part of the user experience is the ability to download files, and we know that. That means that as part of the process, let's say you're browsing now on a certain website and you want to download a file, the file is going to be downloaded into this container. Actually, we can connect to any sanitization solution that the organization has. And you know, working with all the organizations that we speak with in financial and banking and health, most of them have something in place. But our solution also comes built in with a third-party sanitization solution.

What I mean by sanitization, it has actually two angles. One is a multi-scanning engine that checks the file. The other one, which is more sophisticated is what's called Content Disarm and Reconstruction —actually taking the file down, breaking it into pieces, eliminating any potential code or malware that may reside within, and recreating the file according to — let's say if it's Adobe — according to PDF standards. Only when this this process is complete, only then the user can actually download the file to the endpoint. Until then all this process is happening in the virtual browser in the remote container. And again, it's in the DMZ, so nothing is penetrating the organization until it gets the okay that yes, this file is safe to use.

So I know that right now when you speak to users, they are okay with waiting — sometimes a couple of minutes even — for a file to be cleaned out, saying Big Brother is making sure that your file is going to be safe. So people are… it's okay for them to expect it. It's not okay to expect when you browse the internet, to say, “Yeah, well we're not sure if this site is blacklisted or whitelisted, give us a minute to check it.” That's not acceptable. But downloading a file, that's okay to wait. So that's in terms of the file sanitization. And again, one of the advantages of our solution is we know that there are small and medium sized organization who do not have that kind of a solution in place, and that's why we embed it as part of our solution. So they get not only the secure isolated browsing, but also the download of the file.

As for your second question regarding the number of browsers and how they clog the system or they don't, it really is all about managing the resources and making sure that after a certain period of time, browsers or containers are being exploded and recreated. It's very important also to understand that, as I said, the system is very dynamic. So for example, this example of Monday morning 9 a.m., there might be a chance that the idle time is going to be a little bit shorter, because we know that there's a lot of traffic. But say around lunchtime it's less of an issue, because the resources are available. At the end of the day, a lot of the decision is at the enterprise level. They need to decide how much resources they're willing to give the remote browsing, to make sure that users can really browse freely, or are they gonna say, hey we’d like to limit this. So we have all this business logic embedded in the product and, from a certain threshold, we know how to manage the ups and downs.

PA: Danny, how do you handle SSL — is it similar to how a proxy server handles it today? In other words, I get a trusted certificate from the proxy server and then the proxy server does the validation of all the sites I go to?

DM: Exactly. But what we do is we’re actually using ICAP, which is a protocol that’s very common in the industry, and we actually place our ICAP right after the proxy. So we use the ICAP to really execute the organizational proxy policy and, based on your decision… you might even have a firewall before the proxy and then the proxy, and maybe even a proxy afterwards. So we'd like to be the last point before you go into the outside world. And after all the policies have been executed, this is where we're going to decide whether you go directly to the internet, whether you're being blocked, or whether you're gonna be getting an Ericom Shield virtual browser.

JT: Do you act as your own proxy, or are you mostly in the business of partnering, using ICAP, with other proxy solutions?

DM: We've been talking to many customers and prospects. Most of the organizations that we speak to already have a proxy in place. And in such cases we just come with our ICAP solution and handle this. Some organizations that do not have proxy, we provide the proxy as well. So our solution has a proxy embedded, a standard proxy, and we can just disable it in those cases where the organization already has a proxy built in—which is most of the cases.

JT: So both. That's great; that's good to hear.

DM: Well, you’ve got to be flexible. You don't want to tell a customer, “Hey you haven't been using a proxy, so we can't really help you.” You’ve got to find a way to really hook up to what the industry is looking for, and ICAP right now is probably the most common protocol to connect between those pieces.

PA: How does the product provide — or in any isolated browsing situation, how do I get feedback as to how I'm doing? In other words, how do I measure success and know that it's successfully protected some of my users?

DM: At the end of the day, as I said, we are not checking whether you've been hit by malware or not, we're just making sure that the session is always away from you. Now, this is probably some sort of a measure that we need to put in the system, to make sure that if malware did try to penetrate we can just kind of say, “Hey, one malware down in this container!” But right now we don't do it; we just look at it as a black box and say, “If something's wrong here, we don't know but we don't care.” That's pretty much the philosophy. We do have a log, a very extensive log system, that tracks everything, you know, from all the connections, and number of browsers, and idle time, and how many times you were browsing and where. But specifically identifying malware — this is exactly what we're trying not to do. Because, as we see in the industry, this is where most companies at some point in time fail to say, “Hey I missed that specific malware and as a result I've been hit by a WannaCry, or any anything else.

PA: I got you. So this would ride on top of any kind of browser protections that I've put in place? Like what if I’ve run some kind of ad blocker or something in my browser; does that just kind of work before it goes up to your system?

DM: Exactly. And again, I can't really say that everything that you have right now you need to ditch and just use a secure browsing and browser isolation and you're good to go. We know that you need to have different types of products that address the hazards of browser-borne threats in different ways. So definitely you want to have whatever you're currently using; this would be an additional layer that's going to do the trick.

PA: That's pretty cool. And it's something we want to talk about in our stories tonight, about some of the history behind advertising on websites and Google's attempts to put advertising blocks natively inside the browser. And there were some interesting things in there about sites like Forbes and Wired, and — I think was Forbes that said, well if you've got an adware blocker on your browser then you have to register and pay us or register and not pay us, something like that, so you have an ad-free experience. And as soon as they, like right after they did that, they had some kind of malvertising campaign hit their system. So if you had disabled your ad blocker, you actually got owned going to the site — unless you had a secure browsing solution, which would prevent that kind of behavior. So I think it's highly effective at stopping those kinds of attacks, which are hard to trace down

DM: Yeah, it's hard to put your thumb on, you know, here I'm being attacked right now. Simply because people just browse and browse. And, you know, the number of open sessions that are happening in a company at any given moment are just impossible to trace. So you just want to make sure that you're taking an approach which is a little bit more unique, which is really looking at it more holistically — I just don't want to deal with it, let's put it aside and let it play in a safe manner. That's really how we look at it.

PA: So Danny, where do the cookies reside? Are you handling the cookies on your container and just passing back the result? Are you building those cookies and maintaining them for the user, or are some cookies passed back to the user’s browser?

DM: So we are maintaining the cookies on the end user’s browser. However the first time when you are going into a new site, we do bring back a cookie, but we remember them. So that's, for example the reason why if you open a tab on Google Docs and another one on Gmail, for me, from the user side, it's going to be totally transparent; they're not gonna do any login or anything like that. But yeah, we have to pass cookies but — by the way, we have a straightforward website management web admin that you can take some decisions. And the decision is based on, you know what, I don't want to enable cookies from this particular site, and that's also a possibility. So we do enable this granularity. But most options we know that cookies are really required, because if you want to maintain the user experience, the native user experience, you kind of have to have those cookies.

PA: So now, is each individual connection to the site in its own container, or does my browser get its own container?

DM: No, every tab, every URL that you click, is going to be firing up a dedicated container and, inside, a virtual browser.

PA: So in that respect, Cross-Site Request Forgery attacks don't exist on your platform, provided the containers can't talk to each other. Correct?

DM: Exactly. The containers are totally separate; that's exactly the reason. Because, as you can imagine, as the R&D team were putting together their thoughts around, ok, how should it work, there were some thoughts of saying, “OK, one user gets one container.” And then we realized that this leakage is something too dangerous, and we need to separate and isolate each one of the sessions. Because you can never know where the malware resides.

PA: So to a certain extent, cross-site scripting attacks can get at whatever's inside that container, potentially. Correct?

DM: Yeah, they're gonna be hitting the container, and that's about it. And then the container is just gonna go away, and with it the attack.

PA: So it's somewhat limiting — Joff, Larry or Jeff — somewhat limiting to cross-site scripting attacks, because you can't execute code in the user's browser… [aside]

LP: Sorry, you can execute code on the user’s browser but it's in the container, and it's only got access to what the container execs, which is just that one website so… That's pretty darn cool.

PA: It is pretty cool.

DM: It is pretty cool and I think it's also — it's elegant. It's really keeping the users unaware of the fact that they are now not jeopardizing the organization by going to all kind of funny websites.

LP: “Funny”. I like the way you put that. [laughter]

PA: Yeah. Any more questions for Danny…?

Danny, thank you so much for appearing on Security Weekly, and sharing with us some knowledge about isolated browsing. I was always quite curious how it worked without installing a client on the user's workstation, so now we have the answer.

LP: Now we have a very elegant answer.

PA: Containers for the win. Thank you so much, Danny, for appearing on Paul’s Security Weekly.

DM: Thank you very much for having me. Have a great evening, and see you again soon!

PA: Thank you; you will!