The Need for Security in Process Automation

Yesterday afternoon I attended a panel on security populated by Eric Byres, Kevin Staggs, and Matt Franz. Byres, of course, is the founder and former Director of the BCIT Internet lab, who moved to Wurldtech Analytical (which is run by his wife Joann) last month so he could maintain a non-academic "arms length" relationship with BCIT and still have the run of the lab. Staggs is Honeywell PCS division's "man on security." Franz is relatively new with Digital Bond, having left Cisco to join Dale Peterson fairly recently. Between them, they have "critical mass" knowledge and understanding of security issues as applied to process control systems and SCADA. "There are plenty of tests for devices," Byres says, "for safety, for EC, for temperature, humidity, and vibration, but nothing for security." Byres told a particularly gristly story."A couple of weeks ago, Joann and I were working with a hospital, in their critical care unit, and we accidentally brought down their network. We did a simple UDP port scan, and all the monitors in the CCU locked up. Nurses could have been looking at bad data while their patients quietly died on them. The incident data base we maintain has over a dozen such incidents." "What we need is common criteria," he said. We hear the government and others saying that we shall do vulnerability testing, but what is appropriate testing? He discussed Hans Daniel (a former member of the German security apparat) and his presentations at IEC. Daniel says that security can be discussed in terms of lifecycle. IEC 15288 defines five lifecycle stages, from which much can be deduced. Methods and standards, Daniel suggests, can be associated with the various parts of the lifecycle. "The more testing we do," Byres said, "the more security we have, with known deliverables." We need to test at development, integration, and operation stages. But it is like being the first ever to build a brick wall. "Don't design by guessing that the bricks are strong!" Remember, slammer is the most active event in ISID, yet the patch that fixes the vulnerability to slammer is four years old! Test standards can: --provide a level of confidence --a common measure --focus Test standards can't: --guarantee security --defend against device interaction --address other problems in the lifecycle "We need to operate under the KISS principle for now," Byres closed, "and focus on individual components and big wins for now." Kevin Staggs talked about security being a journey, once begun, that never ends. The guiding principle at Honeywell, he noted, is defense in depth. Security and increasing plant safety are key Honeywell initiatives, embodied in the company mission statement. "Security and safety," Staggs says, "go hand in hand." He should know, since he leads, at his own admission, the Honeywell Certified Ethical Hackers. Then Matt Franz repeated much of what already had been said, putting his own, ex-Cisco twist on it. "There is a lot of vulnerability testing that can have significant and immediate impact," he said. Testing, however, is no panacea. There is a lot of "basic stuff" that vendors and asset owners (end users) can do before going to the lab. He repeated several times that it "isn't fun" for lab researchers to keep doing the same vulnerability assessments over and over. Franz, like Byres, called for a common set of comparison criteria, or benchmarks. He suggested that research needs to be done to determine what kind of testing should be done. "We see a lot of assessment and framework overload, though!" he said. We need to somehow keep "raising the bar" on vulnerability assessments, he asserted. We need: --common definitions --clusters of discrete assessment activities (tests) mapped to: --types of vulnerability --who is the user --where in the lifecycle this vulnerability resides "We need a methodology for selection of test cases for different targets," he said. We need to determine which tools to use, when to use them, and why to use them. We need to know what percentage of the "attack surface" of your device, system, or integration use case is unique. That's what you should test, not merely repeat testing on devices tested before. "You don't have to test your CISCO router over again," he declared. Different types of target need different tests. Interface, device/appliance, application, system and solution targets all need different test types and different testing protocols. "And we should be sure we know," he went on, "what types of vulnerability are we checking?" Are we checking known vulnerabilities in infrastructure? If we are, why? Are we checking for robustness? Are we checking for application misconfiguration flaws, or network misconfiguration flaws? Are the checks we are doing valuable? The challenges: Easy problems include diverse users bases, diverse technical bases. The hard problem is making the business case for security. Especially since there are perceived, AND REAL, risks for vendor exposure. "As I said earlier," Franz continued, "there is a real need for end users to do testing themselves, in their own applications." At a minimum, users can initially focus on testing aspects of the system that they, themselves, have control over. (What a "Duh!") It sounded like all three panelists were making a case for the establishment of the testing and certification foundation Johann Nye talked about on Monday.