Dark Times Call for an Overhaul of Your SOC

A wave of change is about to hit every chief security officer that will be every bit as dramatic as cloud computing.

Cloud caught our sector off-guard. The speed at which new cloud services were adopted created blind spots for CSOs. New skills and monitoring tools were required to restore visibility. Even today in 2019, one in every two security decision makers admit their security program struggles to keep pace with new cloud applications.

Our next blind spot will be a little closer to home. It emerges from well-intentioned efforts to address user anxiety about the tracking and monitoring of internet usage.

Several related standards promoted by the browser industry seek to reduce observable data about web requests. They include:

• DNS-over-HTTPS (DoH), a mechanism for encrypting DNS requests.
• TLS 1.3 – the latest iteration of the protocol that secures most web traffic, and
• Encrypted SNI (ESNI), a TLS 1.3 extension for encrypting the server name indicator in a HTTPS handshake.

All three initiatives disrupt content filtering and retention of browsing histories by internet service providers.

By extension, they will have a profound impact on where and how malicious activity is detected on private networks, where network operators are bound by a duty of care to protect users that consent to monitoring. Many reliable data sources used in today’s cyber defense and data protection programs won’t be readable.

DoH!

DNS-over-HTTPS (DoH) is a mechanism for encrypting DNS requests sent between the web browser and DNS resolvers.

In standard DNS requests, network devices on the path between the client and the server resolving the request could observe client IP address information and the requested hostname. In a private/enterprise context, firewalls rules are configured to actively inspect and block malicious requests (via DNS firewall rules), while DNS logs are used for retrospective threat-hunting and incident response.

Visibility of DNS is important information inside the SOC, as it is routinely abused by attackers as both a command and control channel to connect to a compromised host inside a victim’s network (‘DNS Tunneling’) or for exfiltration of data.

We’ve now seen several examples of malware campaigns designed specifically to abuse encrypted DoH in order to bypass detection rules.

Mozilla announced this week that DoH will be turned on by default for all Firefox users in the United States, while Google has introduced DoH in the latest beta release for the Chrome browser. Previously observable DNS data will instead appear as regular HTTPS web traffic.

TLS 1.3, SNI and QUIC

In versions of TLS prior to TLS 1.3, the requested hostname is observable in both the TLS certificate message and Server Name Indication (SNI), neither of which are encrypted.

When a client and server connect using TLS 1.3, however, the TLS certificate message is sent during the encrypted phase of the HTTPS handshake. Network security devices that rely on observing this plaintext for enforcing policy decisions will require new techniques and rulesets. (Symantec made early investments to ensure its SSL Interception products support TLS 1.3 and has repeatedly warned of consequences for network defenders. )

Further, TLS 1.3 sets new conditions for passive decryption of HTTPS traffic. It makes use of ephemeral keys for each session, such that any retrospective decryption of copies of this encrypted traffic will require access to per-session secrets provided by one of the endpoints.

Another source of data observed by network devices is SNI (Server Name Indication). SNI lists the hostname requested by the client in the first packet (ClientHello) of a HTTPS handshake, to account for scenarios in which multiple web sites sit behind a single IP address. Cloudflare recently proposed Encrypted SNI (ESNI) as an extension to TLS 1.3, to again conceal SNI information in ciphertext.

Google, meanwhile, has introduced a new transport protocol called QUIC that can be used in place of TCP+TLS in an attempt to improve browser performance. QUIC operates at the Transport Layer (Layer 4) of the OSI stack, denying network devices the richer application layer context required for making policy decisions.

To date, most network security devices cannot inspect QUIC traffic, and manufacturers advise network administrators to disable or block use of the protocol, forcing requests to fall back to HTTPS over TCP.

We should anticipate strong appetite for these protocols. Most surveyed organizations expect to adopt TLS 1.3 within the next 3-6 months.

Paradoxically, network defense and threat-hunting activities will need to grow more reliant on managed endpoints to compensate for these changes.

My advice is to:

1. Test for impact. TLS 1.3 and DoH can be enabled in two of the world’s most popular web browsers. You should by now understand how they impact the telemetry used in hunt activities inside the SOC.
2. Review your endpoint security strategy. Evaluate the risks unmanaged devices present to your network, in light of the growing inter-reliance between network and endpoint security.
3. Develop a business case for a network security rethink. Assume TLS 1.3 will be a minimum requirement within 12-18 months. Consider the role a zero trust strategy that relies upon trusted identities and devices might play in in reducing your dependency on the network.