When developing secure SCADA/HMI applications that will help systems interface and share data in IoT application, it’s important to take a look not only at what we can do to better protect applications, but at the misconceptions that might be holding back our best efforts at cybersecurity. We thought it might be important to share some of the misconceptions we’ve found in the industrial automation field.
Myth: Security is the IT department’s job
It’s everyone’s job to be concerned about cybersecurity, and everyone has responsibility for ensuring that applications are as secure as possible. System integrators and OEMs are responsible for implementing security procedures and protocols into their interfaces, like username and password authentication for operators and users, records of operator initiated actions, and applications that share information through secure connections. Operators and managers are responsible for ensuring that safety provisions built inside the applications are enforced, and that security procedures like logging in and out of the system are followed according to company policy. IT may allow or disallow USB sticks and test contents or regulate downloads, but it’s up to everyone in the facility to follow these restrictions and prevent malicious software from infecting the network.
Myth: Attacks come from the outside
Sure, some do. But not all security breaches occur because of outside malicious attacks. Some breaches occur through careless or unintentional internal behavior, or possibly even malicious internal behavior. There have been plenty of instances where a disgruntled employee has leaked data intentionally, or caused damage to a system from the inside. The best way to protect a system from internal attacks is to ensure that applications are able to record any activity initiated by operators within the event logs, to have secure user authentication, and that specific user content or control is delivered only to that person or device. Again, it’s very important to see that security protocols are in place. If users are sharing passwords or everyone is logging in to a single guest account, InduSoft Web Studio’s built-in SCADA security is being bypassed and is ineffectual since it has not been implemented or activated.
Myth: Our data isn’t useful to anyone else. No one would want to steal or manipulate it.
You can never know how application data will be used or manipulated. There are any number of reasons why an application might face an attack. Data might be stolen or recorded, or even manipulated to cause harm to industrial machines, as in the case of Stuxnet and Aurora. Some electrical grids can be the target of malicious manipulation, as can any “smart” technology being utilized. Even if data is not stolen, open (to outside connectivity) or unprotected and unsecure networks can still be utilized as a ‘zombie’ by installing malware on unrelated computers inside the network for use in coordinated DOS (Denial of Service) or other types of attacks.
Myth: Antivirus software will notify us if we have any malware
Unfortunately, that’s just not true. Antivirus is really only effective against known malware, signatures, and attack patterns (such as Trojans), and even existing malware undergoes enough iterations to sometimes fool antivirus software. Using antivirus protection is a good security practice, but it is by no means the only preventative measure that should be used to defend a system from malicious software. Security should be applied in layers to any Industrial Control or SCADA System.
Myth: No application is completely safe, so why even bother?
For the same reason you lock your doors when you leave the house. Just because a locked door won’t stop an aggressive break-in by itself, it will deter some attempts to enter the house. The key to good cybersecurity is in layering. None of the layers are completely effective on their own, but combined, they can help create a very secure system. Some layers of security may include:
- Username housekeeping and password strength/expiration enforcement
- Ensuring that process data is not stored on the same networks or servers as other critical enterprise data
- Protecting networks with firewalls using stateful packet inspection, Intrusion Prevention Systems designed for automation protocols, user and device authentication, fencing of data, encryption, and other security measures.
- Building applications that recognize different users and user groups and manages access to process functions and data based on authentication and authorization. Fence data and access to authorized users and areas.
- Develop a culture within the facility ensuring that security measures are taken seriously and that established security protocols and policies are being followed
- Protection of physical ports on process machines, such as USB ports that meet the security requirements of the system and network.
- Restriction of connected computers, terminals, and devices, to the applications that were designed to run on them so that machines, processes, or data are not also being used for unauthorized social media and/or downloading other software or connectivity to unauthorized media or networks.