This guest blog post was written by Lee Neitzel, senior engineer at Emerson Automation Solutions. post.

If you currently have an OPC server, you can quickly and easily overcome its security shortcomings and difficulties by wrapping it with OPC .NET, which combines Microsoft .NET security with access control features. It provides a simple method to secure access to legacy OPC servers.

OPC .NET, originally called OPC Xi, is a Microsoft .NET interface designed primarily to easily and securely wrap legacy OPC servers. OPC .NET works with all versions of OPC, and the wrapper adds access control features to enhance the built-in security of Microsoft .NET. OPC .NET can also be used to develop new OPC servers for the .NET environment that both support the capabilities of legacy OPC servers and can use industry-standard XML data definitions (information models).

Legacy OPC servers have been in use since 1996 to transport industrial automation data and events among applications from different automation vendors. Due to the acceptance and effectiveness of OPC, some vendors now use OPC for communications among their own software and hardware platforms, replacing proprietary protocols and communication methods.

The original OPC specifications, now referred to as OPC Classic, were based on Microsoft's component object model/distributed component object model (COM/DCOM) technology that had the infrastructure for making remote procedure calls from one application (the client) to another (the server). Microsoft has improved that technology, integrating remote procedure calls with web services, to create a COM/DCOM equivalent for .NET called Windows Communication Foundation (WCF). OPC .NET is based on WCF and uses WCF security features for user authentication, access control, and encryption. It also adds its own read, write, and subscribe access control features to supplement the built-in security of WCF. This article discusses these features in the context of the OPC .NET wrapper, which is a special-purpose thin server that front ends OPC Classic servers.

A major advantage of WCF is that it allows the OPC .NET wrapper to use multiple data transport protocols (e.g., TCP, HTTP) at the same time, each configurable with a variety of security mechanisms (e.g., Windows Authentication, transport and message encryption). This is a major step forward for OPC, because it does not lock the wrapper into a single protocol or a single security mechanism, but allows the user to configure the wrapper to use the protocols and mechanisms most appropriate for the installation. Further, changes require only a simple restart of the wrapper.

With OPC .NET wrappers, OPC Classic servers now have enhanced security, including more secure access through firewalls. Firewalls no longer have to be configured to open a range of ports as required by COM/DCOM.

The remainder of this article discusses the Microsoft security features used by OPC .NET and the additional layers of security OPC .NET uses to further lock down OPC .NET wrappers.

Microsoft security

By taking advantage of WCF security, OPC .NET provides a strong base level of security. This base level is further augmented by OPC .NET's security layers, described later in this article.

OPC .NET uses Windows Authentication, which is directly integrated into Windows Active Directory. No additional effort is required of the user other than the standard procedure of setting up Windows accounts for users and authorizing them to access the OPC .NET wrapper. Typically, this is done by adding users to a Windows group account that has access to the wrapper. User authentication is handled automatically without involving the OPC .NET client or wrapper. The user running the client application is verified to be a valid Windows user who is authorized to access the OPC .NET wrapper. Additionally, the wrapper is also authenticated to the user to protect against spoofing of the wrapper.

OPC .NET was designed to use this approach because of its simplicity. The use of certificates was considered. However, it requires separate steps for generating and installing a certificate for each user and for each server, and then configuring clients and servers to use them, a manual and potentially time-consuming process.

OPC .NET also uses WCF encryption, which includes both transport-level encryption and message-level encryption. Their use is configurable at the site, but OPC .NET wrappers are shipped with default settings, which are transport-level encryption for TCP and message-level encryption for HTTP.

The advantage of using Windows Authentication and WCF encryption is threefold. First, they are part of Microsoft's infrastructure, relieving OPC .NET client and wrapper developers from having to implement them. Second, Microsoft performs these tasks automatically and transparently, so the OPC .NET wrapper and its client applications do not have to be programmed to invoke authentication or encryption services. Third, as Microsoft improves these technologies, the OPC .NET wrapper and its client applications reap the benefits without having to be updated.

In addition to these built-in features, using WCF allows the OPC .NET wrapper to run under Microsoft Internet Information Services (IIS) or as a stand-alone "service." IIS is Microsoft's web server, and using it has the advantage of providing the OPC .NET wrapper with the same information technology protections as the other web sites hosted by it, such as having no additional ports opened in the firewall.

When hosted as a stand-alone service, WCF itself performs the function of IIS, receiving requests from the network and forwarding them to the OPC .NET wrapper. In this case, only two ports are needed, one each for TCP and HTTP, thus simplifying firewall rules when compared to OPC servers that use COM/DCOM.

OPC .NET defense-in-depth security

OPC .NET has its own security layer that leverages these Microsoft security features to create a defense-in-depth approach for the OPC .NET wrapper. It has the ability to control security by read, write, and subscribe operations, and is provided royalty-free for use with all OPC .NET servers, including the wrapper. Figure 2 illustrates the OPC .NET access model for this additional layer of access control.

