From a compromised endpoint to the next machine. Require authentication for that connection.

Suppose an employee's PC has been compromised.

The attacker can operate the PC and has obtained the employee's credentials. An internal file server or administration server may be the next target. If that server accepts the stolen credentials, the attacker may reach another machine while appearing to be a legitimate user.

Lantern DSSE addresses this next connection. Separately from authentication at the destination, it requires the user to authenticate before authorising the network connection.

Require step-up authentication for sensitive connections

Being signed in to an endpoint, or knowing a server's password, need not be enough to connect to a sensitive server. Require stronger authentication at that point. This is the idea behind step-up authentication.

For example, a policy can require a passkey used with fingerprint or facial verification, or authentication with a security key, for the connection in question. The aim is to require something an attacker cannot satisfy simply by entering the stolen password again.

Which connections require stronger authentication, and how strong it must be, depends on the work being done and the sensitivity of the destination. Routine traffic and administrative access to a critical server do not have to use the same conditions.

Hold the connection while the agent requests authentication

When a connection requires additional authentication and has no valid authorisation, DSSE holds it.

This is where out-of-band (OOB) authentication built into the agent comes in. The agent presents a dedicated authentication window, where the user completes the required authentication.

Once authentication succeeds and the required conditions are met, the held connection proceeds. The user does not have to initiate the connection again.

The sequence is simple: connect, complete the requested authentication, and continue working. There is no need to build a DSSE authentication screen into each destination application.

Here, OOB means that the connection traffic and the authentication used to authorise it take separate paths. In DSSE, the agent mediates that authentication.

Control of an endpoint need not authorise the next connection

The scenario considered here is an attacker operating an endpoint with ordinary user privileges, without the privileges needed to disable DSSE's controls or the means to complete the required step-up authentication.

Even if the attacker requests a connection to an internal server, that connection does not proceed unless the required authentication conditions are met. Authentication sits between being able to operate one endpoint and being authorised to connect to the next machine.

Displaying an authentication screen is only part of this. The requirement must be something the attacker's existing credentials cannot satisfy. Asking for the same stolen password again adds little protection.

Using a passkey with biometric verification or a security key to require the user's participation where needed is central to using OOB authentication against lateral movement.

Consider authentication strength and authorisation scope together

In operation, the authentication method matters, as does how far the result can be reused.

How old can an accepted authentication be? Which destinations does the authorisation cover? When is reauthentication required, and when should an authorisation be revoked? Consider these questions together with the sensitivity of the destination and the needs of the people using it.

The traffic being protected must also pass through DSSE's controls. Check the managed endpoints, network paths and exclusions to establish that the connections you intend to protect are actually covered.

Use EDR alongside DSSE to address the compromised endpoint itself

We recommend deploying endpoint detection and response (EDR) alongside DSSE. DSSE handles connection authentication and access control. It does not replace EDR's role in detecting and investigating suspicious endpoint activity and isolating affected endpoints.

A successful authentication does not make a compromised endpoint safe again. An attacker on the same endpoint may be able to use a valid authorisation obtained by the legitimate user.

Controlling connections to other machines also cannot, by itself, prevent data theft or encryption carried out entirely within the compromised endpoint.

Use DSSE to manage connection destinations and authorisation lifetimes, and EDR to detect and respond to compromise on the endpoint. Together, they address both the spread to other machines and the endpoint where the compromise began.

Evaluate the connection and authentication flow

Lantern DSSE is currently available as an Experimental release. Available authentication methods depend on the identity provider and endpoint configuration. Verify the step-up authentication and connection controls you need in an evaluation environment.

Check the complete sequence: the connection is held, the agent requests authentication, and the same connection proceeds once authentication is complete. Also check that access is not granted when authentication is left incomplete or does not meet the required conditions.

A legitimate user completes the requested authentication and continues working. An attacker faces a requirement that stolen credentials alone cannot satisfy.

After the compromise, require authentication for the next connection. That is the defence Lantern DSSE's OOB authentication aims to provide.