DDoS Mitigation for Air-Gapped and Restricted Networks

Start by narrowing the claim, because the phrase is used loosely and the loose version is wrong.

A network with no path to the internet cannot be flooded from the internet. If the term is being used precisely, internet DDoS exposure is not among that network’s problems, and a supplier presenting a mitigation appliance for a genuinely isolated enclave is selling something the environment does not need.

Almost no network described as air-gapped is one. What people usually mean is a restricted network: external connectivity exists, is deliberately narrow, is subject to written authorisation, and may not include a path from security equipment to its manufacturer. That environment does have DDoS exposure, and it has it in an unusual shape.

At a glance

Appliance	Constraint	What it rules out	What remains available
No outbound path to suppliers	Hosted consoles, external classification, live entitlement checks	Local classification, local administration, offline-loaded updates
No traffic may leave for analysis	Scrubbing services, external telemetry, cloud dashboards	On-device statistics, local retention, exportable records
Change control by written procedure	Automatic policy updates from a supplier feed	Operator-set thresholds with reviewable, revertible changes
Physical access controlled	Remote vendor support during an incident	Trained local operators, documented runbooks

Each row removes a convenience rather than a capability. What it removes, in every case, is somebody else doing the work — which is why staffing is the real cost of this architecture.

Where the exposure actually concentrates

In a conventional estate the exposure is spread across everything reachable from outside. In a restricted estate it collapses onto the small number of places where the two domains meet.

That concentration cuts both ways. There is less to defend, which is a genuine advantage. But the defended thing is singular, well known to anyone who has studied the organisation, and its loss severs the enclave from whatever it needed the connection for. A gateway that carries authenticated traffic from a partner network, or telemetry outward from an industrial system, is a target whose value an attacker can calculate precisely.

The traffic profile helps. Where a gateway carries only known protocols between known peers, the legitimate envelope is narrow enough to be described exactly — which makes rate and protocol controls far more effective here than in a general-purpose estate, and makes false positives easier to avoid because normal is genuinely narrow.

Internal exhaustion is the more common event

The incident that actually happens in these environments is usually not an attack.

A device fails and retransmits without backoff. A misconfigured application enters a retry loop against a service that cannot answer. A monitoring system is deployed with an interval three orders of magnitude too short. A broadcast storm forms in a segment where spanning tree was never configured properly.

None of these is hostile. All of them produce exhaustion, and the controls that address them are the same rate limits, protocol constraints and state protections a hostile flood would require. The mechanisms are described in the mitigation techniques section and none of them cares about the attacker’s intent.

This has a procurement consequence worth stating plainly: for many restricted networks the business case for a mitigation layer rests on internal reliability rather than on external threat, and a case built on the wrong one of those will not survive contact with a finance committee.

The constraint that shapes every product decision

One rule governs the shortlist: nothing in the enforcement path may require reaching the supplier.

That eliminates hosted management consoles as the sole administrative path. It eliminates external classification entirely. It eliminates live entitlement validation — which is the requirement most often discovered late, because it is not described as a dependency anywhere and behaves perfectly during a evaluation conducted on a connected network.

The fail-operational questions apply here in their strongest form. In a normal estate a licence grace period is prudence. In a restricted network it is the permanent operating condition, and a product whose grace period is measured in days is unusable regardless of how good its detection is.

Updates, offline

Signature and reputation data ages. In a restricted network it ages by design, and the estate has to decide what rate of ageing it accepts.

The procedure is well established and not technically difficult: signed packages, verified hashes, controlled media, a change window, a record. The questions to settle before purchase are whether the product supports offline update at all, whether the packages are signed in a way you can independently verify, and whether any function degrades when data passes a threshold age.

That last one catches people. A product that quietly reduces its confidence, or disables a detection class, when its data exceeds some age will do so silently in an environment where nobody is watching for it.

Weigh the ageing honestly. For volumetric and protocol-layer defences the loss is small, because those mechanisms depend on structure rather than on knowing which addresses are currently hostile. For reputation-driven controls the loss is substantial. An architecture that leans on the first and treats the second as enrichment ages well; the reverse does not.

Operations, which is where the cost is

Every convenience removed above is convenience that consisted of somebody else doing the work. No hosted console means local administration. No remote support during an incident means the person on site has to be able to act. No automatic policy feed means an operator sets and reviews thresholds.

Budget for that. The calibration discipline is the same one any serious deployment needs — measure in a monitoring-only mode across a full business cycle, read the legitimate peaks, set thresholds above them with a hold period, review as the profile grows — but here nobody else can do it for you and there is no fallback to a supplier’s operations centre at 3am.

The incident runbook and the escalation matrix both need local adaptation for this reason: their escalation paths assume a supplier can be reached, and in this environment they cannot.

What to specify

1. Full function with no outbound connectivity of any kind, stated per function, with the supplier enumerating what degrades.
2. Local administrative access independent of any hosted console, with its own authentication.
3. Offline update by signed package, with independently verifiable signatures, and a statement of what changes as data ages.
4. Local retention of incident evidence sufficient for whatever reporting obligation applies to you.
5. Operator-set thresholds, with changes that are reviewable and revertible without supplier involvement.
6. Any accreditation your regime requires, established before the technical shortlist rather than after it.

The sovereignty argument that generalises this to a national scale — where the constraint is jurisdiction rather than a physical boundary — is worked through in sovereign national DDoS capability. The reasoning is the same, applied to a larger enclave.