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.

• 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. 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: Patch it as an exploited flaw, then look back

Outcome

Patch it as an exploited flaw, then look back

With no sign of compromise after a real check, this is a vulnerability to fix fast. A VPN gateway is internet-facing, and an exploited flaw on it is Priority 1 in the pack's defaults: treat it as a potential incident, notify the standard owner at once, put a compensating control in within 72 hours and install the fix within 7 days. After patching, look back over the whole exposed period; that look back is our advice, not a pack step. Any sign found then 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.

• 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 on it or used through it

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 on it or used through it

Step

Change every credential on it or used through it

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, and the accounts of users who signed in through it during the exposure. Check the network behind it for new accounts, scheduled tasks and remote access tools. The pack does not list appliance secrets such as certificates or keys; replace any that were stored on it.

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

Decision

Can the vendor still supply fixes and a trusted image?

Patching and rebuilding both depend on the vendor. An appliance past its end of support, or one where the vendor cannot give you a clean image and a fixed 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: Do you know the route in and every change the attacker made?

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.

Decision

Do you know the route in and every change the attacker made?

This is the test the pack's ransomware playbook sets for each system before choosing between restoring and rebuilding. Applied here, it decides whether patching in place is safe. Yes only when the investigation has found how the attacker got in and has accounted for every change on the appliance. If you are unsure, the answer is no.

• Yes: Patch it in place, remove the changes and check it
• No, or not sure: Rebuild it from a clean image with a fixed version

Step

Patch it in place, remove the changes and check it

The ransomware playbook's rule for this answer, applied here by analogy: put the system right on its patched version, change its credentials and check it before reconnecting. For an appliance, install the fixed version, undo every change the investigation found and apply the new credentials. The patch closes the way in. It is not proof that the attacker has gone: that proof comes from the investigation and from the recovery criteria.

• Then: Are all five recovery criteria met?

Step

Rebuild it from a clean image with a fixed version

In the pack, rebuild means wiping it, installing again from a clean image and then restoring only data. For an appliance, that means re-creating its configuration rather than copying back a file the attacker could have changed. Where the attacker had administrator rights, the ransomware playbook rebuilds the systems it controlled, starting with the sign-in directory; applied here by analogy, check whether the appliance's access reached that far. The plan says not to rebuild before the evidence is safe, so take a full image first if it is not.

• 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.