Programming and configuration of control systems from the security point of view

In the following text, we will briefly summarize the rules that should be followed in order to increase the level of security against attacks. Operational practice shows that although programming tools and applications sometimes provide a relatively high level of security, their capabilities are not exploited - mostly out of convenience or ignorance of how to set them up correctly. Let's try to think about the following tips and, where it makes sense, actively promote them. The control system is divided into four levels - from visualization and data storage to the periphery, towards "down" it is more and more about physical protection, in the "upper" layers we encounter more IT measures. Of course, the last word has the customer in whose building the control system is installed. The rules are described briefly, let's take them as a kind of checklist. Not all measures can be implemented, we would certainly come up with others in the context of implementation.

SCADA, the database

Physical protection

  • install the server in a suitable environment (server room, rack - not somewhere in the workshop under the table);
  • if possible block computer peripherals (CD drive, card readers, USB ports ...);
  • use a UPS with sufficient capacity to bridge short-term power outages.

Software protection

  • OS (operating system): use the administrator account only for configuration, not for normal operation;
  • OS: uninstall unnecessary programs, especially games, unlicensed programs, etc.;
  • OS: regularly updated if possible (must be Internet access);
  • use https: // on IIS, which means, among other things, creating and deploying an SSL certificate.
  • if access is to be from the Internet, the PC should ideally be placed in a demilitarized zone (in cooperation with the customer's IT);
  • regularly review user accounts of both OS and SCADA program and others (check whether users who are no longer employed are defined, etc.);
  • force password change over time (if in accordance with the customer's IT policy);
  • enforce reasonable password complexity in Scada;
  • regular (automatic) backup of the project and check the recoverability of backups;
  • remote access essentially via VPN, do not leave only an open port for remote desktop (RDP) or similar services (VNC);
  • regularly review remote access options (open ports, VPN accounts);
  • allow access only from certain public IP addresses (for remote service);
  • controlled management of login data to the VPN and to the system on technicians' computers (at least protect the computer with a password, encrypt the disk, etc.).

PLC, terminals

Physical protection

  • place the PLC in a lockable cabinet, if it is not in a lockable room; a loop is not enough if the cabinet is in public areas such as hallways;
  • have only the necessary control elements accessible on the switchboard, ie if there is a control terminal in the switchboard door, the section with adjustable parameters is password protected;
  • if possible, do not use wifi in the technological network;
  • if necessary, use a manageable switch with control of MAC addresses on ports and reporting the connection of foreign devices to the network;
  • do not connect other "auxiliary" devices of the GPRS router type to the network with controlled access to the Internet.

Software protection

  • change the default passwords for SSCP access;
  • change default passwords for HMI;
  • change default passwords for web users;
  • regularly (automatically) back up projects, check the availability of backups;
  • do not manually modify the internal PLC firewall (on Linux platforms);
  • disable web access and FTP for terminals after setup, if applicable.

I/O modules, converters, IRC

  • I/O modules are preferably placed in switchboards, on a separate bus (not together with IRC controllers, whose bus runs around the building);
  • configure IRC so that unnecessary functions are not available;
  • for converters, turn off web access and FTP after setting, if applicable.


  • use the "quiescent current" principle to prevent a fault if the peripheral is damaged;
  • use external settings (eg for thermostats) only where necessary; definitely not for safety elements (DHW tank overheating);
  • in public areas, consider anti-vandal sensors;
  • in the PLC software, treat the safe state of the technology in the event of damage to critical sensors (if the sensor input shows a meaningless value, force a safe value into the program or go to a safe state and report the sensor fault with an alarm).