Difficult Conversations: Open Ports, Business Data Needs, and Cybersecurity Risk

Difficult Conversations: Open Ports, Business Data Needs, and Cybersecurity Risk
Difficult Conversations: Open Ports, Business Data Needs, and Cybersecurity Risk

In the industrial control space, it’s common for an engineer to ask IT to open a port on a firewall, router or other network device to connect between certain systems and/or control devices. We’re not just talking to the public internet, but even between network segments such as control and business networks. It’s also common for the IT department to have serious concerns about security risks potentially introduced to all of the company’s networks by opening a port. This often leads to difficult conversations, which we find are becoming more difficult in light of recent events, and require balancing different priorities and perspectives.

We’ve spent 25 years in the operations technology (OT) space, but because we work in data integration with our end user, integrator and machine builder partners, we have to understand IT concepts and concerns. In this article we share with readers in the OT space the terminology, concepts and IT perspectives we’ve learned to help them have collaborative discussions with IT, to weigh risks together, evaluate options to address risks, and accomplish movement of data for operational & business needs.


Start with listening

Start by listening with the goal to understand  the nature of your business, its risk profile, and the concerns people running your business are going to have. If the business is regulated, has access to confidential information from its customers, sells products or provides services that affect health & safety, assume it’s a target, and that will drive the tone and posture of your cybersecurity team’s concerns.


Inside vs outside the facility: It’s still a risk

The topic of the “inside job” where an employee or contractor is physically in the building and has a computer that can directly join the network is the reason why IT will be concerned about any open port between business and production networks or other network segments.

Their job is to protect all, so even if the firewall to the internet is totally closed to inbound traffic, they think about the “what if."  Several well-known attacks on Industrial Control System (ICS) networks originated through a rogue device connected to a trusted network inside the facility.




Also, well-known email link, malware email attachments and other “phishing” schemes, create the risk of a user on the production or business side “inviting an attacker in." That’s why those attacks are so popular and, once on the network, that attacker may as well be physically present, depending on how your network is setup.


Ports & attack surfaces & what’s on guard?

Ports are doors to your systems and network. Any inbound port open to traffic from the public internet is a huge risk. But those same ports open between internal networks also pose risks.

When a port is closed on a device, security is in the hands of the device to not accept any requests to open a connection for TCP traffic and reject UDP connectionless traffic to closed ports. Attacker’s will receive no response when probing for vulnerabilities.

When you open any port without any restrictions you have opened a door completely and told the firewall to let all traffic flow, bypassing methods, algorithms, & technology in the purpose-built security device. An open port is an attack surface. Even one port is a place for someone to probe.

Then who is in charge of security after that? It’s the software applications that the traffic flows to that you are now depending on for that security. Those applications are nearly always built to perform a specific function and are not specialized and hardened for network security like a firewall. Attackers probe for open ports, exploit known software weaknesses, and look for weaknesses in the software such as a factory default password, an easily guessed password, an injection attack, or other vulnerability.

If you have no other options and must open a port, even on your internal network, your IT team will likely insist on limiting access to known IP addresses and employ a whole host of other measures to manage the risk, that may cause you to still consider other options we mention later.

But even encryption, authentication, VPNs, and other mitigating technologies sometimes mentioned as “the solution," have their own risks, which is why your IT team may be taking a hard line. Let’s look at those risks.


Advanced firewall filtering and intrusion prevention services protect us?

Today’s enterprise class firewalls are very capable of inspecting traffic, identifying suspicious or known attacks, and blocking them even on an open port. There are even specialized firewalls that can inspect industrial control protocol traffic and restrict it by protocol function code. You can also setup rules that say “only allow traffic from these IP addresses, or even in some cases these MAC addresses” which can make the attack surface smaller but never totally eliminate it.
 
However, attackers are smart too and always adapting. Also, remember a human configures and maintains those filters. One mistake and the attack surface is enlarged, or critical data flow is cut off. Some firewalls can run a proxy on an open port and the proxy inspects the traffic using rules, algorithms, and detection mechanisms that are constantly updated by the firewall device vendor, or your cybersecurity team, or both. When using those technologies realize you are trusting that device’s algorithms and any rules that were defined by humans managing the firewall. There is still an attack surface.


