Webinar Recording: How to Build Reliable Industrial Control Systems

Webinar Recording: How to Build Reliable Industrial Control Systems

This guest blog post was written by Alex Tarter, Ph.D., technical director of cybersecurity at Ultra Electronics, 3eTI. Dr. Tarter was the lead presenter at an ISA co-hosted webinar on advances in industrial control system design against malicious attacks & unintentional cyber incidents. This post has been updated with the webinar recording.

I am always pleased to share operationally sound methods for deeply layering security, and I frequently demonstrate live hacks that illustrate how exploits can be countered undetectably to hackers once they’ve breached the firewall — as they inevitably will.

Recently I had the opportunity to team with an expert security researcher to investigate new capabilities that add security to widely used, and inherently vulnerable, protocols such as DNP3 in industrial control systems. Investigators have discovered numerous weaknesses associated with the protocol that is in wide use in the SCADA systems driving most industrial control system (ICS) networks. Some of these flaws can severely compromise equipment, and even halt operations. Organizations like the DNP User’s Group and ICS-CERT have been sounding the alarm about the protocol’s security problems, and how tricky they can be when implementing a DNP3 solution that is both secure and robust.

Industrial networks promote the free flow of messages that may also carry malware directly to a particular sensor. Knowing this, we developed a new method for picking up where DNP3 Secure Authentication ends in order to protect all payloads, as well as those from a compromised device. While most security systems do little more than signature-based matching, a validated, protocol-aware, packet inspection solution will parse the DNP3 protocol, including DNP3 Secure Authentication messages, to detect any malformed, unauthorized, or malicious messages.


In this way, you can up the ante on your proactive initiatives to mitigate the ICS’s most deeply embedded vulnerabilities — and do so without decreasing network productivity. The applications for DNP3 solutions stretch far and wide throughout the industrial control world. I am confident that this method will prevent many serious ICS issues. It also helps build stronger infrastructures that model the security standards that are effectively used by the U.S. Department of Defense.

Design a system that leaves no security stone unturned

When considering a security design for your plant or facility operations, make sure to factor in these aspects of the cybersecurity landscape:

  • Traditional information assurance (IA) practices are left over from World War II days when the biggest threat was the enemy breaking encryption (the Enigma machine, for example). IA practice was all about secure implementations of encryption and key management – protecting your information from an external attacker.
  • Cyber attacks are a fundamentally different problem because they occur from within a system. An attacker gets into your system and then looks to pillage as many other areas and devices as possible.
  • Today, the danger lies with the interconnected devices inside the system that individually manage essential, discrete operations. These devices must be protected against both external AND internal attackers.

However, not everyone agrees on how to fix these problems. Enterprise ICS operators understand network vulnerabilities, but often balk at the perceived costs of the solutions. The COOs often focus on the potential for operational interruptions with more deeply embedded security, and the CSOs may question the risk-effectiveness of one approach over another, and may not agree with C-suite colleagues on optimal solutions.

Industry needs to continue to demonstrate how optimal and government-grade cybersecurity can be achieved to the satisfaction of control industry CSOs and COOs. Layering in security can mitigate protocol weaknesses affordably without impacting operational performance. I see exciting advancements ahead for stronger and safer critical systems, and look forward to sharing new strategies widely.

About the Author
Alex Tarter,Alex Tarter Ph.D., technical director of cybersecurity at Ultra Electronics, 3eTI, is an expert and thought leader on new technologies and solutions for industrial and commercial applications for the protection of critical infrastructure. In addition to the work he does developing security solutions, Alex performs vulnerability and cybersecurity work for military and industrial applications, having prepared more than 50 reports on various aspects of security, cryptography, and situational awareness for industry, U.K. Ministry of Defense and U.S. Department of Defense. He earned a doctorate from Lancaster University, and a master’s of engineering from Imperial College London, and is a certified specialist in ISA 99/IEC 62443 cybersecurity fundamentals. He serves as a civilian advisory expert to NATO on Cyber Defense for the Industrial Resources and Communications Services Group.

Connect with Alex:


Top 10 Differences Between ICS and IT Cybersecurity

Top 10 Differences Between ICS and IT Cybersecurity

This post was written by by Lee Neitzel, senior engineer at Emerson Process Management and Bob Huba, system security architect at Emerson. 

In many, if not most plants with industrial control systems (ICS), ICS engineers and their internal information technology (IT) counterparts have very different perspectives on cybersecurity. Not surprisingly, these different perspectives often lead to conflicts when connecting an ICS to the plant’s IT system.

In the past, because industrial control systems used proprietary hardware and software, this interconnection focused primarily on just being able to communicate. The introduction of Ethernet and Microsoft Windows into industrial control systems in the mid-1990s, followed by the development of OPC interfaces, greatly simplified this problem, but at the cost of exposing the ICS to security threats previously known only to IT systems.


