Secure communication channels

Sub-domain 4.3 asks you to implement secure communication channels according to design: voice, video and collaboration, remote access, data communications, and third-party connectivity. The common thread is that data travels across networks the organization does not control, so the channel itself must provide confidentiality, integrity and authentication. This lesson covers virtual private networks, from IPsec to TLS-based VPNs and WireGuard; remote access and administration; voice over IP and unified communications; collaboration platforms; email security; and connections to third parties. The cryptography behind these channels, symmetric ciphers, key exchange and certificates, is covered in CISSP-112 lessons 8 and 9.

Virtual private networks

A virtual private network, VPN, creates an encrypted tunnel across an untrusted network, so that traffic inside appears to travel over a private link. Site-to-site VPNs connect networks, such as a branch to headquarters or a data center to a cloud provider, with gateways at each end. Remote access VPNs connect individual devices to a network. Both rely on tunneling, carrying one packet inside another, plus encryption and authentication.

Older tunneling protocols are worth knowing for the exam mainly as things to retire. The Point-to-Point Tunneling Protocol, PPTP, uses MS-CHAPv2 authentication that has been broken and should not be used. The Layer 2 Tunneling Protocol, L2TP, provides tunneling but no encryption of its own and is usually paired with IPsec as L2TP/IPsec. Generic Routing Encapsulation, GRE, carries many protocols in a tunnel but provides no security unless run inside IPsec.

IPsec

IPsec is a suite of protocols that secures IP packets at the network layer, so it protects any application without changes. Its main components are the Authentication Header, AH, which provides integrity and authentication of the packet, including most of the outer IP header, but no confidentiality; the Encapsulating Security Payload, ESP, which provides confidentiality, integrity and authentication of the payload; and the Internet Key Exchange protocol, IKE, now IKEv2, which authenticates the peers and negotiates security associations. A security association, SA, is a one-way agreement on algorithms and keys, identified by a security parameter index; a two-way conversation needs a pair. AH is rarely used today because it breaks when NAT changes the outer header, and ESP with integrity covers most needs.

IPsec runs in two modes. Transport mode protects the payload of the original packet and leaves the original IP header in place; it suits host-to-host communication. Tunnel mode encapsulates the entire original packet, header included, inside a new packet with a new header; it suits gateway-to-gateway and remote access VPNs and hides the internal addresses of the communicating hosts. IKEv2 authenticates peers with pre-shared keys, certificates or EAP and establishes keys with Diffie-Hellman exchanges, supporting forward secrecy. It also supports NAT traversal by wrapping ESP in UDP port 4500, and MOBIKE, which keeps tunnels alive when a mobile device changes networks.

TLS VPNs and WireGuard

TLS-based VPNs, often called SSL VPNs for historical reasons, carry traffic inside a TLS session, usually on TCP 443 or over DTLS on UDP. They pass easily through firewalls and proxies because they look like ordinary HTTPS. Clientless versions give access to web applications through a browser portal; full-tunnel clients give network-level access like IPsec. OpenVPN is a widely used open-source TLS-based VPN. Because VPN appliances are exposed to the internet and grant access to internal networks, they have been prime targets: several vendors' VPN and remote access gateways suffered critical vulnerabilities between 2019 and 2025 that were exploited at scale, prompting emergency directives from government cyber agencies. Managers must treat these appliances as high-risk systems, patching them quickly, monitoring them closely and planning for replacement by zero trust access where possible.

WireGuard is a newer VPN protocol, included in the Linux kernel since 2020, built around a small codebase of a few thousand lines and a fixed set of modern algorithms: Curve25519 for key exchange, ChaCha20 and Poly1305 for authenticated encryption and BLAKE2s for hashing. Its simplicity makes it easier to audit and fast, and it underpins several commercial VPN and mesh networking products. Its fixed cryptography means there is no negotiation to downgrade, but also no algorithm agility; a future change of algorithms means a new protocol version. WireGuard on its own does not handle user authentication or dynamic IP address assignment in the way enterprise VPNs do, so products wrap it with identity and management layers.

