Cybersecurity Icon

Wes Maffett Headshot
Wes Maffett

Attention to cybersecurity has reached even the most remote parts of the globe. From the missing Malaysian Airlines 370, the NSA, Edward Snowden to the infamous Stuxnet, Flame and Gauss viruses, citizens of the world have something in common—our “processes” might be under attack.

The pieces and parts that hackers and protectors focus on most often include: wires, cables, switches, routers, gateways, servers, and PCs. Overwhelmingly, the goal of these attacks is most often tied to monetary pain points. Because there are so many holes in the cyber world, a strategy called “Defense in Depth” is a practical approach. “Defense in Depth” is the coordinated use of multiple security countermeasures to protect the integrity of the information assets in an enterprise. The strategy is based on the military principle that it is more difficult for an enemy to defeat a complex and multi-layered defense system than to penetrate a single barrier.1

Even so, movies and TV shows perpetuate the concept of cyber-terrorism. Fundamentally, these stories focus on the precept that automation systems—from the Department of Defense to Nuclear Power Plants—are easy targets for those who wish to inflict psychological harm or global destruction. The most famous process automation attack, Stuxnet, originated from the U.S. government2 and targeted Iran’s centrifuges. I must say it’s a conundrum to know that the U.S. government both perpetrates pain and is the victim of cyber-attacks.

READ ALSO: VIEWPOINT: Cybersecurity Matters, But How Much?

For the water industry, there is a government entity called Water ISAC, which is run by the water sector. “The Member base includes water utilities and state and federal agencies dealing with security, law enforcement, intelligence, the environment, and public health.” Water-ISAC publishes known software holes and fixes physical security issues unique to the water industry.

For a bit of perspective, let’s visualize the scenario for Factory & Process Automation systems. Who might attack? U.S. & Foreign governments, cyber-terrorists, hackers, ex-employees, current employees, and anybody with computer access and some twisted motivation.

If this is an accurate portrayal of who’s attacking, what possible chance does the average water, power or gas provider have to combat such a stacked deck? Again, Defense in Depth strategies are the norm and provide varying levels of comfort. I didn’t use secure, because that word is thrown around with such abandon that it has lost meaning. However, I have a practice to add to your own Defense in Depth strategy, which you might find cheap, deployable, and absolute.

Embedded devices (PLCs, PACs, DCSs), variable-speed drives, and lots of things we use in Factory and Process Automation have their own logic engine. This is primarily because the originators of such automation wanted to create devices that would run for years without stopping. The logic engine runs compiled code against a set of instructions and data points. The instructions are the program; the data points are either constants (part of the code) or variables from a data-set or database. We can thank Dick Morley3 for believing early on that engineers (not to pick on anyone) would challenge the reliability of a device they couldn’t “see” working.

What can we see? A checksum or a hash, which is a method used to detect errors. Normally, checksum is associated with communications to ensure the message sent is the one received. If one byte is changed in a communications string, the checksum will be different. The same concept is utilized in automation and device processors. When a program is downloaded or changed in a PLC, a new checksum is generated. For our more hack-savvy readers, you might want to determine which cryptographic hash methodology your device uses:  i.e., MD series (md2, md4, MD5), SHA series (sha, SHA-1, sha-224, sha-256, sha-384, sha512), RIPEMD series (RIPEMD-128, RIPEMD-160, RIPEMD-320), HAVAL, or Tiger. If it’s not using a cryptographic hash, you’ll need to dive deep into how that manufacturer generates a hash to determine if the methodology meets your company’s internal expectations of security.

For the rest of us, you’ll need to find out where this register value is stored. Without going into a diatribe on the inner workings of PLC execution and hidden data, this register changes whenever the program is modified. Implementing a compare strategy for every device will validate that the device has not changed since last programmed. There are a number of well-known end-users who use checksum-based validation to ensure no changes were made since the system was certified as approved for use.

The strategy of comparison does nothing to prevent changes, but rather provides a secure point from which actions can be taken. Also, in the case where a device program is fixed and only datasets changed, the same checksum strategy holds true and is easily captured and stored for future compare functions or actions.
Checksum compare—a last step in a good Defense in Depth strategy—provides the owner/operator the power to circumvent unintended actions and, with proper planning, can enable change within a single executable cycle.

Wes Maffett is a 20-year veteran of factory & process automation systems implementation and design. He has programming and teaching experience on multiple industrial platforms, including PLC, PAC, DCS, embedded systems, HMI, iPC, SCADA and Web-based visualization. Mr. Maffett’s portfolio of experience includes control system analysis, design and testing of Web-based interface software. He hosts the LinkedIn CWWA (Caribbean Water Wastewater Association) group and won Siemens Water/Wastewater Center of Competence 1st Place Global Sales Award. Wes earned a bachelor’s degree in Science in Information Technology (Web-Services) and a master’s degree in Science in Computer Information Systems. Mr. Maffett can be reached at 863 430-2829 or


  1. Defense In Depth,” Search Security, TechTarget.
  2. Obama ‘gave full backing to Stuxnet Attack on Iran,” Paul Marks, NewScientist.
  3. Dick Morley—’Father of the Programmable Logic Controller’,” Industrial Ethernet University.