Your whole policy ruleset was swapped for one that allows everything and sweeps stay green — how do you detect it?

## Why the whole-ruleset swap is the attack worth planning for Tampering with a single rule is narrow and comparatively noisy: the rule id is still in the inventory, its evaluation counts still move, and someone comparing rule text to the repository sees a diff. Replacing the entire ruleset with a permissive one is qualitatively different on three axes. - **Blanket.** Every control the enforcer carried is off at once, not just the one the attacker cares about. - **Persistent.** Nothing about it degrades. A permissive ruleset keeps working for as long as nobody compares what is loaded against what was published. - **Evidence-producing.** This is the nasty part. The control does not go dark; it goes *green*. It keeps generating clean runs that the organisation reads as assurance and may later hand to an auditor. The attacker has not merely evaded a control, they have conscripted it into vouching for them. ## The ways in The distribution point's write path is the obvious one: whoever can put objects there decides what every enforcer runs. Less obvious and usually less monitored is the **enforcer's source configuration**. Repointing the enforcer at a different location, or swapping the credential it fetches with, replaces the effective ruleset without a single write to the approved store, and change monitoring aimed only at the store never sees it. Treat the configuration that says *where rules come from* as part of the ruleset for review and alerting purposes. ## Why the enforcer's own telemetry is weak evidence The enforcer sits inside the boundary that was crossed. If an attacker can change what it loads, they can very often change what it says about what it loaded — self-reported digests, run metadata, log lines. This does not make the digest useless: it catches accidents, deployment drift and half-finished publishes, which are the common cases. It makes it insufficient as *adversarial* evidence, and the fix is corroboration from somewhere the attacker does not control. ## Three independent detections **1. Publish-path monitoring.** Emit an event on every write to the distribution point — who wrote, when, and what digest resulted — into a log the publishing identity cannot modify. Then define the expected pattern: publishes come only from the reviewed pipeline, only on merges, at a rate humans recognise. Anything else is an incident, not a ticket. This is the strongest signal because it fires at the moment of the change rather than waiting for a consequence. **2. Negative controls, or canaries.** Keep one or two long-lived resources that are deliberately non-compliant with the rule in question — an unencrypted volume in a sandbox account, sized and placed so it holds nothing real. Its finding must appear in every sweep. Alert on the *absence* of that finding. This is the only signal on this list that tests the whole path end to end: enumeration, rule loading, evaluation and reporting all had to work for the expected finding to appear. Design it carefully — document it so nobody helpfully fixes it, exclude it from any cleanup that would delete it, and tag it so it never pollutes real compliance metrics. **3. Digest reconciliation.** A job outside the enforcer compares the digest the enforcer reports it is running with the digest of the ruleset the publishing pipeline says it published. Cheap, catches the accidental and the half-competent, and is the one an attacker inside the enforcer can most easily fake — hence third. ## Shape signals you get almost free Even without any of the above, the *shape* of the output changes under a swap. The rule inventory shrinks or changes ids; per-rule evaluation counts collapse to zero; the total number of rules evaluated drops. Violation counts staying at zero is invisible, but rules-evaluated falling from ninety to four is not. Graph the inventory, not only the findings. ## The habit underneath all of it Alarm on absence, not only on presence. A control whose sole output is bad news is indistinguishable from a dead control during every period when things are fine — which is most of the time. Give every enforcer a heartbeat that states what it ran, over what scope, with which ruleset, and alert when the heartbeat changes shape or stops. That single discipline covers the swapped ruleset, the expired credential, the crashed scheduler and the silently narrowed scope with one mechanism.