Defense in Depth and Hardening

A precondition is something the technique cannot run without. A protocol is normally one of several interchangeable routes to the same thing, so blocking it moves the operator to another route instead of ending the technique.

Two controls are two layers only if getting past them means satisfying two independent preconditions. If both are satisfied by the same fact, such as one approved job identity, whatever supplies that fact clears both at once.

Disabling writes a configuration value while the SMBv1 code stays installed, so one administrative write turns it back on. Uninstalling removes the component itself, so there is nothing to re-enable until someone installs software again.

It evaluates the identity of a file at the moment something tries to load and run it: where the file sits, who signed it, or its exact bytes. It says nothing about what an already-permitted program is later handed.

One shared password turns a single compromised laptop into administrator on all 4,000: code already running as admin on one host reuses that secret to authenticate everywhere else. No exploit, nothing for a patch to fix.

No. Installing a package writes a new file to disk; every process already running keeps the old copy of the shared library mapped in memory and keeps executing it. Until those processes restart, the vulnerable code is still live.

Effectively one. All four are satisfied by the same fact: this is a legitimate pipeline job. A contributor entitled to edit the pipeline definition and start a build holds that fact honestly and clears all four without defeating anything.

No new file is presented, so no rule is consulted. Path, publisher and hash rules all answer one question - may this file run - and the script host is an approved, correctly signed file. The script is just an argument.

Three untouched preconditions: the built-in administrator secret that every host in the fleet still accepts, privileged accounts that sign in to low-trust machines, and privileged group memberships held permanently rather than on request. Removing user-level admin addresses none of them.

No. The percentage is an unweighted count of settings, not a ranked control set, so the same 92% is compatible with every load-bearing item failing and with every failing item being irrelevant. Defend the number by naming the handful of items that remove something your adversary depends on.

Ask for two numbers, not one. Installed count is on-disk state. Running count needs a per-host comparison: did the unit that loads this code start after the fix landed - boot time, process start time, running firmware version?

Only that one setting on the hosts checked matched the standard's recommended value at that moment. The standard is written for every reader of that platform, so a pass says nothing about whether your adversary lost a path.

Randomisation's whole protection is a secret: where things are. One leaked address recovers it, because everything inside a mapping moves by the same offset, turning a probabilistic guess into a deterministic exploit against that process.

One precondition is left: the token is accepted from whoever presents it. The control class that removes it is proof of possession - binding the credential to a key the presenter must prove they hold.

Almost nothing durable. The refusal is a configuration value that the administrator role is allowed to write, and the security package is still installed, so the capability sits inside the privilege the intruder already holds.

Time-bound elevation removes permanent membership as a target: an account compromised at a random moment holds no active privilege, and using it needs a request and an approver. It does not touch privilege already active, and bounds when, not where.

Name the technique, name what it consumes, then ask whether that thing still exists after the item is applied. If the adversary can substitute something or simply ask for slightly less, the item narrows. If there is no remaining path without first obtaining something new, it removes.

No. Live patching redirects individual kernel functions in memory, so it covers self-contained kernel fixes only. Data-structure changes, all userspace code and firmware still need a restart, and each patch stream is time-bounded.

Multiplication holds only across independent preconditions. Where controls are satisfied by the same fact, their costs add rather than multiply, and a control that inherits the fact entirely adds nothing — the real total is the cost of obtaining the shared fact.

No. A refused negotiation shows the dialect was declined by the hosts you reached, at that moment. Disabled and removed look identical from the client side, so the failure cannot tell them apart.

A deny only happens when a new file is presented. If the operator's next move was handing text to a permitted interpreter, the rule set was never consulted, so nothing was blocked. The foothold more likely stopped for economic reasons.

The laptop's administrator sits inside the boundary of that logon - the machine must be able to act for the account, so an intruder who already owns the laptop gains whatever that credential reaches. Tiering is a direction rule.

Refuse the safe-or-unsafe framing. Mitigations set a price on exploitation, and the price decides which adversaries can still pay; a rewrite removes the defect class for that component. Decide on component lifetime, exposure and which adversary you are actually funding against.

Treat the objection as a cost to fund, not a blocker to overrule. Pay for password retrieval inside the console his engineers already use, sequence the invisible removals first, and commit to a measured handle-time threshold with a real rollback.

Treat it as a downtime-budget decision, not a patching one. Either fund the redundancy that makes restarts cheap, mandate a periodic power cycle as a condition of hosting, or take a dated acceptance from the owner who refuses.

Because the permitted interpreter is the shell itself. Signature enforcement judges files at execution; a shell script is text the already-approved shell reads, so the payload never becomes a file that is checked. The generality stays.

Fork copies the parent's address space, so every worker shares one randomisation draw and one stack cookie value. A dead worker is replaced by an identical twin, so the attacker retries against the same secret and can learn it byte by byte.

A broker is paid once for a position he never uses, so his product must still work later from the buyer's own infrastructure. Only short lifetimes and possession binding destroy that; region and protocol blocks cost him nothing.

Re-anchor exactly one control, on the highest-consequence step only. Bind the promotion step to an approval from a human who cannot start jobs and did not author the change, leave every other job fast, and state plainly which pipelines are accepted at one precondition.