OT: Traffic Light Control (was Re: First real-world SCADA attack in US)

Jay Ashworth jra at baylink.com
Wed Nov 23 22:45:08 UTC 2011


> Within each intersection controller is a PC board with a diode matrix
> called a "conflict monitor". It has inputs from all of the green and
> yellow phases including pedestrian walk signals, turn arrows, etc.
> 
> It's the job of the traffic engineer installing the system to program
> the conflict monitor for that intersection. By default they're
> programmed for a simple North-South vs. East-West intersection of
> two-way streets with pedestrian controls. If anything different, the
> conflict monitor is reprogrammed in the field to match the
> intersection.
> 
> In the event of a conflict, defined as green, yellow or walk signals
> that would cause conflicting traffic being allowed, the conflict monitor
> forces the intersection into red flashing in all directions and
> disconnects control from the microprocessor until manually reset
> on-site. If networked, it also sends a conflict alarm. If the
> conflict monitor is removed, the intersection goes to flash.

So, while "flash" isn't the default condition, which the controller is
taken *out* of by the conflict monitor, that monitor is at least *static
logic*, with essentially no moving parts?  I can live with that, I guess.

> Conflicting green is only possible if the conflict monitor is
> mis-programmed or the external connections to the signal heads are
> mis-wired. Even a short-circuit in the external wiring between two
> green phases would be detected unless the feed wires of the
> conflicting phases are cut to the signal box.

Got it.

> In the real world, "Stuff happens". Trucks cut corners and turn the
> traffic heads to point the wrong way. Controllers get replaced with a
> stock unit after a failure or accident knocking down the signal box
> without being properly set up for that intersection.

Yeah.  But at least that's stuff you have a hope of managing.  "Firmware
underwent bit rot" is simply not visible -- unless there's, say, signature 
tracing through the main controller.

> But, an external cracker even with full access won't be able to cause
> a conflict. Massive traffic jams by messing with the timing, short or
> long cycles, etc. but not a conflict.

Which is what I was hoping for: a failure might cause that, but an attack
has to be a) local and b) fairly knowledgable.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274




More information about the NANOG mailing list