DHS cybersecurity director on avoiding security vulnerabilities when connecting to the IIoT

Marty Edwards, head of the U.S. Industrial Control Systems Cyber Emergency Response Team, speaks about security vulnerabilities when control networks connect to other environments.

By Dave Perkon, technical editor

1 of 4 < 1 | 2 | 3 | 4 View on one page

Fundamental security issues can be introduced when connecting control system environments to other environments such as business networks. Marty Edwards, director of Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) at the U.S. Department of Homeland Security, spoke exclusively with Control Design about several issues that need to be addressed when deciding to open your network and share data.

ICS-CERT works to reduce industrial control system risks within and across all critical infrastructure sectors by coordinating efforts among federal, state, local and tribal governments, as well as industrial control system owners, operators and vendors.

Edwards brings more than 20 years of experience and a strong control systems industry focus to DHS. Before coming to the ICS-CERT, Edwards was a program manager at Idaho National Laboratory. He has also held a wide variety of roles in the instrumentation and automation fields, including field service, instrument engineering, control systems engineering and project management. Edwards holds a diploma of technology in process control and industrial automation (magna cum laude) from the British Columbia Institute of Technology.

CD: At Control Design, we appreciate the work you’re doing every day. Thank you for the letter regarding our “Tear Down This Wall” cover story. We’re definitely serious about cybersecurity, but perhaps, like many of the machine builders out there, we don’t know as much as we should. You said in your letter that incidents are happening daily. What’s a typical cybersecurity incident related to industrial control systems?

Edwards: They can be detected through a variety of means, and they can actually span a fairly wide range of incident types. Incidents range from what I call commodity-type malware which could be a Trojan design dealing with banking information that is proliferating around the Internet accidentally getting into an industrial control system and infecting the machines. Or it could range all the way out to a significant, advanced and persistent threat from a nation-state-level actor who is very surgically and specifically targeting that control system for whatever the reason is.

CD: Are they causing any type of damage, or what is the typical result when an intruder compromises the control system environment?

Edwards: We don’t have a lot of cases documented globally where actual damage has occurred. Probably the most widespread incident that’s been talked about is Stuxnet, which actually caused damage to process equipment. There’s also an incident widely recorded in the open press in Germany of a steel mill that may have had some type of malware impact its steel-making process. But, for the most part, the incidents of the malware don’t really cause much harm. It would be more of an annoyance if it were in the sort of commodity malware family. But certainly there could be loss of production involved if you have to take a system off-line to clean it up or if the malware somehow affects the processing or uptime of the control system itself causing it to go off-line, resulting in production loss.

CD: So, the Industrial Internet of Things is coming, whether anyone likes it or not. Some are saying it’s not secure, but nothing’s going to stop it. For the average machine builder though there are likely some safety issues they should be aware of that perhaps they don’t pay as much attention to. Are there things the machine builder and controls designer should be doing to address security issues?

Edwards: Yes, absolutely, and I have a lot of empathy for the control system designers because, before coming into this role in security, I was a control systems engineer working both for vendors and users. My background is in the distributed control system area that did continuous plants, but I certainly have empathy. I think the advice is to very clearly understand what your system or machine is designed to do, and it’s, for example, a life-safety type of application, or you’re doing some type of engineered controls where you have to prevent entry into an area; you want to make sure that those types of systems are completely 100% air-gapped or isolated from any corporate environment, any engineering type environment, any other networks.

The life-safety types of systems should be completely stand-alone and very rigorously protected from a change control point of view. As you get into other systems that don’t have a direct life-safety type of application, such as a process skid in a typical manufacturing plant, there’s a lot of impetus to connect those to your corporate environment and to your other control-system environments, and what you have to do is look at the risk of compromise or malfunction of that device versus connectivity from a business perspective. Usually it’s not the integrator that can make this decision; it’s the asset owner or the owner of the manufacturing plant.

1 of 4 < 1 | 2 | 3 | 4 View on one page
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.


No one has commented on this page yet.

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