How do you decide on a vulnerable-driver blocklist when enforcing it breaks a production driver?

## Why this is a decision and not a configuration A vulnerable-driver blocklist refuses to load kernel drivers that are known to expose abusable primitives. It is one of the very few controls that removes an entire technique rather than making it more expensive - if the driver cannot load, borrowing its signature stops working. The awkward part is that the entries are **real drivers from real vendors**, and some of them are load-bearing for somebody. Diagnostics tools, firmware flashers, industrial control interfaces, older backup agents and hardware utilities all show up. So the control's cost is not compute or licensing; it is that turning it on can stop a business process, and the person who owns that process did not ask for this. That is what makes it a judgment rather than a setting: the security benefit and the operational cost land on different people's budgets. ## Step one: measure before you argue Enforcement decisions made from imagination are always wrong in the direction of caution. Run the control in its reporting mode first and find out which machine classes actually load a listed driver. Two things usually come out of that: - The affected population is much smaller than the objection implied - frequently a handful of engineering workstations or one line of equipment rather than a fleet. - Some of the loads are not needed at all: an installer left a driver behind, or a utility nobody uses any more still registers one at boot. That second category is free progress and should be cleared before any negotiation starts, because it shrinks the thing you are negotiating about. ## Step two: default enforce, scope the exception The most common failure is treating this as a single fleet-wide switch, so one objection keeps the whole estate unprotected. Split it. Enforcement becomes the default for every machine class that does not need the driver, which is nearly all of them, and the exception is scoped to the smallest population that genuinely does. The exception then carries its own conditions - and these are what make it defensible rather than merely conceded: - **No general administrative reach.** The technique requires administrative rights before the driver can be installed or opened, so restricting who is an administrator on those hosts directly removes the precondition. - **Keep the population out of the general estate.** If the machine cannot be reached from the ordinary user network, the exception is worth much less to an adversary who is not already there. - **Tighter change control** on what else runs there, because the exception host is now the softest kernel target you own. ## Step three: name the owner, and it is not you An exception is an acceptance of risk, and acceptance belongs to whoever owns the thing being protected by it - the manager of the production line, not the security architect. That is not bureaucracy. It changes behaviour: an owner who has signed for a risk funds its removal, whereas a risk absorbed silently by the security team stays forever. Write the acceptance in the terms the owner cares about - what happens to production if the driver is used against them, versus what happens if it is removed today - and let them choose. ## Step four: give it an expiry and a funded route out Every exception needs a date and a named path off it, of which there are only three honest ones: 1. **The vendor ships a fixed driver.** Ask for it explicitly, with the blocklist entry as the reason; a customer request from a real deployment is what moves vendor roadmaps. 2. **The component is replaced.** This is a capital decision with a lead time, which is precisely why it needs an owner with a budget and a date rather than a security recommendation. 3. **The capability is retired.** Sometimes the honest answer is that the utility is not worth a permanent kernel-level hole and the workflow changes. If the vendor no longer exists, route two or three is the only one available, and saying so early is more useful than a year of escalating reminders. ## What to refuse Two positions are not defensible and both get offered. The first is leaving enforcement off across the whole fleet to avoid one conversation - that is a fleet-wide risk purchased to spare a single team a decision. The second is enforcing globally with no notice and letting the line stop, which converts a security improvement into a reason nobody trusts the next one. The distinguishing feature of a good outcome here is that the exception is *small, conditional, owned and dated* - four properties that an exception granted informally never has. ## The strategic point behind the specific decision The underlying inventory - legitimately signed drivers with abusable primitives - is public, growing, and outside anyone's control. That means the blocklist will never be complete and enforcement will keep colliding with somebody's tooling. Planning for that is the actual principal-level move: a standing process for exceptions with owners and expiry dates, a procurement rule that new hardware must not depend on a listed driver, and a second control that limits what an abused primitive converts into - kernel code integrity enforced from a layer the kernel cannot edit - so the blocklist is not carrying the whole weight on its own.