As a consumer of security solutions, the successful protection of my valuable assets relies on many ‘links’ in the chain that is my security services stack. From Firewall to EDR – each component hooks on a different technology, and is responsible for narrowing the attack surface in it’s specific field of operation. A CISO’s Intelligent composition of this stack creates a synergistic protection against all aspects of a cyber attack relevant to their network infrastructure.

But what if this stack was self-devouring? Today we are observing a process in which big players in this chain who also design the end-user’s OS, are harnessing their technology to create a vendor-lock at the expense of other security solutions in the war for security revenues.

In this article we will examine a single case study in this affair – of an impending battle between OS Vendors and ISPs that is caused by new User Masking technology. We’ll drill down in the tech itself, discuss how OS providers are leveraging it to capture market share from ISP end-user security platforms, and (most importantly) how ISPs, and all of us, can effectively fight back and win.

OS Vendors VS. ISPs: Eliminating Transport Security With User Masking

Three transport visibility technologies recently rolled out by Apple, Google and Microsoft are being marketed by these OS vendors as dramatic end user privacy enhancers. Indeed, user masking tech like MAC Randomization, DoH/DoT and ESNI can effectively augment end-user data security, and because they are privacy-focused, ISPs absolutely need to embrace them.

Yet it’s important to look below the surface of the timing and substance of user masking at the OS and network level. The forces at play here have little to do with end user privacy – and everything to do with security monopolization.

Let’s drill down to the tech.

THE CHANGE: MAC Randomization

Although NIC devices still retain a static MAC address for L2 communications, more and more OS vendors are implementing software-level MAC randomization. This functionality presents a fake MAC address to the LAN upon connection – essentially making the user untraceable across different networks, and removing the device manufacturer information from the first three bytes of the address.

THE ISP CHALLENGE

For provisioning, customer service and security, MAC randomization presents a challenge to ISPs. ISPs end up seeing a network flooded with numerous MAC addresses, all representing the same device. These addresses do not define the device type, and can’t be easily aggregated to represent a single device. Until now, MAC addresses were key identifiers for connected devices. Now, many security, provisioning and customer support applications will need a complete overhaul to keep functioning.

THE CHANGE: DoH/DoT

Google, Cloudflare and other public DNS servers have begun offering “DNS over HTTPS/TLS” – DoH/DoT. Accordingly, both IOS and Android in their current versions offer a DoH client. This functionality encrypts DNS queries and responses over a TLS or HTTPS secure connection layer. The idea is that a threat actor can no longer eavesdrop or intervene in the process of querying a web service’s IP address. It is an important tool, for example, in the fight against censorship – as governments often use DNS traffic to identify and block “illegitimate” user behavior.

THE ISP CHALLENGE

DoH/DoT presents both a business and security challenge to ISPs – who rely on DNS queries to provide valuable end user privacy and safety services like safe browsing and parental controls, and also to offer QoS enhancements by throttling specific services. With DoH/DoT becoming prevalent, ISPs need new ways to monitor user activity and provide the privacy services end users have come to expect.

THE CHANGE: ESNI

Even with full DoH/DoT implementation across networks, ISPs were also able to monitor user activity for security reasons by extracting information at the start of the TLS handshake from the clear text Service Name Indication (SNI) field. This field is used to determine which certificate should be handed to the user during the handshake, in order to correspond to the specific DNS address that was reached by the client. ESNI – Encrypted Service Name Indication – eliminates this option. The user’s SNI is masked via a public DNS record that holds a server’s public encryption key, which is used on connection to encrypt the SNI field. Only the server, which holds the corresponding private key, can decrypt the SNI field and extract the requested service name for the TLS connection.

THE ISP CHALLENGE

Similar to DoH/DoT, ESNI presents business and security challenges to ISPs. The same end user benefits – privacy and safety services, and more – become unavailable once transport identifiers go dark. ISPs potentially lose a valuable revenue stream from these services, and are unable to offer the same levels of network security.

So, Who Do These Changes Serve?

No one debates the need for privacy and security. In light of the Coronavirus crisis, the need is even more clear. Recent research revealed a 600% rise in cyberthreat indicators between February to early March this year. Unsecured home, SMB and SME networks – the very networks that ISP security services can serve best – are the most likely to fall victim to omnichannel attacks from robocalls, text messages, email phishing, IoT vulnerabilities and other sources.

Traditionally, ISPs took a backseat approach to network security, positioning themselves as neutral infrastructure providers. In recent years, many began to proactively offer customers more advanced network security solutions that are based on transport monitoring, in addition to basic security amenities like antivirus and spam control.

And when ISP-based security services began to eat into their bottom lines, the big OS vendors took notice.

So the big question in the rollout of OS-based user masking tech is: who are these changes actually designed to serve? Do they serve end users, who continue to suffer from massive privacy vulnerabilities baked into operating systems themselves? Or do they serve OS vendors – who have a history of seeking quiet routes to vendor lock-in and a vested business interest in keeping ISPs out of the security loop?

The Bottom Line

The debate on the effectiveness of a centralized security stack – one that completely relies on OS’ tech – still remains. If OS Vendors succeed with this strategy, the end-user will enjoy a powerful, singular experience for protecting their assets. But this comes at the expense of eliminating other, sometimes creative and valuable security solutions that could prevent a single point-of-failure.

Thing is – it’s supposed to be up to the customer to decide.

Regarding ISPs, for them to stay relevant in the security field they need to make both technological and branding changes. On the technology side, they need to adopt advanced technology that will enable them to continue to provide effective security services, even in light of OS-level user masking. On the branding side, ISPs need to show both industry and consumers that they are viable, relevant and trusted security players. They need to make it clear that end-user security and privacy are paramount in their infrastructure – while clarifying that future overhauls to privacy-oriented protocols need to be made in a way that ensures that trustees on the transport layer can access the data they require to operate.

Regarding the rest of us, security providers and consumers, we need to stop being afraid of the big OS players and make it clear both to them and standards organizations, that user-defined trustees have to be taken in consideration for future tech. That is how we keep our freedom of choice.