Secure communication and access: VPNs, tunnels, SSE and out-of-band management

Objective 3.2 asks you to manage an architecture so that it protects the infrastructure, given a scenario. This lesson takes how people and systems communicate with it and reach into it: tunnels, remote access and the users who hold it, encrypted messaging and file transfer, the management network, and the cloud-delivered security that now follows remote users around. It is also the applied lab for 3.2, because remote access is something you can configure and measure rather than only describe.

Why this matters

Remote access is where a large share of real intrusions begin, because it is the one route into the internal network that is deliberately exposed to the internet. Stolen credentials on remote access without multifactor authentication, and unpatched remote access appliances, have been the way in for a great many significant breaches.

The exam tests the mechanics -- which kind of tunnel, which access method -- and the judgement: who should have access, to what, and what still needs protecting when the tunnel is perfect.

The lesson

VPN types and tunnelling, and what a tunnel does and does not protect

Tunnelling wraps one network's traffic inside another so that it can cross an untrusted network. A virtual private network is a tunnel with encryption and authentication added, so the networks in between see only that two endpoints are talking and roughly how much.

• Remote access VPN -- one client to the corporate network.
• Site-to-site VPN -- two networks joined permanently by their gateways, invisible to users. Branch to head office, or on-premises to cloud.
• Clientless or TLS VPN -- access through a browser using TLS, usually to specific applications rather than the whole network.

The two tunnel technologies to recognise are IPSec, which works at the network layer and is the usual choice for site-to-site links, and TLS, which works higher up and passes through firewalls and address translation easily on port 443. Within IPSec, ESP is the part that provides encryption.

Full tunnel sends all of a client's traffic through the corporate network, so every filter and inspection applies. Split tunnel sends only corporate traffic through the tunnel and everything else direct: better performance, less visibility, and a client on the internet and your network at once.

What a tunnel protects: the confidentiality and integrity of data in transit between its two ends. What it does not protect, and each is an exam answer:

• Anything before or after the tunnel. A compromised client is a compromised session.
• The client's health. A VPN gives a malware-infected laptop a network path into the estate.
• Who is really holding the credential -- which is why multifactor authentication on remote access is not optional.
• The destination. A tunnel to a vulnerable application delivers the attacker there securely.

Remote access with least privilege, and managing the users who have it

Remote access is a privilege, and it decays like any other unless it is managed.

User management for remote access means:

• a named owner approves each grant, with a reason;
• joiners, movers and leavers are handled promptly -- a leaver's remote access goes on their last day, not when someone notices;
• third-party and vendor access is time-limited, enabled for a specific job and disabled afterwards, rather than left standing;
• access is reviewed on a schedule, and anything nobody can justify is removed;
• shared remote accounts do not exist, so every session is attributable.

Least privilege for remote access means granting the applications a role needs rather than a path onto the whole network. A contractor maintaining one system should reach that system and nothing beside it. Traditional VPNs make this hard, because they hand out network reachability by design; restricting a VPN user to a few addresses works, and per-application access through the service edge described below works better.

End-to-end encrypted messaging and secure file transfer

End-to-end encrypted (E2EE) messaging encrypts a message on the sender's device so that only the recipients' devices hold the keys to read it. The provider carries the message and cannot read it. That differs from ordinary transport encryption, where traffic is protected on the wire but decrypted at the provider's servers.

The security consequences cut both ways:

• the provider, and anyone who compromises the provider, cannot read content;
• the organisation's own retention, archiving, DLP and eDiscovery tools cannot inspect content on the server either, which matters where record-keeping is a legal duty;
• the endpoints are now where the plaintext lives, so a compromised phone exposes everything on it. E2EE moves the problem to device security; it does not remove it.

Secure file transfer replaces plain FTP, which sends credentials and files in cleartext. The usual choices are SFTP, which runs over SSH; FTPS, which is FTP protected with TLS; and HTTPS-based managed file transfer platforms that add access control, logging and automation. A hash published alongside the file lets the recipient confirm it arrived unaltered. File transfer servers face the internet and hold large volumes of other people's data, which is why such products have been targeted for mass exploitation: patch them urgently, restrict who can reach them, and delete files once they have been collected.

Out-of-band management, and the network you need when the main one is down

Out-of-band (OOB) management reaches devices through a path separate from the production network: a dedicated management network, console servers wired to devices' serial ports, a cellular link for remote sites, and the baseboard management controllers built into servers.

It matters twice. When the production network is down -- including during an attack or after a bad configuration change -- OOB is how administrators reach the devices to fix it. And it keeps management interfaces off the network users are on, which is where most attacks against those interfaces come from.

It is also the most privileged network you own: whoever reaches it can reconfigure or power off anything. So it gets the strongest controls -- multifactor authentication, a small set of named administrators, full logging, no exposure to the internet, and prompt patching of the management controllers themselves, which have had serious vulnerabilities of their own.

Security service edge, and the remote-access problem it was built to solve

The traditional model sent remote users through a VPN back to head office, so the office's security stack could inspect their traffic. Once most applications moved to SaaS and cloud, that meant hauling traffic to the office only to send it back out, so organisations split the tunnel -- and lost the inspection.

Security service edge (SSE) solves that by delivering the security controls from the cloud, close to the user, wherever the user is. Its usual components:

• Secure web gateway -- filtering and inspecting web traffic.
• Cloud access security broker (CASB) -- visibility and control over SaaS use, including unsanctioned applications.
• Zero trust network access (ZTNA) -- brokering access to a specific application after checking identity and device, per session, instead of putting the device on the network.

Some definitions also include cloud-delivered firewalling. SSE is the security half of the broader idea of combining networking and security at the edge; the exam names SSE.

The improvement is concrete: controls follow the identity and the device, not the building, and a compromised client reaches the applications its user is entitled to rather than a network to explore. Lesson 24 takes the zero trust architecture behind that.

Exam habits for remote access

What to take into the exam

• A tunnel protects data in transit between its ends -- not the client, not the destination, and not the question of who holds the credential.
• Remote access needs an owner, a leaver process, time-limited vendor access, reviews and multifactor authentication.
• Least privilege means application access, not network reachability.
• E2EE stops the provider reading content and also stops your own inspection; the endpoint becomes the target.
• Out-of-band management is the network for when the main one fails, and the most privileged network you own.
• SSE delivers web gateway, CASB and ZTNA from the cloud, so controls follow the user.