Loading summary
Transcript16 lines
- [00:04]
A
Hello everyone, this is Tom Uren. I'm here with another Risky Business News sponsor interview. Today I have with me Michael Leland, who is the field CTO of Island, which makes an enterprise browser. G' day, Michael. How are you doing?
- [00:17]
B
Great, thanks, Tom. How about yourself?
- [00:19]
A
Good. I thought we'd first start with what exactly is an enterprise browser? Because I remember when Ireland first started sponsoring, sponsoring Risky Business, I was like, what, what's an enterprise browser? I didn't understand what the point was.
- [00:34]
B
So the enterprise browser market kind of evolved around island when we realized as an industry that the majority of the applications that knowledge workers were accessing were SaaS based or web native and cloud first. And yet we've been relegated to using consumer browsers to access business information and business applications. And to be honest, the consumer browser was never built enterprise grade, right? It wasn't built with data protection in mind, it wasn't built with enterprise end user experience in mind, and it certainly wasn't built for the demands that we're placing on today's access to applications, whether that's native SaaS or, you know, tunneling back for a VDI instance. We've been forced to surround the consumer browser with this myriad of security technologies, right? We need to protect the endpoint on which the browser runs, we need to protect the transit of data to the browser, and then we have to protect the browser itself. And so we've surrounded it with things like backhauls, break and inspect for dlp, break and inspect for web categorization, break and inspect for application performance monitoring. And then we've had to layer on endpoint, Tech, Stack as well, edr, VPN zero Trust. We looked at it kind of at a holistic level and said if we were doing it from scratch, if we were building an enterprise class application and service delivery platform, knowing that the browser was going to be the foundational component of it, how would we do it better? And that's where we started. And so we took what was good from the Chromium project and we took out all of the consumer grade code that made it vulnerable and less, less relevant for enterprise knowledge workers and we replaced them with enterprise class capabilities. So think about all of the code that was built into Chromium for ad delivery, ad tracking, the monetization of eyeballs sitting in front of that browser. We took all of that out and then we added in all of those capabilities that make it enterprise grade, the first of which is the authentication paradigm, right? You need to authenticate into an enterprise browser and it's through that IDP authentication, that you get your policy, you get your application entitlements. And the most important thing about an enterprise browser is that the browser by nature sits at the natural termination point of encryption. So after the TLS and SSL have decrypted the data, but before it touches the screen, we call that the last mile. And in that last mile, we see everything post decryption. So we can affect things like inline DLP data redaction before the presentation layer. We can assert MFA in places that couldn't exist before. And then also about a year and a half ago in December, when the Cyber Haven event happened, we realized just how vulnerable the extension management framework was, and we saw Cyber Haven's compromised extension. And so we also needed to protect the users from the risk of compromised and vulnerable extensions.
- [03:42]
A
All right, what happened in that incident? I'm not familiar with that one.
- [03:45]
B
So what happened in December was somebody was subjected to a spear phishing campaign. An admin or a programmer user at cyberhaven allowed access to their code base by a malicious adversary. They then took the Cyber Haven extension code, they manipulated it and added malicious code to it, re uploaded it to the Google Chrome store, and about 400,000 users downloaded it. And the adversary started harvesting everything from Facebook IDs and tokens to cookies to credentials. So a very simple mistake by one admin user exposed this massive vulnerability in the privileges of this extension.
- [04:28]
A
And so that seems like an extreme example, but it must go on all the time in that, you know, I've heard for a long time of old extensions that are actually traded online and people buy them and use them for malicious purposes. And so what do you do about that?
- [04:44]
B
So there's a couple things, right? Google is now enforcing this mandate for the manifest v3 of extensions. And to date, manifest v2 had more significant opportunities to compromise. But the manifest v3 is kind of the newest way of doing things. It enforces better privileges, claims and trusts. And essentially when you look at the privileges associated with an extension, it's. It's called permissions and host permissions. What am I going to do? And where am I allowed to do it? And with manifest V3, those, those controls are very much tightened. So that's, that's a good thing for the industry. The problem is so many extensions require such overly permissive writes simply because of what they're trying to do. Grammarly is, is probably a great example, right? Grammarly, for all intents and purposes, is a keylogger, right? It's capturing everything we type. It's sending up to a cloud instance to be evaluated, the verdict's being sent back down. That might be perfectly fine when you're crafting a personal email, but it may not be fine when you're in an EMR record or you're in Salesforce or you're in workday. So the ability to understand a what is the risk associated with each extension? What's the probability of impact? And then more importantly, when and where do we allow these extensions to operate? So if you could govern exactly where these extensions are able to access your data, you can greatly reduce your attack surface by saying anytime you're in a a browser tab accessing a sensitive business application, we're going to disable those extensions that have access to the full dom, the document object model. Right. They have no right seeing all of the types text we put in files we upload. If I'm in a personal browsing session, perfectly fine. Maybe that's where these extensions can have a little more privilege. But we need to control the data boundary between our business applications and non business applications and actually keep that data in what we'd like to call a secure enclave. Right. No data goes in or out that shouldn't. And extensions don't have visibility in there as well.
- [06:49]
A
Right? Right. Do you get visibility into what kind of extensions your clients are using and what are the, I guess either the stories or the lessons you've learned from that. Are you like ban them all or what's your process for managing that?
- [07:06]
B
I guess so there's some organizations that just outright ban extensions. Right. And you, you can configure that through gpo. You can have a policy that says that no extensions can be installed. There's those that offer an approval process and a vetting that says, you know, let me know what extensions you want to use, we'll validate that they're, they're acceptable and then we'll put them on the allow list. Island takes this slightly different approach. We catalog and we assess every extension that's been uploaded to the Google Chrome store. There's about 220,000 extensions. We evaluate the code base, we assess the risk and we assign a score and then we allow an enterprise to set a threshold for what their risk appetite is. Are you okay allowing low and medium risk extensions? And if so, where, if you want to block them outright, you can certainly do that, or you can, you can have an approval process. You know, this extension appears to be potentially more risky if, if it were compromised. But, but I absolutely need it for my job. So you know, for me, would you change the policy and allow it? But the other thing you get day one from utilizing an enterprise browser is you get full visibility into every extension that's deployed, every extension that's in use, and the risk scores of each one. So it's really important that you identify kind of what's out there so you can better understand what you should be blocking what you should or restricting. Infostealers from extensions have seen a huge growth, like 180% growth since 2023 of infostealers that were built into both extensions and then malicious malware that's deployed through the extension.
- [08:47]
A
So I guess when it comes to info stealers, there's a supply and demand or a push and a pull in the sense that you can do things to stop your credentials being stolen. I guess if you're sitting in the browser, what are the types of things that you might do to stop those credentials? Is there anything you can do to stop those credentials being used?
- [09:08]
B
So the most important thing is stopping them before they walk out the door. Right? And here's the important thing. Attackers aren't breaking in, they're logging in. That's a really critical thing. They're getting access to our credentials in any number of ways. Phishing is probably the most successful. So imagine if you could set up a rule that says that these five domains are the only ones that you're allowed to use or enter your corporate credentials. And if you try to use those credentials anywhere else, that could be a phishing site, a man in the middle attack a browser in the middle attack the enterprise browser will identify the fact that you're using your corporate credentials somewhere outside of the trust zone. So that's one way is you can prevent these corporate credentials from being used anywhere outside of site that you don't put on the allowed list. The other is to enforce a strong MFA policy. There was research out last year that claimed that 94% of all breaches could have been avoided with an effective MFA solution. And most organizations have a moderate MFA solution. They probably authenticate at the initial login and they assert some type of mfa. But there are still a number of applications out there that don't enforce a single sign on with MFA at initial login. So what the island browser does is it allows you to assert MFA anywhere at the presentation layer. So even if there's an application that doesn't natively support MFA for initial login, we can pop one up when the user browses to that application, or if you have an application that only asserts MFA at the initial login. But you know that in a section of that application, if they browse into this section of the application, there's the risk of highly sensitive information being leaked. We can assert another MFA anywhere in the application chain you want. We don't control the code to these applications, but we do control the presentation layer and we can enforce MFA anywhere we want to assert that secondary authentication and prevent those credentials from leaking.
- [11:19]
A
Right. How does that work if, like a criminal somewhere else is not using island but has those credentials?
- [11:26]
B
Yeah. So the other most important thing is what we call browser enforcement. If you insist that certain applications that you know host sensitive data, your mission critical applications, can and should only be accessed by by means of an island browser that is connected to the tenant that you're configured in, no other browser will be able to utilize that connection. So even if I try logging in from Chrome on the same machine that I have island installed, if it's not coming from an island browser, that authentication will fail. We could do it any number of ways. Conditional access through the idp, making sure that all auth requests come from a known path that that contain the IP addresses that island provides. It can be done with certificate pinning. There's any number of ways. And also, you know, there's always the island extension. We can install the island extension in any other consumer browser and use that as the natural transition point to steer them back into the island browser where we can assert the proper enterprise grade security.
- [12:29]
A
Michael Leland Field, CTO of Island the Enterprise Browser, thank you very much.
- [12:35]
B
Thank you, Tom, Appreciate your time.