Further, with the rapid increase of attacks on industrial systems in the past few years, chief information officers are often held responsible for cybersecurity for the entire plant, including their industrial control systems. Unfortunately, not all IT security solutions are suitable for industrial control systems because of fundamental differences between ICS and IT systems. In addition, plants often have multiple production processes and industrial control systems, and some are naturally more critical than others. As a result, it is not uncommon for security to be handled differently among the various industrial control systems in a plant.

This article discusses how industrial control systems differ from IT systems as they relate to cybersecurity. It is important that IT and ICS professionals jointly understand the following top ten differences and develop workable security solutions that benefit the whole organization.

Difference #1: Security objectives
One of the biggest differences between ICS and plant IT security is the main security objective of each. Plant IT systems are business systems whose primary cybersecurity objective is to protect data (confidentiality). In contrast, the main cybersecurity objective of an ICS is to maintain the integrity of its production process and the availability of its components. Protection of information is still important, but loss of production translates into an immediate loss of income. Examples of threats to production integrity include those that degrade production, cause loss of view/control, damage production equipment, or result in possible safety issues.

One of the consequences of industrial control systems focusing on the production process is that ICS security is implemented using a comprehensive set of defense-in-depth layers to isolate the ICS and the physical process from the plant IT system. This isolation is the topic of difference #2.

Difference #2: Network segmentation
The first difference encountered when connecting ICS and IT systems is how they are segmented and protected. IT systems are usually composed of interconnected subnets (short for “subnetworks”) with some level of Internet connectivity. As a result, access controls and protection from the Internet is a primary focus of IT network security. It is not uncommon to see sophisticated firewalls, proxy servers, intrusion detection/prevention devices, and other protective mechanisms at the boundary with the Internet.

Inside this boundary, the remainder of the IT network is segmented into subnets that are generally aligned with organizational and geographical boundaries. Because access between these subnets is usually required, security between them is typically limited. However, all traffic from them must pass through the Internet security boundary to access the Internet. ICS networks, on the other hand, can be viewed as industrial intranets with two overriding security requirements. First, no access to the Internet or to email should be allowed from ICS networks. Second, ICS networks should be rigorously defended from other plant networks, especially those with Internet access.

To meet these requirements, industrial control systems usually employ network security devices (e.g., firewalls) for isolation from the plant IT system. Only workstations and servers within the ICS that act as gateways should allow ICS access through these ICS perimeter security devices. This prevents other devices on the ICS control network from being directly accessible from the plant network. These gateways should have an additional network card that allows them to connect the ICS control network. In general, only devices authorized to access the ICS from the plant network should be aware of these ICS network security devices and therefore be able to send messages through them to ICS gateways.

Industrial control systems should be further insulated from the plant IT system by a demilitarized zone (DMZ) that sits between the plant network and the ICS. The DMZ is an intranet that should be hidden from the plant network by an undiscoverable network security device. All external access to the ICS should first pass through this device and then be terminated in DMZ servers. DMZ servers provide clients on the plant network with ICS data and events that these servers independently obtain through separate and isolated communications with the ICS. The network security device that connects the DMZ to the ICS should be configured to allow only these isolated communications to ensure that all ICS access goes through the DMZ servers.

As a further precaution, the DMZ should use private subnet addresses that are independent of subnet addresses used in the plant network to prevent plant network messages from being erroneously routed to the DMZ. Similarly, the ICS should use private subnet addresses that are independent of DMZ addresses.

ICS networks often have remote input/output (I/O) systems, whereas IT networks do not. In these systems, I/O devices are installed in remote geographical locations and are often connected to the ICS via modems over public networks, virtual public networks (VPNs), and satellite links. Care must be taken, because these connections can give rise to security issues.

Difference #3: Network topology
Closely related to network segmentation differences are network topology differences. Many IT systems are large when compared to a typical ICS and contain data centers, intranets, and Wi-Fi networks. Industrial control systems, on the other hand, are often small and have only a configuration database and data/event historians.

It is not uncommon for an IT system to have hundreds if not thousands of nodes whose numbers change daily as employees come and go, as applications evolve, and as mobile devices are connected and disconnected. In contrast, most industrial control systems are an order of magnitude smaller, and generally have statically defined configurations.
IT network configurations, including VPNs, and network security devices have to keep up with these changes. As a result, IT systems extensively use many automated tools, such as dynamic host configuration protocol (DHCP), to manage their network topologies. These and other tools are cost effective only in large-scale systems and are considered expensive and complex by ICS standards.

Industrial control systems typically remain relatively static for years. A rigorous change management process is normally mandatory to ensure all changes are approved and tested. In addition, the use of DHCP and Wi-Fi segments are discouraged in the ICS for security reasons. In addition, ICS networks that connect ICS workstations with controller-level devices are normally redundant to prevent a network failure from affecting the operation of the control system. This network redundancy is typically proprietary to the ICS vendor with custom addressing models and switchover logic. As a result, the tools and techniques IT uses to maintain its dynamic network topologies are often not suitable or applicable to statically defined ICS networks.

Difference #4: Functional partitioning

ICS and IT systems are functionally partitioned in different ways. The most common approach taken by IT systems is to divide the system into various administrative partitions to better restrict user access to information assets. The IT department typically implements the partitions using Windows Domains and operating system objects, such as files.

