Skkynet’s Approach Calms Recent Security Concerns

Eyebrows were raised among the industrial automation community last week when the well-known Kaspersky Labs issued a report titled OPC UA Security Analysis that lists 17 security issues in the OPC UA protocol and products. While we seen no reason to doubt their methodology, we take a different approach to the question.

As we see it, the real issue is not the OPC UA protocol itself. OPC UA was created to allow client/server networking for industrial communication. The flaws that Kaspersky identified were visible on an OPC UA server that, by definition, is listening for network connections from OPC UA clients. Any application that listens for connections on a network can equally be a point of attack for a malicious hacker. This is not unique to OPC UA—it is a fact of the design of TCP/IP networks. Period.

Think about it. How did Kaspersky Labs discover the vulnerabilities in OPC UA and related products? Using a technique called “fuzzing”, they used a specially-constructed client application to send a rapid-fire barrage of messages at the UA server, each of which was slightly altered, or “mutated”, in some way from a standard message. Sooner or later one of these messages would crash the server or uncover an exploitable vulnerability. This technique can be used on any network-connected server, like a web server, VPN server, RDP server or vendor-supplied remote access server.

We would argue that Kaspersky Labs was searching for symptoms while overlooking the cause. What the report does not address, and indeed it is so obvious that it is easily overlooked, is that this kind of attack can only succeed if the intruder has access to the server in the first place. All software has bugs. Any program exposed to the Internet is fair game. However, as long as your servers are running on a trusted network and you keep all inbound firewall ports closed, you don’t run the risk of an attack from outside, no matter how persistent or devious the attacker may be.

The Real Problem

The real problem is that the standard approach to industrial data communications is not suitable for untrusted networks like the Internet. We are used to a client on the user side connecting into a server at the data source―after all that’s the classic server-client architecture. But for Industrial IoT this approach poses a serious risk because the client is often outside the trusted plant network. It needs an open firewall port into the plant to connect. This design itself is the fundamental reason for the security problem. Rather than expecting protocols or software to be bug-free and invulnerable to attack, it makes more sense to find a more secure design approach altogether.

A Better Approach

A better approach is not to allow any inbound connections at all. The whole Kaspersky Lab scenario was built on repeated client connections into the server network. What if the server (over which the attacker has no control) connects out to the client? If you can establish only outbound connections from a data source to a data user, then the entire threat vector is eliminated. With all inbound firewall ports closed, the plant network and all of its OPC UA servers become invisible. And you can’t attack something that you can’t see.

This is Skkynet’s approach. It is running in production systems worldwide, and it is fully compatible with OPC UA. By keeping OPC UA servers within the trusted network, and keeping all firewall ports closed, Skkynet’s approach enables secure Industrial IoT connectivity, while still reaping the benefits of OPC UA in the plant.

Note: A version of this article was recently published on the website.

System Integrators Waking Up to IIoT at CSIA 2018

Each spring owners, CEOs, and other leaders from some of the world’s top automation and control system integration companies meet to share their experiences, sharpen their skills, and catch up on the latest trends at the annual Control System Integrators Association Executive Conference, CSIA 2018. This year the event was held in cool and breezy San Francisco, with a record attendance of just under 600 participants

Compared to last year the importance of IIoT is becoming more recognized among conference organizers and participants alike.  Several of the talks and workshops had “IIoT” in their title and content.  When we told people we work in the Industrial IoT space, the response was usually interest combined with varying degrees of understanding.

Growing Understanding

Despite a growing familiarity with the term “IIoT”, there seems to still be quite a bit of uncertainty about what it is, and more importantly, its value.  In one workshop I attended, there was a lively conversation about the precise definition of IIoT.  After several opinions were given, the general consensus was that IIoT can mean different things to different people.  Some, for example, saw little difference between IIoT and SCADA, while others attempted to simplify the terminology to meet their understanding, such as by defining the term “edge processing” as “a fancy way of keeping data in the plant.”  You could sense the sincere efforts to embrace the new concepts of IIoT, mixed with a reluctance to step into a new mind-set.

This new mind-set is in some ways easier to accept by professionals and experts outside industry.  In another presentation, Evolution of the SI (System Integrator) Role, Tony Rigoni of Cisco Systems spoke about the growing demand for bridging OT (Operational Technology) and IT via IIoT, and said that IT system integrators can’t do it right now.  They don’t have the industrial background or experience.  But he warned that system integrators in OT need to get on top of it quickly, because the IT people are waking up to the opportunity.

