Data Diodes for Levels 2-3 and 3-4 Integration

Blog entry by Stan DeVries.

Data diodes are network devices which increase security by enforcing one-direction information flow.  Owl Computing Technologies’ data diodes hide information about the data sources, such as network addresses.  Data diodes are in increasing demand in industrial automation, especially for critical infrastructure such as power generation, oil & gas production, water and wastewater treatment and distribution, and other industries.  The term “diode” is derived from electronics, which refers to a component that allows current to flow in only one direction.

The most common implementation of data diodes is “read only”, from the industrial automation systems to the other systems, such as operations management and enterprise systems.

This method is not intended to establish what has been called an “air gap” cybersecurity defense, where there is an unreasonable expectation that no incoming data path will exist.  An “air-gap” is when there is no physical connection between two networks.  Information does not flow in any direction.  Instead, the data diode method is used as part of a “defense in depth” cybersecurity defense, such as the NIST 800-82 and IEC 62443 standards.  It is applied to network connections which have greater impact on the integrity of the industrial automation system.

One-way information flow frustrates the use of industrial protocols which use the reverse direction to assure that the data was successfully received, and subsequently triggers failsafe and recovery mechanisms when information flow is interrupted.  A data diode can pass files of any format and streaming data such as videos and an effective file transfer, vendor neutral approach, in industrial automation is to use the CSV file format.  The acronym CSV stands for comma-separated values, and there are many tools available that quickly format these files on the industrial automation system side of the data diode, and then “parse” or extract data on the other side of the data diode.

There are 2 architectures which are feasible with data diodes, as shown in the diagrams below.

The single-tier historian architecture uses the industrial automation system’s gateway, which is typically connected to batch management, operations management and advanced process control applications.  This gateway is sometimes called a “server”, and it is often an accessory to a process historian.  A small software application is added which either subscribes to or polls information from the gateway, and this application periodically formats the files and sends them to the data diode.  Another small application receives the files, “parses” the data, and writes the data into the historian.

The Wonderware Historian version 2014 R2 and later versions can efficiently receive constant streams of bulk information, and then correctly insert this information, while continuing to perform the other historian functions.  This function is called fast load.

For L2-L3 integration, the two-tier historian architecture also uses the industrial automation system’s gateway.  The lower tier historian often uses popular protocols such as OPC.  This historian is used for data processing within the critical infrastructure zone, and it is often configured to produce basic statistics on some of the data (totals, counts, averages etc.)  A small software application is added which either subscribes to or polls information from the lower tier historian, and this application periodically formats the files and sends them to the data diode.  Another small application receives the files, “parses” the data, and writes the data into the upper tier historian.

The Wonderware Historian has been tested with a market-leading data diode product from Owl Computing Industries, called OPDS, or Owl Perimeter Defense System.  It uses a data diode to transfer files, TCP data packets, and UDP data packets from one network (the source network 1) to a second, separate network (the destination network 2) in one direction (from source to destination), without transferring information about the data sources.  The OPDS is composed of two Linux servers running a hardened CentOS 6.4 operating system.  In the diagram below, the left Linux server (Linux Blue / L1) is the sending server, which sends data from the secure, source network (N1) to the at-risk, destination network (N2). The right Linux server (Linux Red / L2) is the receiving server, which receives data from Linux Blue (L1).

The electronics inside OPDS are intentionally physically separated, color-coded, and manufactured so that it is impossible to modify either the sending or the receiving subassemblies to become bi-directional.  In addition, the two subassemblies communicate through a rear optic fiber cable assembly which makes it easy for inspectors to disconnect to verify its functionality.  The Linux Blue (L1) server does not need to be configured, as it accepts connections from any IP address. The Linux Red (L2) server, however, must be configured to pass files onto the Windows Red (W2) machine.  This procedure is discussed in section 8.2.2.6 of the OPDS-MP Family Version 1.3.0.0 Software Installation Guide.  The 2 approaches can be combined across multiple sites, as shown in the diagram below.  Portions of the data available in the industrial automation systems are replicated in the upper tier historian.

Deployed Enterprise Historian in the Cloud Discussions with Actual Use Cases, Confirms the Opportunity for Leveraging the Cloud to Increase Uptime.

This week I had dinner with a client from the water industry who has just deployed Invensys's Enterprise Historian in the cloud. While I have had many discussions with potential users of historian in the cloud, but the opportunity to discuss 1 on 1 with one of the first implementers was too tempting.

He comes out of the water industry, and they deployed two systems, for two city water systems. They have tiered architecture with tier 1 historian on sites, feeding to the Enterprise Historian. They have used a local historian, with a 7 day storage, with the intent of using the Cloud Enterprise Historian as the analysis tool across the sites, for analysis.

I asked, " why had they gone to the cloud?"

The answer was due to increased reliability in the cloud vs hosting at the city Center and expecting someone to maintain it.

They have found over time the reliability of having a historian on site for long term data in cities is not effective, as the maintenance on the PCs/ servers, upgrading OS’s and management of archiving the data was not been done as regularly as required. With the increased regulations requiring data to be stored for at least 7 years, this risk needed to be addressed. A discussion of why this issue of historian maintenance was an issue and it came down to the Historian falling under the plant automation teams, and they did not see the PC’s and Servers as maintenance items, like they did say a pump. IT, on the other hand, would monitor the PC with performance measures to escalate issues.

