In a parcel-locker threat model, 'more logging' is proposed against a spoofed-courier threat - how do you check a control answers the threat?

## The failure being diagnosed The most common defect in the mitigation pass is not an empty row. It is a filled row that answers a neighbouring threat. Some control is genuinely useful, genuinely in the design, and genuinely records something about the incident - so it gets written next to a threat it does not close, and the model reports coverage it does not have. A parcel-locker network makes it concrete. The threat: an unauthenticated person presents themselves at the locker bank as the collecting courier and the locker opens, so the parcels and their value walk away. The attacker is anonymous and physically local; the asset is goods and the money they represent. The team writes 'add more logging' in the mitigation column. ## Check one: which property does it restore? Every threat is the violation of a security property. Impersonation of a party is a violation of authentication - the system accepted a claimed identity it should not have accepted. So the control that answers it must be one that decides identity better: a credential the real courier holds and an impostor does not, bound to the specific consignment, verified by the locker before it opens. Audit logging restores nothing about authentication. It restores the ability to say afterwards what happened - which is a real and valuable property, and the right answer to a different family of threats entirely. Booking it here is the classic wrong-neighbour mapping. A sharper way to say it: distinguish **preventive** controls, which stop the act, from **detective** controls, which observe it, and **corrective** ones, which undo or contain it. A detective control is an honest answer only when harm accrues slowly enough, or reverses easily enough, that a response inside the detection window actually helps. When the harm is instantaneous and physical - the door opens, the parcels leave - detection alone leaves the threat open, and saying so is the point of the check. ## Check two: where on the flow does it sit? The second failure is subtler, because the control family is right and only its position is wrong. Consider a business-to-business payments integration: your service sends payment instructions to a partner, and the modeled threat is tampering with instruction amounts and beneficiaries while the messages sit in the partner's queue, at the hands of a compromised operator or a compromised component inside the partner's estate. The proposal is 'encrypt in transit'. The family is right - this is an integrity concern and cryptography is the family that answers it - but transport security protects a hop and terminates when the message is received. Once the message is written to the partner's queue it is plaintext inside a system you do not control, which is precisely where the threat was placed. What answers it is integrity protection that survives the hop: sign each instruction at the point of authorization, carry the signature with the payload, and have the final consumer verify it before acting, so tampering anywhere in between is detectable and the instruction is rejected rather than executed. So the check is: draw the attacker's position on the flow, draw the control's enforcement point, and see whether the second is actually between the first and the asset. ## Check three: re-run the attack with the control assumed The habit that catches both failures, and several more, is to assume the control exists and works perfectly, then tell the attack story again out loud. 'The impostor arrives. The locker asks for a consignment credential. They do not have one. The door stays shut.' That narration either completes or it does not, and if it completes you have found a control that does not answer the threat, no matter how good the control is on its own terms. This also surfaces partial answers honestly. Perhaps the credential is a code shared with the courier company by email, and the impostor's route is to obtain that code. The narration now runs again through a different move, and that move is a threat in its own right that needs its own entry. ## What to do with the misplaced control Do not delete it. A control answering a neighbouring threat is usually still wanted - it is just filed wrong. Move the logging entry to the threats it does answer, such as disputes about whether a collection occurred and by whom. Then leave the impersonation row with an authentication-family entry, or leave it visibly uncovered, which is a far better outcome than a green row that lies. ## The habit to demonstrate In a review, ask of every mitigation entry: which property, at which point, and does the attack still complete? Three short questions, applied to a whole table, will find more real gaps than any amount of re-enumeration.