If a VPN appliance may be compromised, do we patch, rebuild or replace it?

Start

A VPN appliance may be compromised

The trigger is usually a vendor advisory or a national CSIRT warning that a flaw in your appliance is being exploited, or an alert on the appliance itself. A remote-access appliance flaw added to the CISA Known Exploited Vulnerabilities catalogue is the pack's own example of an exploited weakness. The first question is not how to patch. It is whether the weakness has already been used against you, and whether it is known to be exploited.

• Then: Keep the logs, then check the appliance for signs of use

Step

Keep the logs, then check the appliance for signs of use

Ask your monitoring provider and IT provider to preserve the appliance's logs and extend their retention before anything is changed. Then look for the indicators the vendor or CSIRT has published, accounts or settings nobody made, sign-ins from odd places, and unusual connections from the appliance into the network. Record which accounts signed in through it, and from where.

• Then: Is there any sign it has been used against you?

Decision

Is there any sign it has been used against you?

This asks about your own appliance, not the world. Any credible indicator counts, and so does being unable to check, for example because the logs do not go back far enough. A check on a closed appliance has limits: CISA warned that attackers hid their traces from the vendor's integrity checker. The triage procedure's rule is that when you are not sure, you declare and set severity by the worst it could be.

• Yes, or not yet checked: Declare an incident and preserve evidence
• No signs, after checking: Is the flaw known to be exploited in the wild?

Decision

Is the flaw known to be exploited in the wild?

A flaw in the CISA Known Exploited Vulnerabilities catalogue, or one your vendor or national CSIRT says is being used in attacks, counts as exploited. A clean check does not clear such an appliance, because an attacker may have left persistence that survives a patch or a factory reset. If you cannot tell, answer yes.

• Yes, or not known: Treat it as presumed compromised, not as a patch job
• No: Patch it by priority, then look back

Step

Treat it as presumed compromised, not as a patch job

CISA's direction on exploited VPN appliances warned that a sophisticated attacker may leave rootkit-level persistence that survives a factory reset, and told agencies to isolate the device. This flow applies that to any exploited remote-access appliance. Do not wait for proof: isolate it, keep an image, and follow the incident route. The pack's own rule is the same in spirit: when you are not sure, declare.

• Then: Declare an incident and preserve evidence

Outcome

Patch it by priority, then look back

With no sign of compromise after a real check, and no known exploitation, this is a vulnerability to fix on its priority. A VPN gateway is internet-facing, which raises its priority; in the pack's defaults an exploited flaw there would be Priority 1, so this branch is for one that is not. After patching, look back over the whole exposed period; that look back is our advice, not a pack step. Any sign found then, or news that the flaw is exploited, makes it an incident and this flow starts again at the first question.

Step

Declare an incident and preserve evidence

A weakness in an internet-facing system used to get in is the pack's exploited-vulnerability category, and the incident plan's own phases are its response. Export the appliance's configuration and logs, and keep a copy of any image the vendor's tools can take, before anyone patches, resets or rebuilds it. A rebuilt appliance cannot tell you how the attacker got in. CISA's direction also expected the device to be isolated from enterprise resources.

• Then: Would cutting it off affect safety or essential operations?

Decision

Would cutting it off affect safety or essential operations?

A VPN may be how remote sites, on-call engineers or suppliers reach systems that others depend on. In the plan, the incident manager contains at once with the least disruptive action that stops the harm, and brings in the service owner and specialists before any action that would stop a service people depend on for safety or essential operations. Stopping a customer-facing service is the executive incident lead's call unless waiting would let the harm spread. If such operations depend on the appliance, or you cannot tell, answer yes.

• Yes, or not known: Contain around it; bring in service owners before cutting it off
• No: Isolate it, preserving evidence first unless harm is spreading

Step

Contain around it; bring in service owners before cutting it off

Keep containing meanwhile, the least disruptive way: close the access paths the attacker is using and disable affected accounts. Before cutting off the appliance, the incident manager brings in the owners of the services that depend on it and specialists, with outside responders where you lack the skills, and decides with them how far to go, for example moving users to another route first. Record who decided and why in the decision log.

• Then: Change every credential, key and certificate it held

Step

Isolate it, preserving evidence first unless harm is spreading

The plan's rule: preserve evidence first unless the harm is spreading; if it is spreading, isolate first and record what was lost. The incident manager may isolate a system without waiting for an executive, using the least disruptive containment that stops the harm, and tells the executive incident lead at the next update. Apply the vendor's mitigation or patch as part of containment if you wish. It does not end the incident.

• Then: Change every credential, key and certificate it held

Step

Change every credential, key and certificate it held

The plan says to assume the attacker had more than you have found. For an appliance that means its own administrator accounts, the service account it uses to reach your directory, the accounts of users who signed in through it, and any certificates and keys stored on it. CISA's direction was to revoke and reissue every connected or exposed certificate, key and password. The pack does not list appliance secrets, so add them to your own list.

• Then: Can the vendor still supply fixes and a trusted image?

Decision

Can the vendor still supply fixes and a trusted image?

Rebuilding depends on the vendor. An appliance past its end of support, or one where the vendor cannot give you a clean image and a fixed, supported version, cannot be made trustworthy again. The pack does not cover appliance replacement, so this is your own judgement with the vendor and your IT provider.

• No, or not known: Replace it, and do not reconnect the old one
• Yes: Rebuild per the vendor on a fixed, supported version

Outcome

Replace it, and do not reconnect the old one

Keep the old appliance off the network, labelled and stored as evidence until the incident manager agrees it may be wiped. Set up the replacement from a clean configuration, not a copy of the old one, with new credentials. It goes into service only when the plan's recovery criteria are met. Look in the network behind the old appliance as well; the replacement does not remove what the attacker did next.

Step

Rebuild per the vendor on a fixed, supported version

In the pack, rebuild means wiping it, installing again from a clean image and then restoring only data. A factory reset on its own is not enough for an exploited appliance, because persistence can survive it. Follow the vendor's rebuild instructions and move to a supported fixed version. Re-create the configuration by hand rather than copying back a file the attacker could have changed. The plan says not to rebuild before the evidence is safe, so take a full image first.

• Then: Look in the network behind it for what the attacker did next

Step

Look in the network behind it for what the attacker did next

Check the systems the appliance could reach for new accounts, scheduled tasks and remote access tools, and for unusual sign-ins from the appliance. Start with the sign-in directory and the accounts that passed through the appliance. The plan's rule is to assume the attacker did more than you have found, so this look belongs before any reconnection.

• Then: Are all five recovery criteria met?

Decision

Are all five recovery criteria met?

The plan returns a system to service only when: the route in is understood and closed; any image used was checked for integrity; it is patched, scanned and monitored with credentials changed; its owner has tested it; and the monitoring period has started. A patched appliance with no investigation behind it fails the first criterion.

• Yes: Reconnect it under closer monitoring
• No, or not yet: Keep it off the network until the gap is closed

Outcome

Keep it off the network until the gap is closed

Whatever criterion is missing goes back to the phase that owns it: the investigation for the route in, the technical responders for credentials and monitoring, the owner for testing. Keep users on the containment route agreed earlier in the meantime.

Outcome

Reconnect it under closer monitoring

Bring it back under closer watching. In the pack's defaults the monitoring period is 7 calendar days for Severity 1 and 2 incidents. The incident closes when the criteria are met, the monitoring period has passed without the attacker returning, and the case log is complete.