Beyond data transactions, understanding the relationship between clients and servers plays a significant role in cybersecurity.
What makes a device fill the role of a server or client? And, more importantly, how can you use that information to strengthen your network security and mitigate insecurities?
The best place to start with this topic is to loosely define what makes software act as a server or as a client. But throughout this blog, keep in mind that the two are not mutually exclusive—some devices can be both a server and a client. When playing the role of a server the key trait is that the server device is always listening.
The idea of a server is very common, and the most common example is a web server. All websites are hosted on servers that are waiting for you to connect with them; when you do, they give you (the client) their data, which is the website itself. To facilitate this, the web server has an open port for those incoming connections, and the client reaches outbound to fetch the data. In most cases, that client is your web browser software. An important thing to note is that the client does not need an open port to receive data back over that established connection—so outbound can support bidirectional communication.For something like online purchases or accessing secure information like banking data, this communication must be secure—which is why many sites use https, not just http. These connections are using signed certificates to confirm the trustworthiness of the server, so when the client reaches out and authenticates, if the certs are not expired and "agree" between both client and server, then you know the data exchange is cybersecure.
Other servers work the same way. Some of the most common examples of servers with an open port in the automation industry are Modbus slaves, since they are in a ready listening state for any clients to come along and ask them for their register data. When this is how your devices primarily connect with each other, with one client going out to each of the servers it needs data from, you end up with a lot of point-to-point connections and—dangerously—most of those Modbus servers cannot have SSL certificates installed. So those connections are very insecure.
With just 3 clients and 4 servers, there are already 12 separate connections, without accounting for communication between servers or between clients!
Since each server is listening, each has to have some way for new clients to connect, and like a web server, that is in the form of open ports. When you have a lot of servers that means lots of open ports, which can be a large security vulnerability and a nightmare to manage. For example, the Modbus port is 502, which is widely known and can quickly become a problem when you introduce IT, cybersecurity, and firewalls. Since every listener (server) has to have this port and possibly other ports open and accessible, there have to be a lot of inbound connections. Inbound connections are difficult to make secure on an untrusted network.
Clients must reach out for the data they need, just like web browsers connect to the web servers that they want data from. Again, this does require an open port on the server but not on the clients, and since each client is closed off, they are by definition more cybersecure than the servers that are listening for new connections. But when many operational (OT) devices that are acting as both clients and servers, plus informational (IT) clients like HMIs and databases, are all on the same network, the mix quickly becomes complex and difficult to maintain since they share the same firewall.
The ideal way to prevent problems is to have all of the OT devices on a trusted network with its own firewall, and have only devices and software that you trust with your operational data on that network. Then all the IT devices go on a separate untrusted network with a different firewall, where you may not want every device to have access to all data.
Data still needs to go both ways between the two networks, but for cybersecurity, it’s critical to have very few, or ideally zero open ports on the OT side. One way to limit open ports is to have all of the OT data collected into one client, which can then create an authenticated and encrypted outbound connection to an IT server. Then that established bidirectional channel can handle the data acquisition and control without compromising security.
The groov EPIC is unique in the industrial automation space. Because of its dual isolated network ports, you can have one network interface controller (NIC) handling brownfield devices by acting as a client or Modbus master on the trusted network, then have the other NIC handle the secure connection to the “outside world” untrusted network.
Since these two NICs are completely segmented, there is no way for a device on the secure network to connect directly to the devices on the local unsecured network, keeping your data protected and your firewalls intact.
This relationship between a client and server and the roles that each plays is often misunderstood, but understanding them is critical to creating a secure platform, which is made possible with the correct implementation of groov devices and intelligent networking.
Keep an eye out for future blogs that go into the details of the software you can use to implement these best practices!
And as always, happy networking.