Certified Security, It’s Coming

Industrial controllers, devices and networks that are certified secure—comprehensively secure—don’t exist, for the simple reason that the standards are not all in place. But bits and pieces of the puzzle are coming together.

Aw 561 Certified11

If you want to hush a group of control engineers, simply say, “Stuxnet.”

In mid-2010, black hats took over software-based supervisory control at a handful of plants in highly targeted attacks. Similar types of malicious attacks, of course, have been at work in the personal computing world for decades—a land where battles against malware have long been highly visible. Waves of grief have washed over that universe, thanks to worms, viruses, misdirections, application stoppages, deliberate file corruption, you name it.

Still, it was something of a surprise when Stuxnet brought malware into the industrial spotlight. Plenty of speculation suggests the attack was specific, nation against nation, with military development the target. And while this a bit of a relief if you make orange drink rather than nuclear arms, the specter is now raised, and it will not go away.

Unfortunately, it is no harmless bogeyman. The closer your products contribute to military applications, national security or social infrastructure, the more frightening are the possibilities. But what if you could simply take your next network out of the box, check its labels or docs for security standards compliance, and relax, knowing that your whole control system will be immune to attack?

Yes, Virginia, standards are either in place or about to be.

Standards in place

Individual devices available today carry certification that they are in compliance with Wurldtech, a Vancouver, B.C. security technologies company providing cyber security under the Achilles moniker—specifically, certified for communications security. Based on groundwork from Dutch consortium WIB (Werkgroup voor Instrument Beoordeling; in English, Workgroup on Instrument Behavior), both the Achilles device certification and a second Achilles process certification around good networking product development practices lays down “a set of requirements and an associated certification program for suppliers to follow … to improve the quality of their cyber security processes and practices throughout the entire lifecycle of an industrial system.”

WIB and Wurldtech benefited from extensive work and input from Shell, British Petroleum, Invensys, Honeywell, ABB, Dow, DuPont, Sabic and a number of other large players in highly security-conscious industrial segments.

The two Wurldtech certification types illustrate the two primary strategies for securing a system: One focuses on specific operational parameters of specific devices; the other focuses on the research and development processes employed in the making of industrial networking components. The first measures the ability of features built into a device to prevent unauthorized access against a specific suite of attacks. The second prescribes the design criteria and available cyber security features required for the creation of a malware-resistant component, with the objective of ensuring that everything required to fend off attacks will be available to a trained implementer.

In the future, manufacturing equipment will be certified to standards such as those issued from the ISA99 industrial cyber security committee. As with most International Society of Automation (ISA) standards, these are intended to be comprehensive, and the process from conceptualization to standards publication is necessarily a long one.

The committee’s description of its purpose underlines the broad scope: “Develop and establish standards, recommended practices, technical reports, and related information that will define procedures for implementing electronically secure industrial automation and control systems and security practices, and assess electronic security performance. Guidance is directed towards those responsible for designing, implementing, or managing industrial automation and control systems and shall also apply to users, system integrators, security practitioners, and control systems manufacturers and vendors.”

Do we want standards?

In general, users want standards, at least according to a recent poll of Automation World readers (see sidebar, “Yes, No, Maybe”), where 65 percent of respondents indicated they wanted devices to be certified for cyber security. But—no matter how black and white the hats in the cyber shootout—the issues still have many gray areas.

“A lot of people ask for the architecture,” says Bryan Singer, principal consultant, Kenexis Security Corp. and co-chair of the ISA99 Committee. “ ‘Tell us what the architecture is and we’ll be done,’ they say. But technology changes too fast for that, both the technologies in controls and the technologies in malware. The answer lies in design processes—practices and procedures, strategies for commissioning systems, designs for operating and maintaining systems.”

In one sense, the ISA99 standards have a head start. In addition to WIB/Wurldtech parameters, ISA99 has welcomed basic concepts from guidelines and strategies across a number of industries, including roadmaps issued by the U.S. Department of Homeland Security, North American Electric Reliability Corp.’s (NERC) Critical Infrastructure Protection (CIP) guidelines, Airlines Electronic Engineering Committee (AEEC) Network Infrastructure and Security (NIS) reports, U.S. Federal Energy Regulatory Commission (FERC) security plans and programs, and similar, industry-specific initiatives.

 “If you have to sum it up in a few words,” Singer says, “it’s best practices—think about it right, design it right, and do it right. Sounds simple, and sometimes it is, but there’s a lot of effort behind that basic concept.”

The ISA99 Committee has already issued its first technical report, ISA TR99.03.01, “Security Technologies for Industrial Automation and Control Systems.” About this report, Singer says, “We went through all the technologies you would typically use to secure a control system, including firewalls, virtual Local Area Networks (LANs), antivirus software and a bunch more. The result is a capability assessment for an industrial setting, trying to delineate the key considerations. It’s a good document around the strengths and weaknesses of firewalls and many more malware-preventive strategies and tactics.”

