Reader Comment 05-26-10 ICSJWG Agenda

Earlier today, Bob Radvanovsky, the man behind the SCADASEC mailing list (among others) posted a comment to yesterday’s blog about the Industrial Control System Joint Working Group’s Fall Conference. I had complained that the Call for Papers for that Conference did not include a listing for papers on any of the cyber security regulatory standards. Bob, the ever practical one, noted that “there is nothing there for ‘defining forensics capabilities’”. One of the problems, one of many unfortunately, with ICS security issues is the fact that there is no ready way to determine if an incident with an ICS system is due to a system error or an external attack. With the complexity of ICS systems (sometimes multiple computer systems with hundreds of devices, sensors and communications devices) there are a large number of potential individual failure points, numerous sources of possible communications errors, and typically an unknown number of points of potential outside access to the system. From personal experience I know that we unconsciously placed explicit trust in the data and response of our control system. I have taken part in probably a hundred or more process upset investigations where we used data historian information to try to track the root cause of the process upset. Not one time did we ever consider the possibility that the control system could have been the source of the problem, not even when we could not isolate another potential cause. Sure, we checked peripheral devices to ensure that the sensors and actuators were operating as expected, but we never questioned the system. The ICS security community does not limit its concern about cyber security to attacks by terrorists or even disgruntled employees. When they talk about cyber incidents they worry about those attacks, but also about unexpected interactions between system components, programming and operator controls. An unexpected opening of a drain valve on toxic chemical tank could be caused by any of those. In fact, if it must be admitted in public, incidents are much more likely to be caused by system problems than by terrorist attacks. So, Bob is absolutely correct; it would sure be nice if there were a reliable, easy to use tool that we could use to diagnose the cause of a system failure and quickly determine if it was the result of a deliberate attack, device failure, or some more complex unintended interaction between system components. While it probably wouldn’t change the immediate emergency response, it would certainly make it easier to fix the problem.