Encryption & authentication protects us, right?

Encryption keeps someone from reading your data if they can’t decode it. It does not prevent attacks. Encryption also means that any filtering in your firewall can’t read the data so they cannot determine if an exploit is included in the data, so the firewall packet inspection is actually subverted by encryption.



There are well-publicized break-ins that were performed by attacking the encryption mechanisms on devices, server operating systems, and software applications. If you’ve had to deal with IT shutting off the older TLS1.0 and TLS1.1 encryption support on your systems, that’s why as those encryption methods are well known attack surfaces.

Similarly, authentication is just another thing for an attacker to try and exploit. Even if they don’t get in, they can overload your software application with requests to the point the application is unable to perform its main purpose and is spending all it’s time fighting off requests, at best.


But we are running a VPN. Isn’t that safe?

VPN’s sound safe as secure way of allowing traffic to flow into or within the secure environment of the plant. But, actually, it’s the other way around especially with remote VPN users. Using a VPN simply expands the security perimeter of the plant or network segment to include the remote VPN client and anything it has been exposed to or is connected to. This is how the NSA EternalBlue exploit propagated the well-known WannaCry virus, and still remains a serious threat today. VPN’s are powerful but are limited by the security of the connected device(s).

Storms, and we don’t mean weather, but broadcast storms

Another concern IT may express about industrial control protocol or devices you add to the network is whether or not they generate broadcast traffic on the network. Broadcast traffic is sent from one device to all devices on the network.  It’s like someone walking into a quiet office of work desks and screaming – no one can hear, think or talk over the screaming, so broadcast traffic is detrimental to overall network performance at best. Broadcast traffic can take a network to its knees, feel like an inside attack, and could stop production.
 

Is IT asking a lot of questions around OPC UA?

Although there are many technologies being used in OT now, the OPC standards for interoperability of software and now hardware in control have 25 years of history and we often answer questions around OPC, networks, & and security.  As the most current of the OPC standards that includes encryption and other security capabilities, OPC UA technology adoption continues to grow in the industrial control space.  Even with that security asking your IT department to open a port to connect an OPC UA client to an OPC UA server will almost certainly result in scrutiny. 

While OPC UA does only require a single open port which, compared to DCOM technologies used in OPC Classic is less risky, it’s still an open port. The same would apply to any protocol that requires a port to be opened. There are realistic alternatives that work with OPC UA and other popular protocols like MQTT, requiring no open inbound ports which we’ll cover next.

On the subject of broadcast traffic, OPC UA uses a TCP port, which is socket-based, as opposed to UDP. UDP, which is connectionless is typically used for broadcast messages where a connection to the receiving host/hosts is not required first (for example, the SNMP protocol commonly uses UDP). Because OPC UA uses TCP for communications means it will not generate broadcast traffic.  If you’re interested to learn more about OPC, consider our OPC Getting Started FAQs Guide.
 

We need to move data, so what do you do?

Ultimately decisions around opening ports must be made by you and your IT team in the context of your business needs and cybersecurity stance. We are not in the business of rendering advice on whether to open ports or not, or how to do that within your security stance, but there are experts that can help, such as your company’s cybersecurity team and the US NIST who has published guidelines to consider.
Here are some alternatives to opening inbound ports that we said we would cover:

For in-plant connections across routers or firewalls, the Cogent DataHub and its secure tunneling protocol enable you to do many things to move data, including OPC Classic and OPC UA data, such as create read only one-way channels, or separate read and write channels into their own secure paths, and even allow data in without opening an inbound open port. You can learn more here.




For remote monitoring and outside of the plant applications, the Cogent DataHub and SkkyHub service can help you move or share data securely by “reversing the connection” so that there are no inbound ports open. Read more about options for your own remote access requirements

About The Author


Win studied software engineering and has been working at Software Toolbox since 2007. Win started out in product support and has worked with hundreds of users around the world with about every product in Software Toolbox's mix. Win’s unique mix of development experience combined with hands-on client experience enables him to deliver value to his clients.


Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..

Subscribe