A padlock and a duty roster beat the security system

In a published modelling study, engineers at the Instituto Militar de Engenharia in Rio de Janeiro had designed a protection system for a facility holding radioactive waste. On paper, it was compliant with the Brazilian nuclear regulator. Then they tested it against a defined adversary and timed every route to the material.

The benchmark was an 85 per cent chance of stopping the intruder. The compliant design scored 6.5 per cent.

The first improvement involved no new hardware. The model assumed that response time could be reduced from 464 seconds to 200 through changes to procedures, communication and the positioning of responders. That lifted the result to 78 per cent.

The second improvement was a padlock. It added 90 seconds of delay at a gate close to the material. The score rose to 92 per cent.

The facility was hypothetical and the figures were modelled, which is why the detail could be published. Even so, the result is hard to ignore. In the model, changes to response procedures and a well-placed lock changed the outcome because they changed the timing.

Security runs on a clock

Security projects are usually bought in pieces: cameras, sensors, fences, doors, control rooms and response contracts. The problem is that an intruder experiences them as one sequence.

Once an intrusion is detected, one condition matters. The delay still ahead of the intruder has to last longer than the response takes to arrive. If it does not, the system may record the event perfectly and still fail to interrupt it.

This is the logic behind the critical detection point used in physical protection design. Detect an intrusion before that point and there is still enough time to act. Detect it afterwards and the planned response may no longer arrive in time.

Response time moves that point. A faster response makes more of the site defensible. A slower response pushes the useful detection boundary further out. That relationship is easy to lose when sensors, barriers and guarding are specified by different teams.

The numbers I want to see

The two figures I look for are almost embarrassingly simple. How long does the response actually take? And after the alarm is raised, how long will the remaining barriers hold?

The word actually matters. A response time copied from a contract is not the same as a response time measured at three in the morning, in bad weather, with the usual staffing level. That is the number the design has to survive.

Barrier performance needs the same honesty. A substantial-looking gate is not a time value. Rated doors, windows and vehicle barriers are available, and their resistance can be written into a specification. Where formal data is restricted or unavailable, the design should at least say which barriers are intended to buy time and what threat they were assessed against.

A rating also needs context. Fifteen minutes against hand tools does not promise fifteen minutes against a cutting disc. The useful question is never simply, ‘Is this secure?’ It is, ‘How much time does this buy against the attack we are planning for?’

Remote sites change the answer

I learned the harder version of this on projects in the Papua New Guinea highlands. Some sites could only be reached by helicopter. Weather could turn a response time from minutes into hours. No sensible fence, gate or door was going to hold for that long.

In that situation, detection has to move outwards. It may need to begin on the approach road, over the water or in the air, while a vehicle or vessel is still well away from the asset. That is not an argument for one particular technology. It is simply what the timing demands.

Sometimes the condition cannot be met at all. Then the report should say so before an incident, not explain it afterwards. The system may still buy earlier warning, better evidence, containment or a smaller loss. Those are worthwhile outcomes, but they are different from stopping the event.

So before adding another sensor or strengthening another gate, I would ask for two measured times: response and delay. If the delay does not outlast the response, the rest of the design cannot rescue it. And if nobody knows the numbers yet, that is probably where the next piece of work should start.