Domains and organizational units typically represent business units/geographical entities within an organization, to which users and computers are assigned. Groups are used to control access to these computers and their objects (files, folders, executables, etc.) through the definition of access control lists (ACLs).

Each object contains an ACL that identifies who has been granted/denied access to the object. To simplify the process of pairing users with objects, groups are defined and assigned to objects, and then users are assigned to groups. As a result, only users/roles who are trusted to access an object are granted permission to do so. The careful definition of groups/roles can thereby be used to partition an IT system into trust levels.

ICS partitioning is much different. The ICS is partitioned into three levels (0, 1, and 2), as defined by the ISA95/Purdue reference model. Level 0 represents the physical process; Level 1 is control and monitoring; and Level 2 is supervisory control. Because of the nature of the devices used in these ICS levels, it is necessary to map trust levels to the device. In this case, trust means how much a device is trusted to behave as expected.

At Level 1, field devices perform I/O operations on the physical process (Level 0). Because they operate on the physical process, field devices have the highest level of trust. Trust generally is ascertained through design reviews, functional testing, and experience. Devices whose behavior is questionable should not be trusted and should not be used in Level 1.

Field devices use proprietary designs and firmware. Many can communicate digitally using standard, industrial protocols such as HART, Foundation Fieldbus, Profibus, DeviceNet, and Modbus. With the exception of wireless, field device protocols rarely include security features. Therefore, access to field devices must be protected by external means. Unfortunately, network security devices, such as firewalls, that are commonly used in IT systems are not applicable. These industrial protocols are not based on Ethernet or TCP/IP. Instead, physical and procedural security often restricts access to field devices and their communication links.

In addition, device firmware needs protection, including protection of upgrade files and the processes used to install them (e.g., flash upgrades and over-the-wire upgrades). Currently, the firmware upgrade process often has limited security features.

At Level 2 are distributed control system controllers, programmable logic controllers, remote terminal units (RTUs), remote I/O devices, and other similar devices. Because they read and write field device parameters, controller-level devices require the second highest level of trust, generally attained through testing and experience.

Controller-level devices, other than some RTUs and other remote devices, usually have limited security-related features and rely on the Level 2 control network for protection. ICS vendors often use industrial grade, proprietary firewalls and Ethernet switches in the control network to separate it into two layers, the workstation layer and the control layer.

These network devices have three primary security objectives: to lock down the network to prevent unauthorized devices from connecting to it, to protect controller-level devices from unauthorized contact, and to prevent them from being saturated with network traffic by rate-controlling the network traffic flowing to them.

IT typically does not have the policies, procedures, tools, and expertise in place to manage the ICS vendor-specific Level 2 network and controller-level devices and the Level 1 I/O devices.

Also at Level 2, and sitting above controller-level devices, are the workstations/servers—configuration/engineering, maintenance, operator, historian stations—all having direct connectivity to the controllers, and all using components and operating systems familiar to IT, such as PCs, Windows, and Ethernet. Level 2 workstations and servers have the third highest level of trustworthiness in the ICS. They provide the buffer between the outside world (Level 3 and beyond) and the process, so outside direct access to controller-level devices should not be allowed. Access to controller-level devices should be limited to Level 2 workstations and servers approved by the ICS vendor.

The trust levels of Level 2 workstations and servers are lower than controller-level and field devices for three reasons:

  1. They run commercial operating systems and software (e.g., SQL database software) with vulnerabilities that are continuously being discovered and exploited.
  2. They have a better chance of being infected or compromised, because they can be accessed by Level 3.
  3. They have users who may not always follow policies and procedures—some may plug in nonverified USB sticks, plug in their smartphones to charge, or bring in their own software that has not been tested to operate correctly with the ICS.

The trust levels associated with field devices, controller-level devices, and workstations are inherent to most control systems. Understanding them and maintaining separation/isolation between them is a responsibility that is normally not present in IT systems.

Difference #5: Physical components

Closely related to functional partitioning and trust levels are the physical components used to implement ICS and IT systems. IT systems are primarily composed of off-the-shelf networks, workstations, and servers that IT can access and administer. As a result, IT departments are able to define security policies for these components and enforce them with off-the-shelf security-related applications and devices, such as firewalls, antivirus systems, and patch management systems.

In contrast, ICSs are not IT systems doing control, as it may sometimes appear, but instead are tightly integrated proprietary systems. With the exception of workstations and servers, ICSs are composed of components that are generally custom built and foreign to IT. This often includes network devices built for industrial use, including Ethernet switches and firewalls. And, although ICS workstations and servers are typically based on Windows, they are usually hardened by the ICS vendor to the point that their software, other than the operating system, is custom built, and their security policies are set to industry standards that may conflict with the policies used within the IT system.

Consequently, IT security cannot just be mapped onto the ICS. Instead, the components used in the ICS may, and often do, require security-related ICS vendor-specific tools unknown to IT systems, such as custom event logs, port lockdown mechanisms, and features for disabling USB ports.

