Classification Decides the Architecture: A Qatar Assurance Reading of the DDoS Question

Most guidance on choosing a DDoS architecture starts from the threat: what is being attacked, how large the attacks are, what the service can tolerate. That is a reasonable engineering sequence and it is the wrong opening move for an organisation assessed under a classification-led assurance regime.

In such a regime, the sequence runs the other way. You classify the information asset. The handling requirements follow from the class. The permitted locations and permitted operators follow from the handling requirements. And the architecture is whatever survives all three. By the time you reach a product comparison, most of the decision has already been taken — which is either an unwelcome surprise late in a procurement, or the cheapest possible way to shorten a shortlist, depending entirely on when you run the analysis.

A note on how this article treats regulatory text

There are no control identifiers, framework versions, classification tier names, deadlines or thresholds below. That is a deliberate constraint and it makes this guide more useful rather than less: assurance frameworks are reissued, tier nomenclature is revised between editions, and a specific reference frozen into an article sends a reader confidently to the wrong document.

What is described here is a method — the order in which the questions are asked, and what each answer forecloses. The answers themselves come from the current text obtained from the National Cyber Security Agency, read alongside the national data-protection instruments, and interpreted by your own compliance function against your own classification scheme. Where this guide names an authority, it is naming a body; it is not paraphrasing a rule.

The chain, stated plainly

Five links, and each one narrows the next:

Class of the information → permitted handling → permitted location → permitted operator → therefore, permitted architecture.

Nothing in that chain is unusual. Every organisation with a classification scheme accepts it in principle. What is unusual is applying it to a mitigation tier, because a mitigation tier does not look like a place where information is handled. It looks like a piece of network plumbing — and plumbing, in most people’s mental model, moves things without reading them.

What a scrubbing tier must read to work at all

It reads a great deal, and this is not a criticism of any product. It is what the job requires.

To distinguish an attacker from a customer, a mitigation tier has to see source addresses and build behavioural state around them. To classify protocol abuse it has to hold session state. To do anything useful at the application layer it has to see request paths, headers, user agents and cookies — and where the protection covers encrypted services, it has to terminate TLS and read request bodies, because a flood of well-formed encrypted requests is indistinguishable from legitimate traffic until something decrypts it.

So the inference that most organisations have never drawn explicitly is this. If a service is classified because of what its users do and what they submit, then the traffic carrying those requests is not a lower class than the service. It is the same information, in motion. And whatever tier inspects it has been handed that class — along with whichever entity operates that tier, in whichever country it operates it.

Run that inference across a service catalogue and it usually sorts itself into three groups quickly: public content where the analysis is trivial and cloud scrubbing is unproblematic; services holding personal or operational records where the analysis is the whole decision; and a small set where the handling constraints leave exactly one architecture standing. Most organisations discover they have been applying the third group’s answer to the first group’s problem, or — more expensively — the first group’s answer to the third group’s.

The second half: evidence is a by-product, or it is a request

The classification analysis tells you which architectures are permitted. Assurance asks a different question: prove it, repeatedly, to a reviewer.

Here the two architectures diverge in a way that has nothing to do with their technical merit.

When the inspection point is equipment your organisation operates, the assurance artefacts are generated by the act of running it. The configuration is yours to export. The logs are yours, with a retention period you set. A packet capture from the relevant window is a query against your own storage. A control test is scheduled against your own change calendar. Nobody outside the organisation has to agree to any of it, and none of it depends on a commercial relationship remaining in good standing.

When the inspection point is operated by a third party abroad, every one of those artefacts is a request. The other party’s interest — entirely rationally, and without any bad faith — is in supplying the minimum that satisfies the requirement, on a schedule that suits their support model, within a retention window written into a standard contract that was not negotiated around your reviewer’s expectations. You will usually get what you need. You will get it later, in less detail, and you will get it again next year only if the relationship still exists.

That asymmetry is the practical reason in-country inspection reads well in an assurance review, and it is a stronger argument than the sovereignty framing usually made for it, because it is about the cost of a recurring obligation rather than about principle.

