Considerations on Closing the Browser Security Gap – Blog

Considerations on Closing the Browser Security Gap – Blog


Let’s get this out of the way, in case you came to this blog via LinkedIn or another social path: The Browser Security Gap remains real for any organization that still relies on signature-based network security solutions or even sandbox technology.

This is due to signature-defeating HEAT attacks. HEAT stands for Highly Evasive, Adaptive Threats. Web traffic, unfortunately, lends itself to both evasive and adaptive attacks.

Consider the HTML Smuggling HEAT attack, enabled by the very HTTP methods that optimize file transfer, chunked file transfer (streaming) and range requests (partial content) and automatic downloads. Threat actors embed malware in these files,  Then, active code like Javascript can detect the download and invoke the malware. HTML Smuggling defeats network-based detection because due to their architecture, they generally cannot see the entire content of files transferred via HTML. Endpoint detection is defeated also if the malicious Javascript can activate the malware before an AV scan can see it. Mitre has a great, more technical discussion of this here.

Or consider the AI-driven escalation in phishing attacks: It used to be easy to pick out a phishing email, based on typos or grammar mistakes or a sender with which you were unfamiliar. Those days are gone, because attackers are taking full use of GenAI’s capabilities to smooth grammar and writing. Even a poorly written phishing campaign used to take time to execute; with GenAI, attackers can iterate on attacks in minutes.

Finally, one of the newer exploits that unfortunately is very much in the news right now: vishing or, voice-phishing. There are countless vishing flows that threat actors use so I am going to use a trivial example to illustrate it.

  1. I am watching a streaming service on my laptop.
  2. A threat actor starts the same streaming service on their computer.
  3. The threat actor has done their homework and knows enough about me to make me think they work for my ISP and says to me, we need to test your service for you. Please go to service/device_auth and send me the code on your screen.
  4. The theat actor is now using my login for their streaming service.

This example is trivial because in spite of the streamers trying to stop password sharing, etc., these days it’s not that big of a theft.

Vishing took a dark turn due to the architecture of salesforce.com connected apps service.

The good news is that Browser Security is not an unsolved problem.

This article is the first in a series, covering various considerations that may not come immediately to mind to stakeholders in the process of closing the browser security gap. The series plan is:

  1. Architecture
  2. Choice and its implications
  3. Cloud-based Browser Security versus legacy RBI
  4. GenAI Security
  5. Network-? Application-? Desktop-? Where is this stuff? What budget do I use?
  6. Endpoint Risk

First, architecture.

First Architecture

Putting it in the simplest terms, Browser Security occurs in one of two places

  1. At the endpoint
  2. In the cloud

Does Architecture Matter?

Here I will demonstrate that architecture does matter when closing the browser security gap. Here are some examples:

Relative to any endpoint browser security solution, the cloud is centralized. And this delivers some advantages:

  • In the cloud, defense can be pre-emptive. How? In the cloud, some sort of surrogate browser intercepts user traffic and prevents threats from reaching the endpoint. Without the cloud, threats end up on the endpoint.
  • In the cloud, services like data loss prevention occur before sensitive data is physically on the endpoint. Endpoint security solutions bend over backwards to protect what they’re trying to protect, but, the endpoint is simply a weak link in the chain (we will cover this in article #6); endpoint security is only as strong as the user’s training and behavior.
  • In the cloud, data is centralized. Logs of millions of browser sessions can feed machine-learning security.
  • The cloud can provide centralized access to external services and resources. Here’s an example of why and how this matters: First, take a look at this report to learn how the bad guys are using AI for nefarious purposes, such as AI-customized phishing/spear phishing/whaling attacks. So, you’ve got to fight AI with AI. While Menlo developed a range of machine-learning-based algorithms to detect fraudulent sites, including logo detection (Menlo customers can submit a high-resolution version of their logo to add to the Menlo logo database used for fraudulent site detection), page structure (with understanding of every page’s Document Object Model), input fields, and the full URL path. Our partnership with Google continues to bear fruit:  Now, read how Menlo Heat Shield AI now leverages Google Vertex platform with Gemini models to greatly strengthen detection of fraudulent phishing sites.

Quick Article 3 Preview: Cloud-based Browser Security Versus Legacy RBI

Some information since I’m making the case for browser security in the cloud:

Years ago Cloud-Based Browser Security architectural advantages were clear. But the technology, pixel streaming, has been found insufficient for modern web use. It worked OK in the early years and became known as Remote Browser Isolation, or RBI.

Modern cloud-based Browser Security gets away from the limitations of pixel-streaming, legacy RBI. If you want to go deep into this right now you can learn how Menlo patented Adaptive Clientless Rendering optimizes the delivery of safe web content from the Menlo Cloud to users’ browsers. Modern cloud-based browser security, unlike legacy RBI, works for the modern web.



Source link