Difference #6: User accounts

IT systems generally support two levels of users: users known to the operating system (e.g., Windows users) and users of specific applications (e.g., order-entry systems). Operating system user accounts are used to authenticate the user during login and to identify which operating system resources the user can access. IT system administrators often administer operating system user accounts with Windows Domains/Active Directory. When multiple domains are present, IT administration establishes trusts between specific domains to let users access resources across domain boundaries.

IT systems also often contain applications, such as database applications, that have their own user accounts that can be independent of operating system accounts. For these applications, the user must go through a separate login screen before being allowed to access the data.

ICSs also use operating system user accounts and domains. However, allowing IT systems users to access the ICS by establishing trusts from IT system domains to the ICS domain is generally not recommended, since it reduces isolation of the ICS.

ICSs also have their own application-specific users. Unlike IT applications, however, the ICS is really a complete distributed system composed of configuration, operation, and maintenance applications, databases, and event journals. ICSs almost always use role-based access controls for granting/denying access to control data and devices. Operators, process engineers, and maintenance engineers are examples of these roles.

To manage access to these elements of the ICS, ICSs typically have an ICS-specific user management application. Although in principle this is similar to IT application security, the complexity, scope, and technical expertise required to administer ICS users is closely related to the nature of the process being controlled, which is generally not familiar to IT system administrators.

Finally, authorizing access from the plant network to the ICS becomes more difficult because of these differences. Do all external users become users of the ICS and its domain, or do DMZ server applications provide access to authorized IT system users but connect to the ICS using ICS credentials? Also, how is traceability maintained for auditable ICS transactions? Answering these questions normally requires collaboration between the ICS and IT systems administrators.

Difference #7: SIS

Plant safety is a critical part of plant operation, and ICSs, therefore, often include integrated, yet distinct, safety instrumented systems (SISs). The SIS is responsible for maintaining the safe operation of the process by placing the process into a safe state when process conditions that threaten safety are detected. IT systems have no systems analogous to the SIS.

SIS networks are usually proprietary and must be securely segmented and isolated from ICS networks. In addition, the SIS decision-making component, commonly called the logic solver, is also a custom, proprietary component, separate even from other components used in the ICS. Also, SIS-specific standards that include security are currently under development in ISA84. As a result, commonly used IT tools and network devices are not applicable to SIS network security.

Managing the security of an ICS includes an often manual effort to ensure that the SIS is protected from the ICS and from external interference, and that its integrity has not been compromised. These are capabilities not normally within the scope of IT systems professionals.

Difference #8: Untested software

IT systems are typically open systems, which allow them to run off-the-shelf software and to evolve over time. Evolution includes adding new software; updating workstation, server, and network device hardware and software; replacing components as needed; and even adding new components to the system. Keeping systems current is one of the approaches taken in IT systems to maintain security.

ICSs, however, are typically closed and implemented to a specific hardware configuration and operating system version (e.g., service pack), and may not run properly if either is changed. As a result, all updates, including patches and virus definition files, have to be thoroughly tested with the ICS before being approved for installation.

Likewise, all new software added to the ICS that is not supplied or supported by the vendor should be thoroughly tested for compatibility with the ICS. In some cases, as with those regulated by the Food and Drug Administration, the ICS and IT systems associated with the regulated product must be validated, and once validated, cannot be updated with new software without being revalidated. But for typical IT systems, this rigor is not common. Running software that has not been tested with the specific ICS is a serious concern, because of its potential to cause conflicts or failures within the ICS or introduce vulnerabilities of its own. Therefore, all software to be run in an ICS should be tested and approved using a formal operations change management process.

The most common way to protect against the introduction of unapproved software is to restrict installation privileges and to use access control lists for program directories. However, these mechanisms do not protect against executables that can be copied to the directory and run without being installed. Mechanisms to prevent this type of software from being loaded onto a workstation include disabling USB ports and CD/DVD drives and tight control or elimination of shared drives. Although these are commonly employed techniques in ICS workstations and servers, they are seldom used in IT systems.

Mechanisms to prevent unapproved software from being run are not as commonplace. While antivirus software can detect infected software, it cannot detect untested or unapproved software. For this, whitelisting is gaining acceptance in IT systems. Whitelisting complements antivirus programs by allowing only approved and authentic (uninfected) executables to run. However, because of the checks necessary to validate an executable each time it is run, performance is affected.

Software that has been approved to execute in an IT system often has not been rigorously tested for compatibility with the IT system. All software that is allowed to run on an ICS must be tested to ensure it will not interfere with the ICS.

Difference #9: Patching

IT systems normally have patch management software that automatically installs security updates very quickly after their release. On the other hand, it is not uncommon for patches to be deferred or postponed indefinitely in ICSs. ICS patching requires testing, approval, scheduling, and validation to ensure safe and repeatable control. Scheduling is required because of the potential disruption to operations, such as reboots. Reboots can cause a temporary loss of view/control, and worse, they can fail, often requiring technical intervention to return a failed component to service. As a result of the effort required and because of the associated risks, patching is often not performed on an operational ICS, or at least not on the same schedule as IT system patching.

