[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