Simply stated, all electronic components are subject to failure. The question is how resilient should we make these components to sustain temporary network fluctuations or security events? The ever-present challenge to an engineer is to keep the process up and running when it supposed to be, and to keep it safe. Knowing the failure modes of controllers, understanding design constraints such as network load and capacity, and understanding the other electronic factors that could impact the uptime of a process gives any engineer a keen advantage in performing their jobs. But with enough on their plates already, should this type of testing be added to their job functions?
When Wurldtech created the Achilles Evaluation platform, we knew that it demonstrated significant promise as a security research and evaluation tool and knew of the value it offers to critical infrastructure protection. I think we were all surprised to learn the extent such a tool is needed and the potential impact it could have. Putting an electronic device under test and creating a failure condition is simply a matter of experimentation and determination, to be sure, but if the objective were only to make a controller fail, then hitting it with a hammer seems one of the more effective strategies. From our perspective, it is about making control systems better, more resilient, and working with vendors so that they clearly understand how to design more robust equipment. Asset owners also benefit in the confidence of knowing that they are implementing a reliable system and that they know the design constraints so that they can build highly available processes that are easy to configure and administer.
Recognizing many of the strengths of device testing, several of our customers from the asset owner community began pushing hard on their vendors to incorporate changes from failure modes detected under test. This also led to several asking for a “certification program” to allow device vendors to design, specific, and subsequently test both in-house built components and externally acquired features such as network stacks. Wurldtech was the first to respond in this space with a device certification program to address our customer’s needs. Discretion being the better part of valor, however, we decided to tread carefully on the vendor relationships… what if no one passed? Leveraging what we knew already, we set out to define measurable and achievable objectives to demonstrate a minimum acceptable level of resilience of a control device. This activity resulted in the Achilles Level 1 Certification, representing years of combined device testing experience along with actual fieldwork to understand how and why these devices were deployed and under what conditions.
The first rounds of certified controllers have been rolling in, with more planned, and more vendors sending additional controllers to be tested. The simple fact is vendors like what we can offer them! Immediate feedback and a close relationship with our experienced testers yield actionable items that vendors can take now to improve their products. Often we have tested with the developers right beside who can see the results and then determine appropriate fixes on the spot. Shortening the time of detection of possible problems reduces time to market, and avoids the negative press of failures later on. Ultimately, this lowers time to market, improves reputations, and improves asset owner confidence in their selected solution.
Never before has a tool or set of test suites been able to clearly demonstrate not only at what point will a device experience a network fault, but what conditions actually cause the electronic behavior to change… after all faulting a network stack is one thing, causing a relay to open or a configuration to change, or an electronic I/O communication to interrupt now realizes the bigger concern in process control, causing something to physically change. Vendors can then take this valuable feedback to either make improvements in their products, work with their own suppliers to remove issues, or to provide design recommendations (such as network capacity and design constraints) to their asset owners.
I have personally been involved in far too many events to count where a network was not designed properly for process controls. Now such testing affords us the opportunity to know when a device will fail and under what network conditions, and more importantly what design in the product or network choices to make to avoid these issues. In the coming months, this certification testing will be extended more and more into the application layers, allowing for a deeper understanding of how and why devices fail.
Wurldtech is not a standards or an accreditation body, however, we do recognize the role of standards, and that this is ultimately the home for such criteria. As such, we will be working very closely with organizations such as ISA-99 and the ISA Automation Compliance Security Institute to offer content in the coming months to help create the a similar level 1 type certification as an industry standard. This of course will be subjected to public scrutiny and the consensus-based process, and we welcome the challenge. At the end of the day, Wurldtech wants to know that we raised the bar for the industry. With the first controller certification program out, and one that is uniquely positioned to understand the physical aspects of failure that vendors and asset owners really care about, we believe that we can offer significant leadership in this space. Once a level 1 certification is done, hopefully representing the basic network protection of control components, we will continue to drive and innovate to create more rigorous testing levels and then subject them to the same process.
For more information on ISA SP99, please visit:
http://www.isa.org/MSTemplate.cfm?MicrositeID=988&CommitteeID=6821
Additional information ISA SP99 can be viewed on Digital Bond’s site:
http://www.digitalbond.com/index.php/category/scada-standards/isa/
To learn more about the ISA Automation Compliance Security Institute, please visit:
http://www.isa.org/Content/NavigationMenu/Technical_Information/ASCI/ISCI/ISCI.htm