In addition, because the lifespan of ICSs is so long, patches for many older systems are no longer available. For example, there are many ICSs still in operation that run Windows NT and Windows XP.

The challenge for ICSs, which is not shared by IT systems, is to keep unpatched systems secure. Typically this is done through compensating security mechanisms in an ICS’s defense-in-depth strategy.

Difference #10: Security inconveniences

As most of us probably agree, cybersecurity measures add a degree of inconvenience to our jobs. Who has not had to wait while operating system patches are being installed? Or who has not had to call the service desk to report that he or she is locked out and needs to have a password reset? But as cumbersome as they can be, we have all learned to live with these inconveniences.

However, in an ICS environment, such inconveniences may not be tolerable, especially those that decrease performance. Imagine not receiving a critical system alarm in time to respond to it, or having to handle it while the workstation decides to reboot itself. Also, having to use a long and complex password during a process upset may not be acceptable. While many of these inconveniences are not specific to ICSs, they can be intolerable to them.

As a result, security measures that are acceptable in IT systems may not be acceptable in an ICS. If indiscriminately employed in an ICS, IT security measures may pose one of the biggest threats to ICS security. Because they are so painful or disruptive, they often result in the security mechanisms being bypassed, disabled, postponed, or otherwise ignored. Not only will this expose the ICS to vulnerabilities, but it will also negatively affect attitudes of ICS users toward future attempts to secure the ICS.

We have examined how ICSs differ from IT systems with respect to cybersecurity. Unfortunately, failure to understand these differences often leads to conflicts between IT and ICS administrators, which leads to a less-than-optimal security solution for the plant. These discussion points should help promote communications and resolve conflicts.

About the Authors
Lee Neitzel, senior engineer at Emerson Process Management 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:

Bob Huba, system security architect, has been with  Emerson Process Management for 36 years. He is active in the development of the ISA-99/IEC 62443 standards.

Connect with Bob:

A version of this article originally was published at InTech magazine.

Bolster Security for Your Legacy OPC Server

Bolster Security for Your Legacy OPC Server

This guest blog post was written by Lee Neitzel, senior engineer at Emerson Process Management. 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.


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 Process Management 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.

How Do You Balance Connectivity with Security on the Plant Floor?

This guest post is authored by Jim Flagg, systems architect for Polytron.

Manufacturing facilities increasingly are becoming reliant on network connectivity to improve operational efficiency.  Getting an internet connection on the plant floor without running it through the enterprise IT department is quick and it gets the job done – as long as the network is only connected when your equipment or software vendor is providing remote support.  Everything should be OK, right?  Not quite.  When you prioritize connectivity without considering security, facilities are taking a serious risk.information security

We know that hackers are going after industrial equipment, but breaches are often underreported in an effort to minimize a manufacturer’s exposure.  Due to the increasing likelihood of network intrusions from both internal and external sources, manufacturing plant managers are beginning to realize they need to balance connectivity with security from the start.

Connecting with Security

When companies invest in secure connectivity, the two primary goals are to provide:

  • Enterprise network connectivity so managers can collect critical data from the plant floor. This enables companies to easily analyze data to assess production levels, procurement needs, downtime and whether manufacturing goals were met.
  • Internet connectivity that enables authorized employees to connect to the plant floor through a VPN for remote support, updates and diagnostics resulting in a significant reduction of support costs.

Due to the critical nature of manufacturing, secure barriers must be established between enterprise networks and manufacturing networks.  A large part of the security implementation is in the physical setup of the connections.  For example, a tiered network is much more secure than a flat one.  Software needs to be programmed to specify which users and data should be allowed through to control these data flows.  Finally, multiple firewalls can be installed to monitor connectivity and ensure compliance at the various intersections of enterprise and manufacturing networks.

Lax information security policies and practices can be a serious issue when your IT infrastructure converges with your plant floor.  Most businesses use firewalls to prevent outsiders from infiltrating their systems, but many breaches actually come from INSIDE the company.  Security isn’t just an add-on − it should be baked into your IT at every level.  A tiered infrastructure with varying degrees of access and security provides the highest levels of protection and will help prevent the worst of disasters.

The good news is that these security measures don’t have to be overly intrusive.  With proper planning, you can improve your plant’s security while maintaining connectivity for better operational efficiency.

Planning for Security

One of the hardest parts of properly implementing connections between a plant floor and the enterprise is getting everyone to work together efficiently.  I often see gaps between plant engineering and the enterprise IT department, so getting a third party involved to consult with the entire organization helps bridge the gap for an optimal solution.

A thorough plan is required to establish a secure manufacturing execution system (MES) that will allow a company’s enterprise operations to obtain the appropriate data from the plant floor for the management of resources, global procurement and other elements of the production process.  To create a plan, assess the needs of the enterprise IT department and the engineering team.  This will help you determine what is currently in place versus what you may need to incorporate into your manufacturing operations.  To ensure a smooth transition, test the solutions prior to the final rollout.