Some of the necessary thinking and practices are directly analogous to those around safety. “You need to approach security with the same discipline you maintain for safety,” Singer says. “You have rigorous startup and procedures for safety levels—why don’t we have the same thing for networks?”

Bob Huba, DeltaV product marketing manager and security architecture expert for Emerson Process Management in Austin, Texas, underscores the analogy to safety. “For [industrial safety standards] IEC 61508 or IEC 61511, you have code and procedures that are firm, and they are well tested beyond normal control system behaviors. There’s a need to take the same kinds of requirements and carry them over to the security side. You can have different levels of safety systems and the same kind of level-based approach can work in the security arena as well.”

Building the right tools

“The responsibility right now is to follow best practices wherever they can be found,” Huba says. “Use the best tools to create the most secure system. A lot of the process is available. What’s missing right now is a complete set of tools to allow you to say that the best possible solution is in place and working. Standards will help people determine that they’ve done everything they need to do.”

More options for testing are in the mix, one of which is the ISA Industrial Security Compliance Institute (ISCI), with its embedded device security assurance testing, ISASecure. ISCI founding members include Chevron, ExxonMobil Research and Engineering, Honeywell, Invensys Operations Management, Siemens and Yokogawa. Key technical members include exida, Mu Dynamics and Rockwell Automation. In a move to consolidate methods and practices, ISASecure’s testing specifications were merged with those of Wurldtech Achilles in a move announced last October.

Meanwhile, with or without certification or standards, there are several ways to allay fears of malware, beginning with sealing any means of unauthorized access to the network: installing firewalls, assigning and enforcing passwords, removing or locking away keyboards, disabling Universal Serial Bus (USB) connectors, tossing out obsolete diskette or tape drives and the like.

Because so many groups have worked in such a variety of industries on security issues around similar kinds of industrial control systems (and also because many threats follow similar paths), there are a remarkable number of similarities among the precepts, developmental procedures and test parameters in all the available documents.

“Many of the people now working on ISA99 have been part of earlier initiatives over the years,” points out Ernie Rakaczky, program manager of cyber security for control systems for Invensys Operations Management. “We know each other and have come to respect each other’s take on the situation. The bits and pieces may be different, but a core set of the people has been the same for quite a while.”

Rakaczky cites three elements that any approach should take. “First, there are the specifics of the control system. How do you assign or change passwords? Who gets what user privileges? What’s the best way to minimize access?”

Second comes a set of guiding criteria around how to implement systems, from project management, to system baselining and parameters, to acceptance criteria, to ways and means to update the final system, because, as he says, “nothing’s ever final in security.”

“The third element is a document or document set that drives how the security program is implemented and managed,” he says. “The object is to make sure we’re doing all the things we need to do in support of the system and to make sure we’ve created the best possible umbrella of security.”

“In reality,” Rakaczky adds, “from the supplier side, design for security really should be a quality assurance program. When you wait until the end for certification, you’re waiting too long. It should be built into the ongoing developmental testing, the code, everything. It’s too hard to go back through the development cycle if something doesn’t meet the criteria.”

Big attacks, big money

There are some definite positive sides to the situation. A primary one is the meager financial return on investment for black hats. “The level of detail and investment in Stuxnet is incredible,” points out Charles Hoover, business development manager for security at Rockwell Automation. “There was a lot of technical knowledge required on levels not generally known, and a huge amount of money involved. There were four different zero day vulnerability attacks dovetailed into it and every one of those costs a great deal of money, without any of the returns possible, say, by infiltrating a bank’s database or siphoning off millions of credit card accounts.” Bottom line: ideological rewards will generally outweigh any financial gain, making the effort unpalatable to most black hats.

“Still,” he says, “a disgruntled employee can harbor a strong ideological motivation. The key for protection against most of these less-than-Stuxnet situations is a strong plant area model that allows you to section off areas. You need to make sure key areas stay locked down. That can be as simple as refusing to divulge a password because somebody forgot it, at least until you’re sure the person actually has the right to it.”

The levels and the details of standards development (and the follow-on growth of certification programs) run both wide and deep—one of the reasons that an ISA99 initiative takes a long time. Right now, antivirus software, strong password programs, intruder monitoring of network traffic and removal of easily accessed physical ports make up the most basic of programs. In a few years, a growing protective layer over industrial networks will include a multitude of best practices around procedures, system design and day-to-day operation, quantified into recognized standards. 

May 2011, Related Feature – Automation World Readers’ Poll: Yes, No, Maybe
To read the feature article, visit http://www.automationworld.com/feature-8770

Subscribe to Automation World's RSS Feeds for Feature Articles

More in Home