The basic approach of OPC .NET follows that of OPC Data Access (DA), Historical Data Access (HDA), and Alarms and Events (A&E). The client applications must first create a configuration that identifies the data and events/alarms that they want to access before accessing them. In OPC .NET, this configuration for each client application is referred to as its context.

OPC .NET provides four access types that allow the client application to create and access its context: manage, read, write, and subscribe. "Manage" allows the client to browse for data and alarms and to create lists of run time and historical data and events/alarms that it wishes to access. Data lists are composed of explicitly assigned data items, while event lists are composed of events/alarms selected by a client-defined filter.

The read and write access types are used to access data lists and their elements. The subscribe access type is used for both data and event lists and allows clients to automatically receive data changes and events/alarms as they occur or periodically at a rate defined by the client application.

Each of these access types is represented by a WCF endpoint that is accessed through a separate WCF connection. Each endpoint can be configured to support one or more protocols with appropriate authentication and encryption settings as described above. By default, all protocols for the manage endpoint are configured for Windows authentication and encryption. This capability makes it possible to restrict access independently for read, write, and subscribe access types by protocol. For example, when TCP is used for local network communications inside the firewall, the wrapper can be configured to allow writes. When the firewall is configured to allow only access from the outside through HTTP, the wrapper can be configured to refuse writes from external users by disabling the HTTP write endpoint.

To provide more granular security, access to manage, read, write, and subscribe endpoints can be configured based on the user, the client application, the client workstation, and the client workstation IP address or subnet. This level of access control allows organizations to specify not only who, but also from what and where access can be made to the wrapper. More sophisticated OPC .NET servers may also include the allowable time period to determine when the client is permitted to connect to these endpoints. For example, a user in the control room adjacent to the wrapped OPC server might require full access, while a remote user thousands of miles away might best be restricted to read-only access, and then only at certain times.

Data lists are composed of data items specified by the client. When data items are added to a data list, the wrapper uses the Microsoft infrastructure to pass the user identity to the OPC DA and HDA servers to allow them to apply access controls to the data defined by the underlying control system. Other wrappers for OPC servers simply use administrator privileges, thus bypassing this important level of access control and granting full access.

All data values in these lists are transferred through the read, write, and subscribe endpoints and are identified by a dynamically assigned random number, called an alias, instead of by their names. Further, if the same data item appears in more than one list, it will have a separate alias for each.

The use of aliases is an additional security feature that prevents an interloper from easily identifying the data item or event whose value is being transmitted when encryption is not used. Aliases can also be periodically regenerated to protect against traffic analysis by an interloper. This defense-in-depth mechanism is of particular value when HTTP is used for accessing large amounts of data. HTTP data is typically transmitted as text, increasing message sizes dramatically and potentially reducing data transmission performance significantly. In these cases, it may be desirable to transmit data that is signed but not encrypted to improve performance. In these cases, the aliases are visible to interlopers.

OPC .NET lists have their own least-privilege security mechanism. Lists have to be separately enabled through the manage endpoint for read, write, or subscribe access. Therefore, clients cannot issue write requests to lists that are not write-enabled, even if the write endpoint is open. Of course, if the write endpoint is closed, all writes are disabled.

Automation system installations typically require different read/write access options for various types of clients, making these security layer features vital for virtually all industrial automation applications.

Conclusion

As detailed above, a primary objective of OPC .NET is to provide secure access to OPC servers through an OPC .NET wrapper. OPC .NET achieves its security through a combination of three features.

First, OPC .NET leverages the Microsoft .NET architecture and WCF to enable secure communications. As a result, OPC .NET is the beneficiary of the evolution of Microsoft security, allowing it to keep up with improvements in the industry without requiring code changes.

Second, in addition to security features of the Microsoft .NET architecture, WCF allows servers to be self-hosted as a service or hosted in IIS. This provides greater flexibility in how OPC .NET wrappers are deployed and also simplifies setting up firewall rules, requiring only a single port for HTTP access and another port for TCP access.

Third, OPC .NET enhances Microsoft security with its own defense-in-depth security layer that can be configured to meet the specific needs of an installation. These features are designed to implement least-privilege security concepts to further lock down security when accessing OPC servers. Combined, these three features provide secure access to OPC servers that are simple to install and maintain.

Information regarding the download of a production-level OPC wrapper and client helper code can be obtained from the OPC Foundation (www.opcfoundation.org). The OPC Foundation OPC .NET wrapper is free to its members, and installation takes only a few minutes. The client helper code is freely available to everyone, not just OPC members, and simplifies writing client applications.

About the Author
Lee Neitzel, senior engineer at Emerson Automation Solutions in Austin, Tex., has been involved in security and network standards for more than 30 years. He has worked on IEEE 802, FDDI, Fieldbus Foundation, and OPC standards. He is currently the IEC project leader for integrating the WIB "Process Control Domain - Security Requirements for Vendors" specification into the IEC 62443 and the ISA-99 security standard.

Connect with Lee:

This post originally was published at InTech magazine.