Finding the Right Solutions

The key to implementing an optimal, balanced solution is to focus on designing plant connectivity with a high level of security from the ground up.  It is important to assess your entire system for vulnerable points and close any security gaps quickly.  Then, as network upgrades are made − whether equipment components or systems configuration − security should be one of the top priorities in decision-making for design, platform and software.  Involving key managers from both the enterprise IT department and plant engineering helps ensure all user data needs are addressed as security is applied at the appropriate levels.

Have you assessed your network security?  How are you addressing security today?

About the Author
Jim Flagg, MCP, PMP, is a systems architect for Polytron with 30 years of experience working on automation and manufacturing intelligence projects.  A graduate of Georgia Tech, Jim has worked on everything from PLC and drives through HMIs and MES/MI systems.  Since 2004, Jim has been the lead technical engineer for Polytron’s MI projects.  In this position he has consulted with multiple clients to develop their overall software and hardware architecture for providing plant data to company personnel.  Most of these projects include developing a URS (user requirement specification) that will meet their current and future data collection, reporting and ERP interface needs.
Leveraging DoD Wireless Security Standards for Automation and Control

Leveraging DoD Wireless Security Standards for Automation and Control

This guest blog post was written by Thurston Brooks, vice president of product marketing, Ultra Electronics, 3eTI,

Over the last several years, the use of wireless networks in control systems has yielded a number of benefits to critical infrastructure while revolutionizing operations in key areas of industry, such as energy and transportation. Apart from the benefits of eliminating signal and power wiring, wireless sensor networks can enable measurement applications in sites that are hard to access, or where the wiring cost cannot be justified. They are also invaluable for modernizing existing legacy facilities, for temporary installations, or for locations where a power source is not available. However, the practical implementation of wireless technology in industrial settings has faced a number of challenges, not least of which is the adoption of industry security standards.


By definition, predictive analytics encompasses a variety of techniques from statistics, modeling, machine learning, and data mining that analyze current and historical data to predict future events. The nature of predictive analytics pushes the pursuit of asset reliability from its residual reactive orientation to one that is fully forward-looking and better aligned with the goals and realities of today’s manufacturing environment.

The increased transmission of plant data through networks has given rise to ominous cyber attacks that threaten networks, businesses, and end-user devices alike. Wireless sensor networks (WSN) are currently receiving the most industry attention focused on such areas as condition monitoring, process control, wireless instrumentation, and measurements. One of the greatest inhibitors to the adoption of WSN in the private sector is the concern for security in critical industrial applications. While significant advances have been made in topology management, routing algorithms, and sensor data management, lingering concerns remain that WSNs are inherently untrustworthy.

Integrating wireless into legacy networks designed for and deployed in enterprise environments provides increased flexibility and ease of use, but the need for security on the physical and network levels – and even the protocols built atop it (i.e., ISA100, WirelessHART, and 6LowPAN) – reflects the heightened stakes when these networks are deployed for critical operations in industrial settings.

ICS-CERT incident response trend data.

Today, most general-purpose operational systems incorporate ISA-adopted security concepts. However, there is no guarantee that a supplier selling commercial-off-the-shelf (COTS) products has implemented security correctly. To overcome lingering security concerns about the use of wireless networks in critical industrial operations, facility managers are increasingly looking to the government for guidance on deploying secure networks more effectively. Government agencies require a minimum level of assurance that a product’s stated security claim for protecting sensitive data is valid. Today, the government develops and implements networks using proven security standards, such as independently tested and certified-for-compliance solutions to ensure industrial applications and critical data are sufficiently protected.

Industrial control systems: under attack

Although recent cyber-attacks on The New York Times, Twitter, and major U.S. banks have received disproportionate media attention, industrial control systems have increasingly become a target of choice for attackers, who have specifically sought to disrupt and damage industrial control systems and their integrated wireless networks. “Alerts of possible risks to critical infrastructure operations released by the Industrial Control Systems (ICS) and Cyber Emergency Response Team (CERT) are up 50 percent from a year ago,” said Earl Perkins, research vice president in systems, security, and risk at Gartner.

In fact, a Department of Homeland Security (DHS) report released in January revealed that industrial control systems were hit with 198 “documented” cyber attacks in 2012 and that many of these attacks were deemed serious. Forty percent of those attacks were on energy firms, according to ISC-CERT, which reviewed every incident. Water utilities came in second, with 15 percent of the attacks focused on them.

Wireless advantages in industrial applications.

The meteoric rise in successful cyber attacks demonstrates that attackers can not only disrupt communication networks but also the automation and control systems that are linked to them. Defense Secretary Leon Panetta pointed to cyber attacks in a recent policy announcement, noting that they mark “a significant escalation” in cyber warfare. Many of these threats can be effectively counteracted by private industry through the use of military-grade, COTS security processes in their industrial control systems.

ISA100 security by design

In the industrial automation and control world, insecure devices, such as access points and user stations, can seriously compromise both wireless networks and wired networks. Hackers deliberately target insecure devices, using specialized tools to break encryption and authentication. Since most wireless networks connect back to a wired network at some point, hackers can use any unsecure wireless station as a launch pad to breach a network.