The Value of IIoT

Other non-industrial professionals at CSIA 2018 eyeing IIoT opportunities include investors.  In a panel discussion among venture capitalists and investment bankers, David Mount from Kleiner Perkins, whose focus is primarily on IoT companies said, “The value of IIoT will be in connected control.” In other words, bidirectional data communication.  Underlining his point, he said, “Closing the loop is a big opportunity.”

What he was alluding to is a capability we have been offering for several years now—the ability to not only collect data and store it in the cloud, but also the ability to send commands back to the system.  Sometimes referred to as “supervisory control,” this can be as simple as switching off a pump that is overheating to updating recipes or sending complex commands.  Instead of just storing data, the cloud now becomes a conduit for securely exchanging data and control in real time.

As system integrators worldwide wake up to the wealth of opportunity inherent in IIoT, it is our responsibility and our privilege here at Skkynet to offer them the full value of IIoT, from integrating plant OT with office IT to the ability to connect and control remote systems, anywhere, securely, in real time.

Extraordinary Remote Service Management through IIoT

We’ve all heard about helicopter parents. You know, that mom or dad that keeps hovering over their child, choosing their clothes and their friends, checking out their Facebook pages, watching their every move. Hey, after all, they’ve invested a lot of time and money into their offspring, and they aren’t going to just let those kids go out on their own and mess things up, right?

While that might not be the best parenting model for human children, it may transfer well to physical products—particularly expensive, complicated products like machine tools. Builders of industrial equipment are often responsible, by choice or by contract, for the performance and maintenance of their machinery for years after the sale. Mechanical failure is not an option for an assembly line whose down-time costs can be in the tens of thousands of dollars per minute. More and more customers buying equipment are looking for 24/7 monitoring and remote service management. And more and more vendors and OEMs are turning to the Industrial IoT (IIoT) for solutions.

With or without IIoT?

Consider the options. Without the IIoT, a lot of time gets wasted between the detection of a problem and a repair. The company calls the vendor, who sends out a rep to inspect. The rep then processes a work order, which may require a second visit by someone with the right skills, tools, and parts to make the repair. The whole process can take hours, even days, while the machine, and sometimes the whole line, sits idle.

With the IIoT, the vendor or OEM maintains a full-time connection to the machine, and can continuously monitor every aspect of its health, such as operating temperatures, abnormal vibrations, fluid levels, and so on, via the web. Before a problem is even noticed by an operator, the vendor can detect an irregularity, assess the situation, manage a work order, and send out repair personnel right away. Sometimes they can even make the repair remotely, without any on-site visit at all.

“OEMs tell ARC that 30 percent or more of the repairs can be made via the web by modifying parameters remotely or with minor assistance by an onsite person,” says Ralph Rio of ARC Advisory Group in a recent article, How IIoT Improves Field Service Management KPIs.

Extraordinary service

The IIoT makes an extraordinary level of service possible. But it’s not just any IoT platform that will be so helpful. Giving a vendor access to a piece of equipment inside a plant requires deep trust. The connection needs to be secure. Within that secure connection, the vendor should not have access to the whole plant network, just to the data. And then, to modify a parameter or change a machine set point requires bidirectional data flow.

Many IoT platforms offer Internet connections, but few of them can securely connect into an industrial plant without opening a firewall. Among those that can, many rely on VPN technology, which opens the whole plant network to the vendor. Of those that are able to make a connection without a VPN and still keep all firewalls closed, most are offering only one-way data flow, from the plant to the cloud. It takes an extraordinary service to provide what Ralph Rio is talking about: the ability to modify parameters remotely, and do it securely. It is exactly this extraordinary level of service that SkkyHub offers. For those vendors and OEMs that want supervisory control over their offspring—their products—this is the kind of remote service management that works best.

What Makes an Ideal Protocol for IIoT?

If you want to ship goods, you need infrastructure.  Trucks, trains, ships, and planes rely on highways, tracks, ports, and airports.  In a similar way, a key element of Industrial IoT (IIoT) is the infrastructure, in other words, a data protocol.  Just as there are many transportation modes to choose from (some better than others), there are a number of IIoT protocols on offer―and they are not all the same.

