Open and secure controls

Making control systems more open and interoperable also have made them more vulnerable to malicious acts, internal and external. A control system can be open, interoperable, and secure but that requires stringent attention to system design and plant-wide policies, procedures, and available technologies.

By Mark T. Hoske, Editor-in-Chief June 1, 2004

This article includes online extra material.

Making control systems more open and interoperable also have made them more vulnerable to malicious acts, internal and external. A control system can be open, interoperable, and secure but that requires stringent attention to system design and plant-wide policies, procedures, and available technologies. In recent months, the call intensifies to augment controls and automation security… not only from people with something to sell.

Have you actively participated in your plant-wide security plan, and adapted it appropriately for your control systems? To avoid what some have called “plug and plague,” you need take the following steps:

  1. Dispel myths that feed a false sense of security. Common misconceptions include that security is an IT problem and that obscurity (of PLCs, DCS, embedded or other controls) provides security (most breaches are from the inside). Another fallacy is that a firewall is all that’s needed for protection (laptops, which can travel, account for the vast majority of virus imports into a system).

  2. Do a security assessment of risk analysis, including those in control engineering, IT, and others. Rank risks and assess present and proposed safeguards. At the center of any plan are plant assets, and, moving outward, are operating system security (and remote access), application security, intrusion detection, anti-virus protection, firewall, and backups/disaster recovery.

  3. Establish rules, communicate and train, and enforce the rules. Visibility and consistency help thwart those who might consider causing trouble, and can help avoid unintentionally opening your systems to attack.

  4. Implement technologies to support security measures. Patches and updates help. For instance, Microsoft says its Windows Server 2003 switches off many functions by default, curtails network access if a password is left blank, and reduces “attack surface” by 60%.

  5. Consider security with any changes; validate and manage updates; and make appropriate changes to related documentation and training. It’s not a one-time effort; you need to assess, audit, check, revise, train, and do it all again regularly. Consider security intrinsic to every change.

While mayhem is a mainstay of general media reporting, Control Engineering remains an advocate for helping readers avoid problems; I’d really rather you take security seriously than write about your disasters later. Please read “Technology Update: Cyber security guidance,” an Online Extra to this issue. Also, find more tips with links to seven other items (sources for this info) with this piece online, in the June 2004 archive at www.controleng.com .

MHoske@cfemedia.com

More security tips; links to previous coverage

What’s the root cause of most control system security problems? Inadequate or nonexistent security procedures, because the system predates the time when security became a fundamental design requirement, suggests Marcos Taccolini, chief technology officer at InduSoft. He says systems need to be protected through design, development, deployment, and consistent communications to all with system access. Think about points where a system could be vulnerable and take advantage of available technologies, including encryption and passwords (enabled by default). All systems have weaknesses, he says; issues include privacy, data integrity, and authenticity at end devices, in protocol, applications, and network devices.

Taccolini advises that end-users follow client/server security fundamentals, make a secure server, use a firewall to restrict access to server, filter IP addresses, filter by TCP port, authenticate all data, encrypt communications, authenticate the server to clients, audit server logs, restrict physical access to server, stay current with operating system and application updates, document and practice disaster recovery procedures, and run virus-protection software. Make only data required for an intranet available in that server, he adds. Taccolini offered advice at a National Manufacturing Week conference session on security, on Feb. 26, 2004, in Chicago.

For related Control Engineering security reading, see:

  • Cyber security guidance, June 2004, Technology Update in this issue

  • U.S. GAO says control systems at risk of cyber attacks, May 2004

  • OSIsoft Conference: consultant says work needed to secure control systems

  • ABB Automation World: security means avoiding‘plug and plague,’ April 23, 2004

  • CRITICAL INFRASTRUCTURE PROTECTION: GAO Report to Congressional Requesters (March 2004), April 2004 Control Engineering Resource Center

  • Viruses and hackers and worms … oh my!, November 2003

  • Get Safe: Prepare for Security Intrusion, March 2003

  • Monitors logs, performance at network layer, January 2003