Podcast with Nate Kube on Controller Security Testing
Recently I recorded a podcast with Nate Kube of Wurldtech who has done more hands on controller testing over the past years than anyone I know. It is fascinating to hear the testing techniques, trends and common findings in this specialized and complex field.
This podcast provides an overview of the basic three categories of testing, positive, negative and resource exhaustion, in the first five minutes and then gets more technical and specific on the the issues and common results in testing controllers. We talk about:
- The challenge of monitoring controllers for faults during testing and avoiding false negatives
- Failure modes in the different modules, e.g. i/o vs. Ethernet cards
- Unique aspects of testing systems with redundancy including safety systems
- Where controller RTOS and protocol stacks come from, how they are customized, and where bugs and vulnerabilities are commonly found
- more
The technical portion of our loyal readers will definitely enjoy this podcast.
Author: Dale Peterson
Posted: September 5th, 2007 under Assessment Tools.
Comments: 5
Comments
Comment from Jake Brodsky
Time: September 6, 2007, 10:49 pm
Nate mention casually “SIL3″ controllers in safety applications. To my knowledge using a controller for an SIS application would almost demand a stand-alone configuration. Attaching a network would lead to additional failure modes and would have an effect on the Safety Integration Function. One would expect to use other process instrumentation to detect the behavior of a safety system in such catagories. If someone says he has a “SIL3″ device on a network, I would conclude it is not a Safety Integration System. If it were, you’d probably have grounds for a malpractice law suit.
Oh, one other thing: I’ve never heard of SIL4. If there is such a designation. you can be certain that it is strictly a stand-alone device with redundant inputs, redundant instruments in 2oo3 configuration, redundant outputs and control devices, redundant and independent power sources, and so forth. No networked device I know of would be reliable enough to handle this sort of application.
I wouldn’t throw these terms around lightly. We try to keep industrial safety systems as simple, passive, and stupid as possible. Where a PLC does get in to the picture, you can be very sure it will be as minimalist as possible. I seriously doubt there is any good reason to network a safety system in any fashion.
Comment from Dwight
Time: September 6, 2007, 11:16 pm
Dale:
Very good pod cast on vulnerability scanning and a high level view of the process. I think Nate Kube did a great job of painting the picture of the issues.
I particularly like watching the I/O as the testing progresses.
It might be interesting to see a write up of quality assurance and the use of vulnerability testing for product life-cycle development.
Thanks,
Dwight
Comment from Dale Peterson
Time: September 6, 2007, 11:37 pm
Jake - I will admit Safety is not an area I claim any expertise on, but I have seen numerous safety system components with Ethernet cards.
Even more disturbing are the vendor efforts promoting the benefits of sharing information between SIS and control systems. If you have any doubts on this, just check out the articles and whitepapers at the controlglobal site.
In fact, the SIS/control information sharing vulnerabilities is still an area I’m chasing a paper for S4 2008.
Dale
Comment from Ralph Langner
Time: September 7, 2007, 6:16 am
Good that someone brings up the safety issue. I have seen several kinds of so-called “safe” devices with Ethernet connectivity, up to network wired emergency shutdown and network override of manual operation, and I am still waiting for somebody to explain how this could reasonably be termed “safe”.
Comment from Jake Brodsky
Time: September 7, 2007, 4:12 pm
Ralph, I’m shaking my head in disgust. I sure hope those systems aren’t running anything critical, such as the burner controls for a high pressure steam boiler, or a cooling water pump speed controller at a Nuclear Power Plant (Oh, wait…).
Gentle readers, allow me to point out that just because you’re using a SIL3 controller does not mean you’re running a SIL3 SIS. If the instruments, controls, and failure modes are SIL1 then the whole SIS is SIL1, with a very expensive SIL3 controller.
Likewise, I’m sure some marketeering genius thought that having a “SIL3″ device with Ethernet would be real cool. He doesn’t have to examine all the potential failure modes. Neither do the ignoramuses who buy such things. They may call it SIL3, but it’s barely suitable for SIL1 in my book.

Write a comment