A design choice in remote access VPNs is split tunneling. In a full tunnel, all of the device's traffic goes through the VPN to the corporate network, where it can be inspected, but internet traffic is backhauled and performance may suffer. In a split tunnel, only corporate traffic uses the VPN and other traffic goes straight to the internet, which is faster but leaves that traffic outside corporate controls and can let a compromised device bridge the internet and the corporate network. Many organizations now split tunnel trusted cloud services while relying on endpoint and cloud-delivered security for the rest.

# Estimate tunnel overhead and the TCP MSS for several tunnel types (approximate byte counts)
MTU = 1500
INNER_IP_TCP = 40
tunnels = {
    'No tunnel': 0,
    'GRE over IPv4': 20 + 4,
    'IPsec ESP tunnel, AES-GCM': 20 + 8 + 8 + 4 + 16,
    'IPsec ESP in UDP (NAT-T)': 20 + 8 + 8 + 8 + 4 + 16,
    'WireGuard over IPv4': 20 + 8 + 32,
    'WireGuard over IPv6': 40 + 8 + 32,
}
for name, oh in tunnels.items():
    inner = MTU - oh
    print(f"{name:28s} overhead {oh:3d}  inner MTU {inner:5d}  TCP MSS {inner - INNER_IP_TCP:5d}")

No tunnel                    overhead   0  inner MTU  1500  TCP MSS  1460
GRE over IPv4                overhead  24  inner MTU  1476  TCP MSS  1436
IPsec ESP tunnel, AES-GCM    overhead  56  inner MTU  1444  TCP MSS  1404
IPsec ESP in UDP (NAT-T)     overhead  64  inner MTU  1436  TCP MSS  1396
WireGuard over IPv4          overhead  60  inner MTU  1440  TCP MSS  1400
WireGuard over IPv6          overhead  80  inner MTU  1420  TCP MSS  1380

Remote access and administration

Remote access covers more than VPNs. Remote desktop protocols, SSH and remote management tools give users and administrators direct control of systems from afar, and attackers love them for the same reason. Rules of thumb: never expose RDP, SMB or management interfaces directly to the internet; require multifactor authentication, preferably phishing-resistant, for all remote access; route administrative access through jump hosts or privileged access management systems that record sessions; and inventory every remote access path, including those used by vendors and IT support tools, which have been abused in supply chain attacks. Remote access servers authenticate users through RADIUS, Diameter or TACACS+; TACACS+ encrypts the whole payload and separates authentication, authorization and accounting, which suits device administration, while RADIUS encrypts only the password and combines authentication and authorization, which suits network access.

Older remote access technologies still appear in questions. Dial-up modems with callback were once used to verify a caller's location; a forgotten modem attached to a building system or a fax line can still be an unmonitored entry point. War dialling was the practice of calling ranges of numbers to find modems. Point-to-Point Protocol, PPP, carried IP over serial links and used authentication protocols such as PAP, which sends passwords in clear text, CHAP, which uses a challenge and hash, and EAP, which supports many methods.

Voice, video and unified communications

Voice over IP, VoIP, carries telephone calls over IP networks. The Session Initiation Protocol, SIP, sets up and tears down calls, and the Real-time Transport Protocol, RTP, carries the media. Unprotected, SIP signaling and RTP media can be captured and replayed, calls can be hijacked or redirected, and attackers can commit toll fraud by using an organization's phone system to place expensive calls. Controls include SIP over TLS for signaling and Secure RTP, SRTP, for media; separate voice VLANs with quality of service; session border controllers at the edge to protect against attacks and enforce policy; strong authentication for phones and softphones; restricting international and premium-rate dialling; and monitoring call records for fraud patterns. Spam calls and caller ID spoofing are addressed in North America by the STIR/SHAKEN framework, which signs caller identity between carriers.

