ABB Automation World: security means avoiding ‘plug and plague’

Atlanta, GA—More open systems have created “plug and plague concerns,” says Stephen L. Thomas, associate project engineer for Olin Chlor Alkali Products, during his presentation at ABB's Automation World conference on April 21.

By Control Engineering Staff April 23, 2004

Atlanta, GA— More open systems have created “plug and plague concerns,” says Stephen L. Thomas, associate project engineer for Olin Chlor Alkali Products. This division of Olin Corp. (McIntosh, AL) manufactures chlorine, caustic soda and related products. “It’s so easy to connect to open systems, problems may not be detected until after the fact, and the problems can affect the entire network,” says Thomas.

Don Richardson, Microsoft director of manufacturing solutions, suggests that control systems may be more vulnerable than once thought because of a number of misconceptions, including that security is an IT problem and that a firewall is all that’s needed for protection. Thomas and Richardson agree there’s a need for better discipline by individuals and companies, as well as more proactive policies, procedures, and technologies to counter attacks. Each discussed security concerns in presentations at ABB ‘s Automation World conference on April 21.

Olin also has plants in Georgia, New York, and Tennessee, and had a “home-grown QNX-based control system.” Thomas says this system was considered relatively closed because it didn’t use Microsoft Windows or Ethernet TCP/IP, which limited interoperability and outside access. This provided “security through obscurity,” adds Thomas.

Installation of Olin’s first ABB control system in April 2003 offered the ability to use new applications, as well as easier opportunities for continuous improvements. However, a more open system also presents new security challenges. “An open system is easier to modify, connect, and attack,” says Thomas, who adds that internal attacks are deemed more likely than external ones. He draws a distinction between safety and security, which should be independent to avoid the failure of one affecting the other. Security risks, he adds, are harder to quantify than safety risks.

Thomas recommends working with IT and other stakeholders at risk analysis identification, ranking, safeguard assessment, application of protective layers, security management monitoring, recovery, change management, documentation, and training. “It’s easy to accidentally open holes in protective layers that you think you have in place,” he says. For example, opening firewall ports to allow one application’s DCOM-based communications would have left Olin vulnerable. In a model similar to the familiar safety layers of protective analysis (LOPA), Thomas reports that Paul Baybutt of PrimaTech offers Rings of Protection Analysis (ROPA), which adopts LOPA to security for process control systems, providing consistency, repeatability and documentation. At the center are plant assets, and circling around that are rings of operating system security (and remote access), application security, intrusion detection, anti-virus protection, firewall, and disaster recovery on the outermost ring.

Most plants do a good job on physical security, but there’s a temptation to share resources, as the base technologies become more similar, Thomas adds. “Separate IT and controls. Don’t share cabinets, paneling, or fiber-optic runs. Locate everything inside a control cabinet in a limited-access area,” he recommends: “We should all live happily together and by the same rules. Microsoft Windows’ security is improving, but it’s more of a concern for us than previously,” before Olin had a Windows-based system.

Microsoft describes myths Richardson explains that Microsoft has more than 1,000 people working on secure code; requires security training for all code writers, and is designing code and applications to be less vulnerable. For example, Microsoft Windows Server 2003 has a 60% reduction in attack surface; network access is curtailed if a password is left blank; and many functions are switched off by default, he says.

Richardson adds that he spends time fighting misconceptions. Some common myths are that security is really an IT issue; a firewall will secure a network; separating IT and control networks will reduce security risk; all patches result from an exploit or virus; embedded systems are more secure; PLCs can’t be hacked; Linux or Unix operating systems are more secure than Windows; and that wireless LANs are always insecure.

Older systems, such as Windows NT 4.0, which Microsoft will stop supporting this year as part of a seven-year lifecycle commitment, were never not outfitted for Internet. Even disconnecting control systems from everything else, reverting to an island of automation, isn’t the answer, since laptops account for 95% of virus imports into a system, according to Richardson. Holding up his laptop, Richardson says Microsoft itself has “brutal” security measures, requiring a password, hard-card plug-in, a full notebook scan and upload of the latest protection, prior to allowing network access, remotely or at its campus in Redmond, WA.

Richardson’s resources for security include:

Microsoft

National Cyber Security Partnership

CIDX

NIST Process Control Security Requirements Forum

ISA Standards Department Report on Industrial Systems Security

For more, read related news from Control Engineering ’s “ U.S. GAO says control systems at risk of cyber attacks .”

For more from Primatech’s Baybutt, see a 17-page PDF white paper, “ Cyber Security Risk Analysis For Process Control Systems Using Rings Of Protection Analysis (ROPA) .”

For more from Control Engineering about the ABB conference, see “ ABB professes strengths; increases manufacturer competitiveness .”

Control Engineering Daily News DeskMark T. Hoske, editor-in-chiefMHoske@cfemedia.com