So to resolve the issue the client has taken advantage of the new Enterprise Historian in the cloud offering from Invensys/ Schneider Electric where the historian is managed by Invensys/ Schneider Electric, in its cloud system working with Microsoft Azure. The uptime of the system is supplied by Microsoft with it’s Azure infrastructure, and data centers, combined with the expert managed services from Invensys / Schneider Electric. Who install and set up the system, monitor the system for data usage and archiving, and manage the operating System, and product upgrades?

Removing the whole management of the data from customer.

A series of clients hosted in the cloud are available for analysis by the user.

There was no question of security; it was assumed and believed that Cloud infrastructure is more secure than they can maintain on remote sites. This has been proven many times, and I ask people who doubt this to understand how secure your own managed historian is from an up time point of view and data security, especially as the breadth of users accessing the data increases.

It was nice to validate the original intent of building an Enterprise Historian in the cloud, and reaffirm the trend we seeing of the internet becoming a natural part of the industrial information architecture.

This case was interesting as it was new, but I suspect a year from now this will be common, as the challenge of maintaining historians and servers on remote sites, or in companies scaling back on plant engineers increases.  

The comment I heard in New Zealand a year ago “ why would I put a server on a plant site in water again” comes ringing back to my ears!  

Big Data Requires a Big, New Architecture

“The potential of “big data,” the massive explosion of sources of information from sensors, smart devices, and all other devices connected to the Internet, is probably under-appreciated in terms of its eventual business impact. However, to take maximum advantage of big data, IT is going to have to press the re-start button on its architecture for acquiring and understanding information. IT will need to construct a new way of capturing, organizing and analyzing data, because big data stands no chance of being useful if people attempt to process it using the traditional mechanisms of business intelligence, such as a data warehouses and traditional data-analysis techniques.” Dan Woods; Forbes

So does this apply to Industrial Area, I was heading through Terminal 5 in Heathrow this week, and articles banners around Big Data were all around me, and yes it is the latest “train” for people to board, but is it real in the Industrial Space? As I boarded a train, sat doing a mind thinking moment looking at the industrial operations/ automation landscape I realized why there is confusion is that in the industrial space,  we talk about Enterprise Historians, and one person said to me that is big data! I do not think so, it is just one aspect of the growing industrial information dilemma facing all us over the next 5 years.

When I look at the predictions of Big Data by Industry from Gartner:

The column for “Manufacturing and Natural Resources” which has every row in “Hot” or greater and points to “Volume of data”, “Velocity of data” and especially “Underutilized Dark Data” as Very Hot. This is should not be a surprise to anyone with the historians out there with 10000s of tags soaking up the data at second intervals. In the last 7 years,  Invensys Wonderware has installed 128 million I/O in historian points. Another point not brought out here is the need to make the data “trust worthy” and auditable so business decisions can depend upon it, much of the industrial data is just captured today, not validated against the current state of the process etc.

Now lets understand the “Jobs People want to do today” has there been a change? Yes there has been around the responsibility scope increase. This is both in making decisions and more business impactive decisions, as well as the increase in breadth e.g. Area that a person has to manage.

Initially this seems okay, but  now consider  the devices in the field today, and the amount of data coming from a device that traditionally would have 2 to 3 points, can have 400 points. Is this exaggeration, lets look at an example of a pump.

In the old days,  a pump would have:

• Speed
• Pressure

 Today:

• Speed
• Temperature
• Pressure on incoming and outgoing
• Vibration
• Energy calculations (many variables)
• Number of starts
• Volume
• On goes the list

The reason is that today devices are much smarter this to improve performance, efficiency, maintenance lifetime, and energy consumption management as well as predicting the operational reliability of  the pump. Compared with the old requirement of turning it on and making sure it is pumping to make sure it does not run dry.

Now take one device and put it in a plant context where it is one of 1000s, we have effectively increased the volume of data by 100000s and it will not stop growing. So the ability to capture this data as close to local data source, validating the data, but accessing the data, understanding events, patterns, and relationships across devices, plants, and device types etc required for this ever increasing drive to lower the OPEX costs, through increased efficiency and lower maintenance lower energy consumption  etc.  Again review this data historised for  a pump, the data falls under multiple categories:

·         Operational

·         Energy

·         Maintenance

·         Efficiency

Different roles within the “day to day” running of the industrial operations will analysis the data in different ways, to draw different conclusions. Examples are some people will want to look across multiple pumps and compare efficiency, energy etc vs the Operator who is just look at the current status and availability.

Will the traditional industrial tools be good enough?  I do not think so as all data is not in one form, one data source, take the above time series historian data, combine this alarming, events, and operational data. The introduction of new architectures, “Information Models” and analysis tools which will enable a view across large amounts of data, put this data in the context (this does not mean a data warehouse) and analysis tools quickly bring out trends/ relationships between data from different sources over large areas. All with the simple objective of enable more “real time decisions support”. An example of this is in the latest Wonderware Information Server 2012 R2 (released this month) with a new operational analysis capability. Seen below this capability is out of the box across, MES, Batch, Time series historian data and alarms data sources, providing an immediate view into a trend with a “halo” to show the shift, or batch or phase of operations the process was in, and associated alarm data, all at the operators finger tips.

This is the first step as Invensys will be expanding this capability through the next few years across the Enterprise Control Solution. I will expand on this Big Data in Industry and Decision Support concepts over the next couple of weeks.