What this does not decide

Two things, and both matter.

It does not decide capacity. An appliance behind your circuit cannot help once the circuit is full, whatever the classification analysis concluded, and the same national-scale volumetric event that would exceed your edge exists in Qatar as everywhere else. The classification analysis constrains where everyday inspection may happen; it does not manufacture headroom. That is why the destination for most classified services is an on-premise-first hybrid with a defined, rehearsed and time-bounded diversion path rather than an on-premise-only design — and why the diversion window itself needs its own handling position, agreed in advance rather than improvised during an incident.

It also does not decide the product. Classification narrows the field to architectures; within a permitted architecture, the ordinary evaluation criteria still apply, and our method page sets out the six we use.

Where the analysis touches the shortlist

Only in a few places, but they are load-bearing ones.

The first is what the equipment sends outward during normal operation. A product whose detection consults a manufacturer-operated intelligence service is, by construction, exporting something — and a classification-led reviewer will ask what, to whom, and where it lands. That is answerable; it is simply an additional flow to classify, document and re-assure each cycle. A product whose detection is trained and executed entirely on the customer’s own infrastructure removes the flow rather than documenting it, which is why HARPP DDoS Mitigator tends to shorten this particular artefact rather than improve it. Whether that matters depends entirely on the class you assigned; for public content it is an irrelevance.

The second is how many components the flow diagram has to describe. A single device covering Layer 3 through Layer 7 produces one hop to classify. Where the edge device handles L3/4 and the application-layer analysis lives in a separate ecosystem product — the normal shape of a NetScout Arbor deployment, where Edge Defense sits alongside Sightline — the diagram, the assurance file and the test plan each describe more than one thing. That is not an engineering criticism of a capable product line; it is an observation about how much documentation the design generates. Fortinet FortiDDoS is worth naming here for the opposite reason: it is frequently dismissed as a firewall feature and it is not, it is a purpose-built appliance, so the usual stateful-firewall objection does not apply to it at all.

Appliance	Control-set-led reading	Maturity-led reading	Classification-led reading
The first question asked	Which controls apply to this system	How well is this capability practised	What class is this information
What determines the answer	The system's scope and criticality	Evidence of repeatability and review	The data itself, before any system is named
Where a DDoS design gets caught	A control has no implementation evidence	The capability exists but has never been exercised	The inspection point handles a class it may not
Effect on vendor selection	Product must map to named controls	Product must be operable by your team, repeatably	Product's processing location and operator are part of the requirement
What a reviewer asks for first	The control matrix	The test record and the review trail	The data-flow, with a class against every hop
Most common failure	Controls documented, never monitored	Capability bought, never rehearsed	Classification done for storage, never for traffic in flight

Three reading strategies, not three levels of rigour. Most Gulf organisations are assessed against more than one of them; the value of naming them separately is that they fail in different places.

A working sequence

For an organisation starting this analysis rather than defending one already made:

1. List the public-facing services, not the systems. The unit of analysis is the thing users connect to.
2. For each, state the class of what a user submits and what the service returns — separately from the class of what it stores.
3. For each class, state the handling constraint in one sentence, obtained from your compliance function rather than inferred by the network team.
4. Mark which services can be inspected by a third party outside the country, which can be inspected by a third party inside it, and which cannot leave your own equipment.
5. Only now compare architectures, and only for the groups that have more than one option left.
6. Write the diversion position for every group before the tender, not during an incident.

Step two is where most of the value is, and it is also the step that gets skipped, because classification programmes are built for documents and a request body does not look like a document. It is worth an afternoon with the people who run the classification scheme.

Sources and further reading

Obtain the current national assurance framework and the applicable classification scheme directly from the National Cyber Security Agency, and read them alongside Qatar’s data-protection instruments as they apply to your entity type. For the cross-border processing analysis that follows from step four, the GCC data residency guide covers what a scrubbing tier processes and why “we do not store it” is not the same claim as “we do not process it”. For the structurally different problem of a market where international capacity itself is scarce, see the thin-transit guide.