Is Your Zero-Trust Solution Missing Half Your Network?

With hybrid work environments on the rise, enterprise networks are dealing with multiple remote connections, increasing the risk of breaches and other attacks. One way to mitigate these risks is by implementing Zero Trust Architecture (ZTA) into the enterprise network. Unfortunately however this does not address the full set of threats to the enterprise, as many of the zero-trust service providers and on-premises network solutions do not address the voice network.

ZTA, as its name indicates, is based on the premise of not granting trust, regardless of a user or asset’s location within or outside the enterprise’s network, physically or logically. The requirements were set in NIST SP 800-207, which lays the roadmap towards ensuring authorization, access, and encryption to protect resources within the enterprise.

The model around zero trust has grown over the last few years. The U.S. Government Services Administration (GSA) lists 8 specific pillars of focus for a successful ZTA implementation: user, device, network, infrastructure, application, data, visibility & analytics, and orchestration & automation.

What about voice?

Why isn’t the voice network included in current zero-trust solutions?  A major difference between Real-Time Communications (RTC) traffic (voice and video) and data network traffic is the dependence on speed for quality. Voice traffic needs to be processed end-to-end, as fast as possible, to ensure call quality. With this requirement, sending traffic through a network firewall creates inefficiencies and delays to RTC traffic.

When a firewall is the demarcation point of a voice network, all packets are processed as a first-in-first-out with little regard for speed, putting RTC traffic behind any other traffic waiting for processing at the firewall. Additionally, the number of packets generated by RTC is significantly higher than standard network traffic, creating delays.

Many enterprises have tried addressing this by opening firewall ports just to allow RTC traffic to pass through, unchecked. This is a major security risk since there are over 16,000 potential media ports for RTC traffic, creating potential targets for hackers to launch cyber-attacks and infiltrate the network. Firewalls are also highly susceptible to VoIP Spoofing attacks because of their minimal inspection of VoIP packets. Luckily, it doesn’t have to be this way.

Enter the SBC

Securing RTC traffic without losing quality requires a Session Border Controller (SBC). SBCs process RTC at near wire-rate speeds Regardless of the endpoint’s location, running voice traffic through an SBC enables multiple security features including the following:

Access

Access on an SBC can be achieved to meet the requirement of a zero-trust environment through voice network design. By configuring the network to use access registration through the SBC, all users, regardless of their location, must send their Session Initiation Protocol (SIP) registration through the SBC, which is then forwarded to the Private Branch Exchange (PBX) or Unified Communications (UC) Server.

Rather than just sending the packet through, the SBC acts as a Back-to-Back-User Agent (B2BUA), hiding the connection to the PBX or UC Server from the registering endpoint and vice versa. Once the PBX or UC server responds to the registration, the SBC will cache that registration to allow for continuity in the instance of a PBX or UC Server outage. If the registration fails, the endpoint will be blocked from making calls into the network as the SBC will deny the SIP messaging packets from setting up the call.

Authentication

An SBC can be configured to pass authentication in several ways. Typically, username and password or PKI certificates are the leading methods to provide authentication. Whichever method is chosen, the SBC will pass the required portions of the authentication in a newly created packet to the SIP registrar to provide authentication. Once registration is complete, the SBC knows that the endpoint is authenticated and any change in that endpoint, such as IP address or MAC address, will require a reregistration. Use of certificates provides increased security as the certificates must originate from a trusted root Certificate Authority (CA).

Encryption

There are three methods of encryption that can be configured on an SBC: Transport Layer Security (TLS), Secure RTP (SRTP) and IP Security (IPsec). Each of these methods can ensure end-to-end security for traffic, signaling and media and leverage trusted certificates.

Adding STIR/SHAKEN to ZTA provides another layer to protect against Caller ID spoofing. Secure Telephone Identity Revisited (STIR) and Signature-based Handling of Asserted Information Using toKENs (SHAKEN) was required to be implemented by most voice service providers in the US by June 30, 2021 and in Canada by November 30, 2021. With a policy engine and SBCs that are configured to utilize STIR/SHAKEN, voice service providers can verify that the origin of the call is actually who they are claiming to be through Caller ID authentication. This enables the carrier to  set policy to deny any calls that are likely to be spoofed.

SBCs and Firewalls were purpose-built to perform the specific security functions within their network environments. Neither is efficient in processing the types of traffic for the others capability set. For network security that encompasses all traffic, data and RTC, effectively, you will need both. Without either, your network will be affected in security, Quality of Service, or both.