Voice and video are sensitive to delay, jitter and loss. The ITU-T recommendation G.114 suggests keeping one-way mouth-to-ear delay below about 150 ms for good conversational quality. Every security device in the path, from firewalls to encryption gateways, adds delay, so designs must budget for it.

Collaboration platforms

Video conferencing, messaging and file sharing platforms have become core business systems. Risks include uninvited participants joining meetings, recordings and chat logs exposing sensitive information, data stored in other jurisdictions, external sharing of files and channels, and third-party apps with broad permissions. Controls include meeting passcodes and waiting rooms, authenticated participants for sensitive meetings, end-to-end encryption options where available, retention and records management settings aligned with legal obligations, data loss prevention policies, restrictions on external sharing and guest access, and review of integrations. Contracts with providers should cover data residency, breach notification, lawful access requests and audit evidence.

Email security

Email was designed without sender authentication, and it remains the commonest route for phishing and business email compromise. Transport security protects mail between servers: STARTTLS upgrades SMTP connections to TLS opportunistically, which an on-path attacker can strip; MTA-STS and DANE let a domain tell senders that TLS is required and which certificates to expect. End-to-end encryption and signing with S/MIME or OpenPGP protect message content but require key management, so they are used mainly in specific communities.

Three DNS-based standards help receivers decide whether a message really comes from the domain it claims. Sender Policy Framework, SPF, publishes the list of servers allowed to send mail for a domain. DomainKeys Identified Mail, DKIM, has the sending server sign messages with a private key whose public key is published in DNS. Domain-based Message Authentication, Reporting and Conformance, DMARC, ties them together: it checks that the domain in the visible From address aligns with a domain that passed SPF or DKIM, tells receivers what to do with failures through a policy of none, quarantine or reject, and requests reports. Since February 2024 large mailbox providers have required bulk senders to have SPF, DKIM and DMARC in place. A domain that does not send mail should publish an SPF record allowing no servers and a DMARC reject policy, so that it cannot be spoofed.

Email security also depends on gateways and user controls: filtering for malware and malicious links, sandboxing attachments, banners marking external mail, and processes that require out-of-band verification of payment changes. Business email compromise causes far larger losses than ransomware in many years' crime statistics, and no technical control fully replaces a phone call to a known number before changing a supplier's bank details.

Third-party connectivity

Organizations connect to suppliers, customers, managed service providers, cloud services and payment networks. Each connection is a path an attacker can use, as several high-profile breaches through heating and ventilation contractors, IT management software and managed service providers have shown. Controls include documented interconnection agreements or interconnection security agreements that define the purpose, data, security requirements and contacts for each connection; dedicated, segmented landing zones for partner connections with only the required flows; individual, multifactor-protected accounts for vendor staff; time-limited access granted on request and removed afterwards; monitoring of partner sessions; and regular review of whether each connection is still needed. Contracts should include security obligations, breach notification and the right to audit or receive assurance reports.

In the United States, sector regulators set expectations for third-party connections. The federal banking agencies issued interagency guidance on third-party relationships in June 2023, the New York Department of Financial Services' cybersecurity regulation, 23 NYCRR Part 500, requires third-party service provider policies and multifactor authentication for remote access, and federal contractors handling controlled unclassified information must meet NIST SP 800-171 requirements verified under the CMMC program (checked October 2026).

Thinking like a manager

When choosing a channel, start with the requirement: what must be protected, between which parties, and with what performance. Site-to-site links usually mean IPsec; remote users increasingly mean ZTNA or a well-managed VPN with MFA; voice means SRTP and SIP over TLS within a delay budget; and email spoofing means SPF, DKIM and DMARC enforced in stages. Treat every internet-facing access gateway as a critical asset to patch urgently. Govern third-party connections with agreements, least privilege, monitoring and periodic recertification.