Mitigations: input validation, patching, encryption and defence in depth

Why this matters

The previous lesson located the defects. This one closes objective 4.2 with the responses, and its organising idea is a distinction CAS-005 tests repeatedly: address the cause, then the symptom — and know which one you are doing.

A web application firewall rule blocking a payload is a symptom control: useful, fast to deploy, and defeated by a variant. A parameterised query is a cause control: it removes the vulnerability class from that code path permanently. Both belong in a real response, and a scenario offering one of each is usually testing whether you will take the quick one and call it fixed.

The second idea is layering. No single control holds, so the question is not which control is best but whether the layers fail together. Two controls defeated by the same compromise are one control with extra cost — which is the same reasoning lesson twenty applied to enforcement points and lesson thirty to scanning methods.

The lesson

Validation and output encoding, and why allow-lists outperform deny-lists

Input validation checks that input conforms to what is expected. Output encoding ensures that data is treated as data in whatever context it lands. They are different controls at different points, and both are needed — validating input does not make output safe, because not all output came from validated input.

Allow-lists specify what is permitted; deny-lists specify what is forbidden. Allow-lists win, and the reason is structural rather than a matter of degree:

• A deny-list must anticipate every malicious form. Encodings, alternative representations, case variation, whitespace tricks, double encoding and parser quirks all produce inputs an author did not think of.
• An allow-list must only describe the legitimate form, which the application's author knows exactly. A field that holds a UK postcode has a known shape; a field that holds "anything except these forty patterns" does not.
• Deny-lists fail open — an unanticipated input passes. Allow-lists fail closed — an unanticipated input is rejected, which is occasionally inconvenient and never a breach.

Validation done well has four properties: it is server-side, because client-side validation is a usability feature an attacker simply bypasses; it validates type, length, range and format, not only content; it happens after canonicalisation, so that a single encoded form is checked rather than one of several representations; and it is applied at every entry point, including API endpoints that share a back end with a validated web form.

The limit to state honestly, because it is the reason the next section exists: validation is a mitigation, not a fix. Some legitimate inputs contain characters that are dangerous in some context — an apostrophe in a surname is valid data and is a quoting problem in SQL. A design that relies on validation to prevent injection is one legitimate input away from a choice between a vulnerability and rejecting real users. The fix is separating instruction from data.

Parameterised queries and safe APIs as the structural fix rather than filtering

The cause control for the whole injection class, and it is worth stating why it is qualitatively different from filtering.

With a parameterised query, the query structure is sent to the engine first and the parameters are supplied separately. The engine has already parsed the statement before it ever sees the data, so no value can change the structure — not because dangerous characters were removed, but because the data is never part of the text that was parsed. That is a categorical guarantee rather than a probabilistic one, and it is why it holds against inputs nobody anticipated.

The same principle across interpreters:

• Shell — pass an argument array to the process directly rather than building a command string for a shell to parse. No shell, no shell metacharacters.
• Templates — the engine receives data to substitute, never template text assembled from input.
• Directory queries — an API that builds the filter, rather than string concatenation.
• Deserialisation — a schema-constrained format that cannot instantiate arbitrary types, rather than a format that can.
• Browsers — set text rather than markup, and let the framework encode contextually.

Two cases where this needs care and scenarios exploit them. Dynamic identifiers — a table or column name chosen at runtime — cannot be parameterised in most engines, so they must come from an allow-list of known values rather than from input. And stored procedures are not automatically safe; a procedure that concatenates its parameters into dynamic SQL has the same vulnerability one layer down.

The architectural control that makes this stick across an estate is a safe default in the framework or data access layer, with the unsafe path requiring an explicit, greppable, reviewable construct. Relying on every developer to remember is a control with a known failure rate; making the safe path the easy one is a design decision that scales.

Patching as a mitigation with a lead time, and the compensating control that covers it

Patching is the cause fix for a known vulnerability in software you did not write, and its distinguishing property is lead time: between disclosure and your deployment there is a period, measured in days or weeks, during which you are exposed and cannot patch.

The period is not idleness — it is testing, change approval, scheduling and staged rollout, all of which exist for good reasons covered in lesson twenty-nine. But it is exposure, and the question a scenario asks is what covers it.

Compensating controls for the patch window, chosen by what the vulnerability needs in order to be exploited:

• Restrict reachability. If the vulnerable service need not be reachable from where the attacker is, a network or identity control removes the exposure without touching the software. Usually the strongest and fastest option.
• Virtual patching — a rule at a gateway, web application firewall or endpoint agent that blocks the known exploitation pattern. Fast, and signature-shaped, so it is defeated by variants.
• Disable the vulnerable feature, where the software allows it. Frequently overlooked and often the cleanest answer.
• Increase monitoring specifically for exploitation of that vulnerability, which does not prevent anything and shortens discovery.
• Configuration hardening that removes a precondition.

Three points that appear in scenarios. A compensating control is temporary by declaration, recorded in the exception register from lesson one with an expiry tied to the patch; removing it when the patch lands is part of the work, and accumulated stale virtual patches are their own problem. Emergency patching is the right answer when the vulnerability is being actively exploited and reachable, and its authority must be pre-agreed, per lesson twenty-nine. And some things cannot be patched — end-of-life software, embedded devices, vendor-controlled appliances — where isolation is not a temporary compensation but the permanent design, documented as such.

Layering controls so one failure is not a breach, with a worked example

Defence in depth is widely recited and frequently implemented as stacking rather than layering. The distinction that makes it real: layers should fail independently. Two controls that a single compromise defeats are one control with the cost of two.

Worked through an internet-facing application holding customer data, asking at each layer what has to be true for an attacker to continue.

The value is visible in the right-hand column: each layer is defeated by something different. An attacker who finds an injection point still meets a least-privileged account, still meets encrypted fields whose key the database does not hold, still meets a segment they cannot leave, and still generates egress that differs from the baseline.

Two design cautions. Correlated failure is the thing to look for — several controls administered by the same team with the same credentials, or several enforcement points configured by the same compromised pipeline, are one failure. And layers have cost, so the depth should follow classification, as lesson eighteen's table set out; a sandbox does not need this stack and restricted data needs all of it.

Choosing the mitigation the exam expects: address the cause, then the symptom

The closing method for the objective.

Given a scenario with several workable mitigations, rank them:

1. Eliminate. Remove the feature, the exposure or the data. The strongest answer whenever it is available, and the one candidates skip because it does not feel like a control.
2. Fix the cause. Parameterised interfaces, contextual encoding, the patch, the configuration corrected. Permanent, and it removes the class rather than an instance.
3. Reduce the exposure. Network and identity restriction so the defect is unreachable by the relevant attacker. Often the fastest strong action, and the best answer to "what do we do now" while the fix is prepared.
4. Block the symptom. Virtual patching, request filtering. Fast, weak against variants, and explicitly temporary.
5. Detect and respond. Necessary, and not a mitigation — it shortens the incident rather than preventing it.

Two reading habits for the question stem. "Most effective" usually means highest on that list; "immediately" or "while a fix is developed" usually means three or four. Scenarios distinguish those deliberately, and answering the wrong one is the commonest error in this objective.

And the closing observation that connects back to domain 1: every mitigation below the second line leaves residual risk, which belongs in the register with an owner and a review date. A finding "mitigated" by a temporary control and then closed is the defect lesson eight described — a remediation that reduced a risk to a level still outside appetite, recorded as complete.