Since the IIoT is still quite new, it has been an ongoing question as to what makes an ideal IIoT protocol.  With limited experience in this new sphere, many early adopters have looked to existing protocols.  For example, companies are currently using or considering MQTT or AMQP messaging protocols, the REST web services protocol, or the OPC UA industrial protocol.  Each of these works fine in its own application space, and each seems like it could work as an IIoT protocol.  But are any of these really suited to task? Or is there something better out there?

9 Criteria for an Ideal Protocol

To answer that question, we did a comparison.  We distilled over 20 years of hands-on experience in industrial data protocols and TCP networking into 9 criteria for what makes an ideal protocol for IIoT.  The results are summarized in a new white paper, IIoT Protocol Comparison.

These 9 criteria cover all of the essential areas of high-quality industrial data communication, like real-time performance and interoperability.  They also cover the broader arena of the Internet, with its greater security risks, variations in bandwidths and latencies, and multi-node architectures.  The white paper considers specific criteria for each of these in turn, and provides a simple explanation of how each of the protocols does or does not meet them.

If you’ve been following the growth and development of Skkynet over the years, the results of the comparison should come as no surprise.  The only protocol we are aware of that was designed from the ground up to provide secure networking of industrial data both on-premise and over the Internet is DHTP.  DHTP is what our products and services have been using for over 20 years, and it is one of the keys to their success.  We invite you to read the white paper, consider the criteria, and see for yourself what makes an ideal protocol for IIoT.

IIoTのための理想的なプロトコル – DHTPの開発

Industrial IoT(IIoT)の概念が普及して以来、人々はそれに対して理想のプロトコルを見つけようとしてきました。 結局、IIoTは新しいものです。「Internet of Things」 と同じように、インターネットを横切って走行するデータに関わっていることは明らかです。しかし、“Industrial”では、FTPやHTTPのような一般的インターネットプロトコルを超えるものが必要です。IIoTプロトコルとして最良の選択は、工業的要件とインターネット要件の両方を満たすよう設計されたものです。

Skkynetでは、DHTPというプロトコルを使用しています。—DHTP (DataHub Transfer Protocol) 20年前の創業以来, DataHub 技術は、リアルタイムにネットワークとインターネットを介して異種システムの接続に関わってきました。 90年代には、QNXリアルタイムオペレーティングシステムで実行されるプログラムとWindowsで実行されるInTouch HMI間でデータを交換する、Cascade Connectという製品を使用していました。 Cascade Connectは、DataHubの前駆体である2つのコネクタを使用しました。1つはQNX、もう1つはWindows上で実行されていました。 これらはそれぞれ、標準的な産業用プロトコルを使用して、それぞれのオペレーティングシステム上で動作するプログラムに接続され、ネットワークを介してTCPを使用して接続されました。 これらをTCPで接続するため使用したプロトコルは、現在、私たちがDHTPと呼んでいるものに進化しました。


DHTPは当初からCogent APIにて公開されています。 その後のDataHub製品のCascade DataHubやGammaスクリプト言語、Cascade Historianなどは、Cogent APIを通じてアクセスが可能になりました。DataHub製品がOPC DataHub、そしてCogent DataHubへと発展するにつれて、より多くのコマンドが追加され、APIはWindowsで利用可能になりました。 現在、DHTPはDataHub APIDataHub コマンドセットで構成されています。


この進化過程の個々のステップは、具体的なプロジェクトのニーズ対応で、工業的背景の中で起こりました。お客様がTCPを介してより堅牢で安全なデータ通信を要求したため、SSLなどの機能を追加することでDHTPの機能を改善しました。 OPCトンネリングアプリケーションのためのCogent DataHubよりも明らかな成功はありません。 DataHub DA TunnellerとDataHub UA Tunnellerは、OPCサーバーとクライアントをネットワークまたはインターネットを介して接続する他に類を見ない製品です。


クラウドを介して産業通信の価値を認識した最初の企業の1社として、Skkynetは、DataHubからSkkyHub への接続にWebSocket機能を使い、DHTPを強化しました。 ファイアウォールポートを開かずに、双方向通信のために産業システムからの安全なアウトバウンド接続をサポートするDHTP独自の特許取得済み機能は、Skkynetのセキュア・バイ・デザインアーキテクチャがキーになっています。数年後に組み込みシステム用に ETK を導入し、この構成図が完成しました。 DHTPは現在SkkynetのIIoT製品とサービスの3つのコアコンポーネントであるDataHub、SkkyHub、ETKで使用されている標準プロトコルです。
次回のブログでは、なぜDHTPがIIoTの理想的なプロトコルであるかを詳しく説明します。効果的なIIoTデータ通信challenging基準の概要を説明し、DHTPがそれらのすべてをどのように満たしているかを示します。 DHTPの詳細については、次の点に留意してください。 DHTPについて詳細、 IIoTプロトコルとしての成功は、工場通信とインターネット通信が絡み合う厳しい環境でどのように開発されたかに起因しています。

