Industrial Control System Security
So what does this have to do with security on the plant floor? Well, for industrial communications the roles of the 'bank guard' and the 'teller' are broadly analogous to 'Network Security' and 'Application-Focused Security'.
For example, the firewall acts like the guard, so that specified protocols are either permitted or denied access into the control network. And just like a more experienced bank guard, a more sophisticated SCADA-aware firewall observes the traffic beyond the obvious protocol types and makes additional filtering decisions based on the behavior and context of the systems using these protocols on the network.
Similarly, an OPC server with a robust OPC security implementation can act like a well-trained bank teller. After a user successfully connects to an OPC server, the OPC Security configuration ensures they only get access to the specific sets of data they are supposed to see. Attempts to access others' data should be blocked and logged.
As with the guard and the bank teller example, the firewall providing the network security and the OPC server are an essential team. For example, a firewall can block millions of randomly malformed messages directed at a server as part of a Denial of Service (DoS) attack. At the same time, user authentication and authorization checks can prevent a more subtle attacker inside the firewall (such as a disgruntled employee) from accessing process set points in a system and making changes that might risk property or lives.
To understand network-focused security, it is important to know that most TCP/IP protocols, such as Modbus TCP, include an internationally recognized number (called a port number) in each message. This identifies the message as using a specific upper layer protocol, such as HTTP or Modbus TCP. This consistent protocol identification makes it easy for firewalls to block or allow specific messages based on function. For example, to block all Modbus TCP traffic, all a firewall needs to do is search for and then block any message that contains the number assigned to Modbus TCP (namely 502) in its TCP port field.
An out-of-the-box OPC server does not use a fixed TCP port number. Instead the server dynamically assigns a new TCP port number to each process that it uses to communicate with OPC Clients. The OPC clients must discover these associated port numbers by connecting to the OPC server and asking what TCP port number they should use for the session. The OPC clients then make a new TCP connection to the OPC server using the new port number.
An OPC server's ablity to designate any port between 1024 and 65535 for communications provides some ease of use advantages. Unfortunately it has also caused many IT professionals to consider OPC "firewall unfriendly" in the past. Configuring a traditional IT firewall to leave such a wide range of ports open is like having a sleeping bank security guard watch the front door. On the other hand, insisting on locking down the dynamic ports effectively ends up blocking all OPC communications.
This has changed significantly with the availability of OPC-aware firewall technology. New OPC-aware firewalls can now automatically track and manage OPC Classic's dynamic port problem. These firewalls are designed to be dropped into existing networks without any changes to existing OPC clients and servers. The OPC dynamic port issues are no longer a reason not to install firewalls in front of OPC servers.
Returning to the bank analogy, once visitors get past the front door and the guard they approach a teller to take care of their transactions. The teller's job is to both facilitate transactions and to ensure only those accounts the visitor has access to are affected. The OPC servers of virtually all OPC vendors simply rely on DCOM (or an OPC-aware firewall) to address security (the guard at the door) and do not provide specific access control security (the tellers).