ISA99 is the Industrial Automation and Control System Security Committee of the International Society of Automation (ISA). The purpose of the ISA99 committee is to develop and establish standards, recommended practices, technical reports, and related information that will define procedures for implementing electronically secure industrial automation and control systems and security practices.

Today, many plant operation systems have adopted ISA99 security protocols, although it is not mandatory. Unfortunately, Gartner’s Earl Perkins has found that, “there is denial in some portions of industries with critical infrastructure regarding the true threat,” referencing “cyber threats” damaging and disrupting industrial control systems in the recent ICS-CERT report. The first step in embracing the ISA99 protocols is simple recognition that cybersecurity is not an irrelevance or distraction, but rather must become an integral component of planning and acquisition from the outset.

ISA99 provides additional focus to improve the confidentiality, integrity, and availability of components or systems used for industrial automation and control and to provide criteria for procuring and implementing secure control systems. They endeavor to improve system security and help identify vulnerabilities to address them, thereby reducing the risk of compromising confidential information or causing degradation (or failure) of the equipment or process under control. These three concepts (confidentiality, integrity, and availability) form the basis of businesses’ IT security. For enterprise systems, the first priority is confidentiality. Logically, for real-time operational systems used in industrial settings, the priorities are reversed, with availability shifted to top priority – the control system needs to operate 24 hours a day, without interruption, for long periods of time. Systems are designed to operate at multiple levels, with redundant control computers backed up by local controllers that are, in turn, backed up by safety shutdown systems.

A major step in adopting good security lies in how it is implemented. ISA100 incorporates basic “security by design,” a concept that incorporates security into all aspects of network design, construction, and operations. Successful security by design results in a more robust security infrastructure that minimizes insider access to materials and opportunities for risk(s) associated with malicious acts (i.e., sabotage, diversion, etc.), while providing flexibility to respond to a changing threat environment.

Wireless networks created under the ISA-100.11a-2011 standard feature authentication and encryption controlled by a flexible security policy, which can be varied under ISA-100.11a’s two-layered security methodology. First, “link layer” security is associated with hop-to-hop authentication and encryption. ISA-100.11a wireless subnets feature multi-hop, mesh-enabled subnets with packets of data being routed over multiple devices to the subnet extraction point. Each router used in this apparatus authenticates and encrypts/decrypts the packet that it routes.

The second layer, or “transport layer,” security, is associated with end-to-end authentication and encryption of data messages. Here, the originating device authenticates and encrypts the packet at the transport layer, and only the destination authenticates and decrypts the packet. This is accomplished through sessions that are established between pairs of devices that communicate at the transport layer.

Various levels of authentication and encryption can be enabled for both layers of security, and these levels are inherited from the security policies supported by IEEE 802.15.4 – the underlying wireless technology on which ISA-100.11a is based.

Although ISA100 has security built in by design within the standard, it still needs to be implemented correctly. In effect, improperly implemented security is equivalent to no security at all. Many vendors claim product functionality and/or offer security without any validation or oversight. Knowledge gained from DHS CSSP assessments and ICS-CERT documented daily on their ICS-CERT vulnerability disclosure policy web page proves that the number of product vulnerabilities found in the industrial control sector continues to rise.

Demystifying government-validated solutions

The federal government and Department of Defense (DoD) facilities require resilient networks that assure delivery of critical assets to support our armed forces at home and abroad. Current mandates provide significant incentive for these agencies to build more efficient and resilient systems that consume less energy and are protected from disasters, accidents, and attacks.

Government agencies require a minimum level of assurance that a product’s stated security claim for protecting sensitive data is valid. Today, federal policy requires government agencies to develop interconnection agreements for federal systems that share or exchange information with external networks. For wireless networks, government agencies require FIPS 140-2 validated encryption to ensure the protection of data in transit. Considered a benchmark for security in government, FIPS validation assures users that a given technology has passed rigorous testing under either the CAVP (cryptographic algorithm validation program) or CMVP (cryptographic module validation program).

Private sector vendors who want to have their products certified for use in government departments (and regulated industries) must complete a rigorous government-validation process in order to meet the security requirements set forth for federal organizations by the National Institute of Standards and Technology (NIST). Once tested and certified, private sector vendors can assure government agencies that all data downloaded to wireless devices is in full compliance with U.S. federal government guidance and policy.

Core components of the ISA99 Security Standards are built from the defense-in-depth (DID) strategy, which was conceived by the National Security Agency (NSA). The DID strategy, largely employed by the U.S. government, is based on implementing multiple layers of security controls (defense) throughout a system. Its intent is to provide redundancy in the event that a security control fails or vulnerability becomes exploited, as a single countermeasure cannot be depended on to mitigate all security issues.

Implementing a secure wireless infrastructure using validated solutions.