IIoT Security: Attacks Grow More Likely, Users Unaware

A few weeks ago hackers of industrial systems reached a new milestone. For the first time in history, someone was able to break into the safety shutdown system of a critical infrastructure facility. Roaming undetected through the system for an unknown amount of time, the hackers finally got stopped when they inadvertently put some controllers into a “fail-safe” mode that shut down other processes, which alerted plant staff that something was wrong.

The danger was not just in the safety mechanisms themselves, but for the whole plant. “Compromising a safety system could let hackers shut them down in advance of attacking other parts of an industrial plant, potentially preventing operators from identifying and halting destructive attacks,” said cyber experts interviewed by Reuters.

Plan Ahead

That facility was lucky this time around. What about next time? What about the next plant? Rather than relying on luck, it is better to plan for the future. As attacks grow more likely, those systems that are secure by design, that offer zero attack surface, that are undetectable on the Internet, stand a much better chance. This has always been Skkynet’s approach, and as the threats increase, it makes more and more sense.

In fact, the industrial world is largely unprepared for these kinds of attacks. Having evolved for decades cut off from the Internet, until recently there has been little need to change. And a surprising number of users seem unwilling to acknowledge the risks. According to a recent article in ARS Technica, hundreds of companies across Europe are running a popular model of Siemens PLC (Programmable logic controller) with TCP port 102 open to the Internet. “It’s an open goal,” commented security researcher Kevin Beaumont.

Government Mandates

The situation has attracted the attention of governments, who realize the need to protect critical infrastructure for the sake of their citizens. The United Kingdom has issued a new directive authorizing regulators to inspect cyber security precautions taken by energy, transport, water and health companies, reports the BBC. The National Cyber Security Centre has published guidelines, and companies that fail to comply are liable for fines of up to 17 million pounds. “We want our essential services and infrastructure to be primed and ready to tackle cyber-attacks and be resilient against major disruption to services,” said Margot James, Minister for Digital.

IT to OT Challenges

What has brought all of this into focus over the past few years has been the increased awareness of a need for process data outside of the production facility. Companies are recognizing the value of the data in their OT (operational technology) systems, and want to integrate it into their IT systems to help cut costs and improve overall efficiency for the company as a whole. What they may not realize is that the tools of IT were not designed for the world of OT, and the security practices of OT are not adequate for the Internet.

The WannaCry virus that affected many companies worldwide last year is a case in point. Companies using VPNs to protect their IT-to-OT connections found out first-hand that a VPN merely extends the security perimeter of the plant out into an insecure world. A breach in an employee email can expose the whole plant to the threat of a shutdown. “WannaCry is the personification of why computers on the corporate networks should not be directly connected to OT networks,” according to Gartner Analyst Barika Pace in a recent report, Why IIoT Security Leaders Should Worry About Cyberattacks Like WannaCry, January 30, 2018. “It is also the reflection of the inevitable convergence of IT and OT. Based on your risk tolerance and operational process, segmentation, where possible, is still critical.”

Segment Your Systems

By segmentation, Pace means dividing networks into security zones, and maintaining security between each zone through the use of firewalls, DMZs, data diodes and other similar technologies to ensure that if one system gets hacked, it cannot affect others. Segmentation is part of a secure-by-design approach that Skkynet endorses and provides. Our software and services offer a way to connect IT and OT systems through DMZs or the cloud without opening any outbound firewall ports.

A Siemens PLC in this kind of segmented system could be accessed by authorized parties, and exchange data in both directions, without opening TCP port 102 to the Internet. Managers of critical infrastructure that implement this secure-by-design approach to segmentation are not only ready for government inspection, they have taken the best precaution against those who would intrude, hack, and attack their mission-critical systems.

As attacks on critical infrastructure become more likely, users must become aware, and prepare. The acknowledged benefits of IIoT need not entail unnecessary risk—securing an industrial system can be done, and done well. A big step is to segment your OT system though a secure-by-design approach, such as that offered by Skkynet.