Plant IT really IS different

IT and Operations Differences I received an e-mail this morning from a Conference attendee wanting to know if I would give Continuing Professional Education (CPE) credits for the CISSP certification. I didn’t have an answer so I called the organization responsible for CISSP accreditation – the International Information Systems Security Certification Consortium (ISC2). I explained the reason for the call and explained a little about control system cyber security and what makes it different than traditional IT. He was not aware of the unique issues dealing with control systems. Suffice to say they are willing to provide CPE credits. As an aside, so is ISACA, the international organization for IT governance. I then had a chance to talk to some IT security professionals who will be attending the Conference. One fascinating issue is the root cause of the Hatch Nuclear Plant cyber incident (the automatic shutdown of a large nuclear power plant). An accepted tenet of patching systems is that it should be done first on off-line test systems to discover any possible system impacts. What occurred at Hatch puts a new spin on this issue as the root cause was the connections between systems - something that cannot be discovered in off-line testing. Other issues to be discussed include how do you secure, or effectively isolate, unpatchable systems and how do you address memory leakage in control systems that are designed to be shutdown for significant periods of time. The underlying purpose of these discussions is to get the IT and Operational organizations to better understand each others accepted design and operational practices which are often in conflict. Joe Weiss
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • <p>Joe,</p> <p>&gt;What occurred at Hatch puts a new spin on this issue as the root &gt;cause was the connections between systems - something that cannot &gt;be discovered in off-line testing.</p> <p>do you see this as a difference between "classical IT" and "operations"? connections and interdependencies are quite normal in all IT systems - by their very nature. and bugs and side effects caused by these interdependencies are the rule rather than the exception. both in "operations" and "classical IT".</p> <p>to find such bugs in advance one would need a test system which replicates the whole primary system as a whole - with all its components and interdependencies. Furthermore an elaborate test plan is necessary which covers all possible effects based on the interdependencies. Both is not very feasible. First of all there is the problem of test coverage - noone can design and run an exponential number of test cases. And certainly there are simply econcomic reasons - duplicating the whole systems is expensive. Although, I have been involved in the design and procuremnt of a huge control system where the test system relpicates all system nodes including the redudancy systems and the site-to-site interconnection. The test system will include a kind of 'process playback' feature which can be used to run through real-world process events which have been recorded in the primary system. We are speaking here of about 60 nodes for the primary system and 15 nodes for the test system. the question is if asset owners are willing to spend additional money for such a test system (ie. the costs for the additonal hardware and the playback feature) and the testing process.</p>


  • <p>Joe Weiss responds:</p> <p>I have some history in power plant simulation. Years ago, we considered using simulators as a means to identify potential cyber security issues and/or train operators to respond to cyber events. Unfortunately, the simulators were not designed to address cyber issues or to identify the types of system interactions that occurred at Hatch (in this case both the workstation and the PLC operated as designed - it was the cross-interaction that was the problem). One of the reasons for the discussion of this event at the Conference next week is to identify possible means of identifying such events. When looking at Aurora and Hatch, the question is what other significant types of scenarios are out there we have not addressed yet.</p>


  • <p>The test system I mentioned above is not a training simulator (which is a software component part of the main system), but a system replica used primarly for testing patches and updates under conditions which are as much "real-world" as possible. Up to a certain degree it should indeed be possible to use the system to simulate cyber events and train operators.</p>


RSS feed for comments on this page | RSS feed for all comments