There are also legislative restrictions regarding certain types of technology, such as cryptography, that require federal agencies to use only tested and validated products. Today’s DoD standards can act as an important role model to encourage industry to develop and implement solutions that are independently tested and certified for compliance. Without independent validation, there is no guarantee that the supplier has subjected their product to sufficiently rigorous testing. Independent validation allows buyers to obtain that assurance and perform necessary product security comparisons.

Implementing standards-based secure wireless (case study)

In October 2009, the Secretary of the Navy laid out five aggressive energy goals to improve energy security and efficiency, increase energy independence, and help lead the nation toward a clean energy economy. In 2010 the Navy initiated a SmartGrid pilot program comprised of interconnected technologies that could securely, collectively, and intelligently monitor, predict, control, and respond to building and utility management systems.

The need to deploy sensors anywhere in distributed environments requires a tremendous effort, and the DoD was quick to recognize the cost and time benefits of integrating advanced wireless solutions into its existing network infrastructure. For example, wireless integration could accommodate a variety of topologies and meet the needs of specific applications while increasing productivity and providing a path toward lower operational costs. However, the DoD’s stringent security requirements limited the Navy to those solutions that offered FIPS 140-2 validated encryption and Common Criteria certified levels of security.

Although many companies offer wireless solutions, none had robust products that met the DoD’s information technology security requirements while providing battery-powered wireless sensor interfaces. The solution had to fully comply with DoD information security requirements, including directives for information assurance (IA) during activities involving data and information interchange. Meeting all these requirements was critical to enabling a successful integration and program rollout. There is a new breed of solutions, such as the AirGuard iMesh wireless network technology, that are ISA100-compliant for industrial sensor networking based on security that is independently validated, approved, and deployed by the U.S. military. Designed for lower power and flexible integration, these devices form a cyber-secure bridge linking ISA100 sensors nodes with 802.11 Wi-Fi and Ethernet networks for sensor applications, including oil refineries, utilities, factories, electrical power substations, and processing plants to interface a variety of sensors (pressure, temperature, vibration, etc.) to remote network locations. The resulting industrial wireless mesh network enables system operators to improve regulatory compliance while achieving greater visibility over system operations with configurable sensor sampling and reporting.

The Navy is now deploying two systems, which utilize wired and secure wireless mesh technology. The first system is the Enterprise Industrial Controls System (EICS) – an advanced, cyber-secure, wired and wireless sensor networking system that integrates disparate industrial control systems across several Navy bases into a centralized facility operations center. The second system, the Virtual Perimeter Monitoring System (VPMS), is a wired and secure wireless critical infrastructure protection and perimeter monitoring solution. Leveraging a robust, integrated network enabled through the use of secure wireless technology, the Navy is moving to control energy to achieve cost savings and efficiencies, ensure critical infrastructure operations, and enhance situational awareness. More than 5,000 secure wireless devices are being installed to network sensor systems on DoD installations. They will measure energy usage and energy allocation while enabling real-time energy resource management to reduce energy consumption at the building level while complying with the Energy Policy Act of 2005 and the Energy Independence and Security Act of 2007.


The military is realizing the benefits of deploying integrated systems that leverage secure wireless technology. These benefits range from obvious cost reductions brought about by the elimination of wiring to better plant productivity, improved asset management, and strong data reporting. The success achieved while complying with the DoD’s restrictive security requirements demonstrates that secure wireless technology can be adopted by operators of critical systems looking to implement more robust, secure, reliable, cost-effective systems.

In the absence of any commercial or federal cybersecurity standards or requirements, the industrial sector has looked to the military for an example of best practices and security requirements. Although integrated networks provide undeniable benefits, some critical infrastructure operators are still in denial about cyber threats targeting, disrupting and/or damaging industrial control systems. Recent threats such as Stuxnet and Flame have powerfully demonstrated that once-theoretical threats have now become a reality; cyber attacks that threaten to penetrate and sabotage critical control and monitoring systems continue to generate serious consequences.

Many of these threats can be effectively countered and defended against with changes to key security processes and organization. Cyber warfare is not just a threat for the future – it is a very real threat today, forcing an increased need for robust security to ensure the continued operation and protection of critical control and monitoring systems worldwide. The time to future-proof plant control systems is now, and the DoD approaches described in this article should pave the way for broader industrial adoption of secure wireless networks.

Thurston Brooks

About the Author
Thurston Brooks, vice president of product marketing, Ultra Electronics, 3eTI, is focused on developing new technologies and solutions for industrial and commercial applications for the protection of critical infrastructure. He has more than 30 years of professional experience in developing and managing a wide variety of solutions for military and industrial applications and holds engineering degrees from the University of Florida (B.S.), the Massachusetts Institute of Technology (M.S.), with a thesis in human-machine systems and controls, and the University of Chicago (M.B.A.). He contributed as a key member of the IEEE/NIST Committee on Smart Sensors (IEEE 1451). Brooks has authored more than 45 publications in referred journals, symposiums, and conferences, and holds two patents. One patented product won the 1993 Star Tech Award for best new product in Washington Technology magazine.

This post originally was published at InTech magazine.

Pin It on Pinterest