Call us! 512-349-0334 or (877) INDUSOFT

National Cybersecurity Awareness Month: Cybersecurity for Intelligent Systems

For this Cybersecurity Awareness Month, InduSoft would like to leave you with some practical thoughts and ideas on Cybersecurity that you could incorporate into your InduSoft Web Studio HMI and SCADA projects.  For those of you who want to think about these concepts or are already on-board with making your applications cybersecure; these topics and ideas may help you solidify your project design plans.

This first topic is called, “Stating the Obvious”.  Your projects should be including cybersecurity as a principle design goal.  InduSoft Web Studio HMI Software has built in application-level security functions that allow objects and screens to be viewed and operated based on security groups and users.  Simply said, you can build screens, controls and make data available only to specific users, and lock these things away from users who don’t need such access.  Management data are available only for management level personnel.  Maintenance data and controls are only available for maintenance level personnel.  Operator controls and data only are available to Operators.  Administrator and Engineering groups and users only have access to the things that they need to see and control. In addition, items and data can have two-level authentication (a logon and an e-signature to make changes or open/enable a control, screen, or object).  Finally, using LDAP, users and groups can be managed from a central location such as Active Directory. InduSoft has many webinars, training videos, white papers and Tech Notes on using various aspects of the built-in security functionality that you may find useful for your HMI software projects.

This next topic is a simple enough scheme to implement with great potential and substantial benefits to inhibit a Man-in-the-Middle Attack scenario on your control system.  Additionally, it can be applied to legacy devices of all types with little or no impact in operation or performance, and with great efficaciousness.  Let’s call it “HMI and Device Authentication”.

For those readers who have studied or thought about implementations of cybersecurity in any depth, you understand that Man-in the Middle Attacks affect control systems by allowing an operator to only see manufactured or manipulated data presented by an agent who has inserted himself between an HMI and the Industrial Control System (ICS), which is usually a PLC or a PLC farm.   As a matter of fact, had the designers of the control systems who were the victims of the STUXNET infiltration incorporated this simple technique, it would have thwarted any attempt at a Man-in-the Middle attack scenario, as it has been described and reported by the media.

Authentication and Authorization usually go hand-in hand in any security system.  Authorization is the ability to allow the correct person or system to access something within a secure area. Authentication is the method that this person or system identifies itself to be the entity it claims to be that is authorized to enter or connect. Authentication is usually defined within the security community as “Something You Have, Something You Know, and Something You Do.”  An example of this concept is User Access to a machine or building.  Something You Have is “secure access credentials”.  This may take the form of a simple user name or could be a key card or biometric information.  Something You Know is the passcode, or access number, and Something You Do is enter the passcode into the correct interface providing the secure access to the system or building, like an access keypad, or in the case of a computer, the “password” field on the logon screen.  These three metrics individually cannot allow access into the secure area, but all three create “Authentication” to prove to the system that you are who you say that you are.

A simpler example is an ordinary metal door key.  You are “Authorized” to enter the building through the door because you have been issued this key.  But just because you have the key in your possession does not grant you access to the building.  You must “Authenticate” yourself.  Something You Have is the key itself. Something You Know is where the key fits into.  Since there are millions of door locks, and your key only operates in one specific lock mechanism, you must know which lock the key will work in.  Something You Do is the physical action of putting the key into the correct lock and turning it correctly in order to open the door.

When intelligent systems are designed, traditionally, divergent parts of the system are given authorization to interact or have access to other parts of the system. In a network connected system, this authorization is very often an IP address using the assumption that because there are so many unique IP addresses that whoever is connecting was “by design” to be the correct entity.  An example of this is an HMI system that is connecting to a PLC or other control system using an Ethernet driver.   Man-in-the-Middle Attacks are successful because the agent, who is inserting himself in the “middle” or between the HMI and the PLC, has learned the IP addresses of each, and by poisoning a lookup table, has impersonated the HMI to the PLC, and impersonated the PLC to the HMI.  This is how the STUXNET worm operated, and the operators thought they were viewing the PLCs, when in fact they were actually viewing data manufactured by STUXNET.  Had the HMI and PLCs actually “Authenticated” this attack could never have succeeded as it did.

A very simple method for creating real-time authentication between components is the use of a “Contract” using a checksum. This simple method of authentication only requires two I/O Integer tags.  The first Integer tag carries the hash value, which is calculated simply by taking values of several Analog tags which could be added, subtracted or any other combination of functions applied to them (and these do not have to be the same ones each time) and then converted to an integer value by truncation or rounding.  This is the Hash Value.  The second I/O tag is the Control.  Initially set by the PLC, the value it carries is the algorithm code used, and if set by the HMI, it could be used as a challenge for authentication based on the last values received or a message that the Hash Value was not understood.

For example, on the PLC, there are 3 tags which could be summed such as, Int(Tag1 + Tag2 + Tag3) or combined in any other way such as Trunc((Tag1 – Tag2) * Tag3).  Each of these methods is assigned a number and this is sent over the second Integer tag to the HMI, so it knows which algorithm is being used to create the Hash Value.   The HMI recalculates the last values of Tags 1, 2, and 3 using the same algorithm used by the PLC and compares the newly calculated Hash Value against the one sent by the PLC.

The agent using the Man in the Middle attack method could not understand how or where (unless there was intimate knowledge of the PLC and HMI programming) these Hash Values originate, especially if the tags being used are rotating and the algorithms keep changing.  In other words, the HMI and the PLC know something that the Man-in-the-Middle does not.  Simply generating random data would not jibe with the authentication on the HMI end, and retransmitting the current Hash Value in the PLC by the Man in the Middle could not be authenticated by the HMI unless the correct values of Tag 1, 2, and 3 are known, and which algorithm was used to create the Hash.  Variants of this scheme could include using only one I/O Integer Tag, encrypting the Algorithm Number, error messages, challenge messages, etc. into the tag.  An alarm could be created in the HMI when the Hashes do not match or fall outside of a deadband, indicating an Authentication Failure with the PLC or assign it a level of “Quality of Authentication”, alerting appropriate personnel to a potential system breach without creating a panic situation.  This security scheme is quite simple to implement and provides a statistically more difficult security layer to penetrate in your Defense in Depth implementation.

Remember that applying only one single security layer or technique most likely will not statistically be enough defenses to prevent a breach into your control system when an attack occurs.  There is no “Silver Bullet” when it comes to security.  Your “Defense in Depth” security scheme must include many layers of disparate types of security, so that one single penetration tool is not enough to breach your system.


Comments are closed.