[SCADASEC] How to develop a more secure PLC or RTU

Jake Brodsky ab3a at comcast.net
Mon Feb 18 11:31:22 CST 2008


OK, so while we're so busy attacking the embedded systems in PLC or RTU 
gear to see where they fail, what sorts of things could we do to shore 
up the security?

First, let's consider a physical application side:  A real key for the 
PLC that requires you to place it in one of three positions:  RUN, 
PROGRAM, and REMOTE, and SAFE RUN.

The REMOTE mode would allow for someone to change the PLC state, but 
only if they had a key.  SAFE RUN mode would preset all registers or 
counters with some pre-defined known safe values from which a program 
could start running.  In that mode, none of the PLC registers would be 
modifiable remotely.  It is intended to bring a program back on line to 
some safe state following a corrupted download or if we know there is an 
attempt to hack the PLC.

The PLC would have its own flash disk with it's own key file stored on 
it.  The installers would create the key file.  Then, anyone seeking to 
update the program would need to sign their program with something that 
would match this key or it wouldn't run.

Second, in the application, there needs to be a heartbeat.  The PLC 
should be able to report this millisecond heartbeat via a LAN connection 
so that severe excursions would be noted.

Third a profiling module should be present.  If the PLC becomes less 
responsive or it overruns, it would be good to know where the time was 
going.

Fourth, The RTU or PLC should have a capacity for identifying users and 
various programmers.  If someone downloaded a program that is defective, 
it would be useful to know who did it.  They may have a corrupted or out 
of date copy.

That's just a start of the security features.  Does anyone here want to 
discuss more?  I'm sure I haven't covered all of the things we need to 
know...


Jake Brodsky



More information about the scadasec mailing list