Properly Tackle Your Cyber-Security Vulnerabilities

Start by getting a realistic view of weaknesses in your specific hardware and software.

By Jeff Melrose, Yokogawa

1 of 2 < 1 | 2 View on one page

Companies using or providing industrial automation systems never want to receive news that a vulnerability has been identified that could allow a cyber criminal to break into a system to do damage or steal information. Anyone who pays attention to the cyber security world knows about these sorts of problems.

Microsoft has to correct such vulnerabilities in Windows and other platforms on a monthly basis, or even more often in some cases. The hand wringing about Microsoft discontinuing security updates for Windows XP shows that hackers are still finding new vulnerabilities; others certainly still are waiting to be discovered, even after more than 12 years of security updates and improvements.

Vulnerabilities of one sort or another exist in virtually every software program of any size or complexity. While programmers do their best to create reliable and secure software, some weaknesses will arise when programs have many thousands or even millions of lines of code. These vulnerabilities may not interfere with normal operation but one might provide an entry that can be pried open with the right tools and strategy if a cyber criminal wants to break in.


The U.S. Department of Homeland Security supports an Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) that provides many helpful resources and services for industrial users. If this is something you never have explored, make a point of checking out

One ICS-CERT service is an index of vulnerability advisories listed by particular products deployed in the field. Most of these advisories relate to a specific piece of hardware or a software platform. The weaknesses might have been discovered by users or as part of laboratory analysis. The response team documents the problem, explains what it means, indicates if it has been used in a documented cyber attack, details what the vendor is doing about it, and provides suggestions for mitigation.

The list covers a variety of issues. Some examples include:

• runtime toolkit null pointer deference;
• data server denial of service;
• improper authorization;
• incorrect DNP3 driver input validation;
• use of hard-coded password; and
• insecure password storage.
The website names the specific supplier affected by each listed vulnerability.

Many varieties of root causes exist but one of the most common is some form of buffer overflow. In simple terms, a buffer overflow occurs when a hacker forces too much data into a given buffer space, which causes it to overflow into adjacent buffers and create interference. This can provide a means to access other parts of a system for potentially nefarious activity.

Cyber criminals typically use these vulnerabilities as tools in one of two ways.

A hacker who has learned how to exploit a vulnerability in a particular piece of equipment can try to use this skill wherever that equipment is deployed. Knowing how to break into a Brand-X Model 200 programmable logic controller (PLC) because it has a hard-coded password allows the person to search for situations where that device is found and attack these locations as targets of opportunity. The motivation may be mainly to capitalize on the weakness of the equipment rather than to target a specific location.

A hacker trying to break into a particular target will take the opposite approach. The person might scan the systems of the company to determine what equipment it uses. When those items are cataloged, it’s a matter of finding out which have the most useful vulnerabilities that can be exploited to achieve the desired result. Some companies have discovered to their dismay that a dedicated hacker has a better picture of their networks than they do.

A Sobering List

After spending a few minutes sifting through the list of advisories, you’ll find that virtually every major automation supplier shows up one way or another, and most more than once. No company is immune to some sort of problem, particularly with its larger platforms. Suppliers don’t like to appear on the list and do everything they can to correct these issues but the realities of cyber security guarantee problems always will exist.

Such problems occur for a number of reasons. Suppliers tend to reuse chunks of programming that work and some of these can go back to a time when security was less of a concern. Such legacy code can remain in a user’s system for many years and function perfectly, all the while hosting a vulnerability waiting to be discovered.

Some users looking at the list of vulnerabilities may find it somewhat overwhelming given the sheer number of items. However, for a given asset owner or industrial network administrator, the overall number isn’t as important as the specific items germane to particular installations.

The more relevant question is how many of these vulnerabilities exist in your plant, and how severe the individual ones are given your particular applications. Of course the information available from the ICS-CERT only is valuable if you know when it applies to you, which requires some sleuthing on your part.

1 of 2 < 1 | 2 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