Evolving towards secure Modbus

The Modbus/TCP protocol is used in industry to transmit register reading or writing commands between devices within multiple sectors, including manufacturing, chemical industry, food, etc. It is based on a master/slave relationship and is very widespread in the industrial world because of the simplicity of its plots and the great support it has with regard to all the devices that have capabilities to use it in their communications.

As discussed in the article Deconstructing Modbus, this protocol has plenty shortcomings, resulting from an initial design that did not take security into account. For this reason, its successor, the secure Modbus/TCP, protocol appeared, the objective of which is to be more reliable and robust, so that its communications are encrypted and it is not so easy to interpret data.

New security features of the secure Modbus/TCP

The new security features that this protocol incorporates compared to its predecessor are:

• Change from master/slave to client/server. According to the new specification, Modbus devices will now no longer be the master and the slave, rather it will change to a more computer language and therefore they are called client and server. The client would correspond to the traditional master and the server would be the final device, previously called slave.
• Change to the 802/TCP port. Although this aspect is not related to the security of the protocol, it is important to bear this detail in mind when it comes to analysing communications. In this line, it should be noted that there are no changes in the heading mbap (Modbus Application Protocol).
• Certificate based identity (x.509v3). The use of these certificates will prevent attacks that can currently be executed with Modbus/TCP such as man in the middle, influx of plots, etc. The certificate makes it possible to guarantee the origin of the plots, ensuring that the two devices that maintain communication are the ones they claim to be.
• Establishing communication (authentication phase) between client and server through a secure channel with TLS. Once the TLS session is established between client and server, both requests and Modbus/TCP responses will be exchanged within a secure channel.
• Mutual authentication between client and server. As an alternative to using credentials, the server can authenticate clients by means of a certificate. The server may require the client to provide a certificate that the server validates according to the certification authorities it trusts.
• Authorization by means of encoded roles as an extension in the certificates themselves. Thanks to the use of object identifiers (OID) included in electronic certificates, it is possible to include the role assigned to the device that is going to exchange information. For example, the following identifier corresponds to the role assignation as Operator in which the role is defined by a PEN (Private Enterprise Number), in this case 50316, within a private MIB provided by the Modbus organization:
  • RoleOID:1.3.6.1.4.1.50316.802.1

The secure Modbus/TCP protocol is an evolution of the existing Modbus/TCP that adds a security heading in order to encapsulate the plots based on the use of TLS (transport layer security). The mbap PDU (Protocol Data Unit), that has not changed in the mbaps profile, is encapsulated in a TLS application protocol message.

Modbus/TCP vs. Secure Modbus/TCP

The secure modbus documentation shows that improvements have been implemented in the Modbus/TCP protocol, but the differences between both have not really been mentioned. Below a comparison of different parts of the old protocol (not secure) and new protocol (secure) will be discussed in order to clarify which were the changes that make this secure Modbus/TCP protocol a perfect candidate to be used in industrial communications.

- Basic differences between Modbus/TCP and Secure Modbus/TCP -

The Modbus protocol that has been used to date, and that will continue to be used less and less, has two ways of being transmitted: by series or Ethernet, both of which are insecure and have vulnerabilities that are easily exploited by attackers. With the new secure Modbus implementation, the plots in communications will only be able to be transmitted through Ethernet and making use of TLS.

The current Modbus protocol does not have authentication, since only an IP address and function code are needed to establish the sessions. Furthermore, an attacker is able to capture the network traffic and analyse all of the requests exchanged between masters and slaves in an industrial network that uses Modbus/TCP and could easily interpret the plots because the Modbus specification is publicly available. As the sessions are not authenticated, both the slave and master could be impersonated. This is no longer possible in secure Modbus/TCP as it ensures the authentication and information encryption.

This type of weakness requires external countermeasures to be applied in the use of the current Modbus, given that it is the only way to improve its security. By using firewalls it is possible to control both reading and writing requests and even the records to which certain actions are allowed to be carried out. On the other hand, and thanks to the use of IDS and IPS, requests coming from attackers are alerted or blocked.

Given that the new implementation of secure Modbus/TCP includes encryption, the cybersecurity paradigm is changing when it comes to analysing plots and detecting abnormalities. Therefore, the use of firewalls, intrusion detection systems, etc. can only be implemented in an industrial network if such tools are able to interpret encrypted traffic. This poses a problem concerning the establishment of secure end-to-end TLS channels, given that these devices should break the encryption in order to be able to undertake the analysis, just like it is currently done with HTTPS communications, where an encrypted channel is established from one end to the firewall and then to the other end.

Application and incompatibilities

The use of secure Modbus, as a new protocol, requires a few years to get settled in the industry. The first devices that support it are currently being created, therefore the market penetration rate is small.
Secure Modbus could be used for the same functions and in the same environments in which the TCP version of the original Modbus is used, always bearing in mind what was previously discussed about device support.

Conclusion

The new capabilities in matters of cybersecurity incorporated in the secure Modbus protocol make it a great choice in order to be able to use and replace other communications that have been implemented in the industry longer and were not initially designed with a security layer. Nevertheless, it is a major challenge for the industry to develop devices that allow for this protocol to be supported. For this reason, its deployment could be slowed down, giving rise to another challenge for other monitoring tools that can currently dissect unencrypted industrial protocols.