Posts

Secure IoT Gateway Architecture

An enhanced, secure-by-design OPC UA to MQTT gateway can pass data through a DMZ or IT department, keeping all inbound firewall ports on the plant closed.

Skkynet Opens OPC UA Lab in Yokohama

Hardware and software vendors and users now have a facility for testing OPC UA products.

Mississauga, Ontario, July 12, 2018 – Skkynet Cloud Systems, Inc. (“Skkynet” or “the Company”) (OTCQB: SKKY), a global leader in real-time cloud information systems, announces the opening of the Skkynet UA Lab in Yokohama, Japan.  Working in close cooperation with Skkynet partner BellChild and OPC development company Puerto Co., the Skkynet UA Lab will provide testing, development, and advisory services for users and vendors of OPC UA-enabled hardware and software.

“We are pleased to offer this center of excellence to the OPC UA community in Japan and worldwide,” said Paul Thomas, President of Skkynet.  “OPC UA is a robust and secure industrial protocol, and we expect to see a steady increase in implementations.”

The Skkynet UA Lab offers three kinds of support for its clients.  For developers who need to test OPC UA projects, the UA Lab provides powerful OPC UA servers with a large assortment of evaluation software.  For vendors who have a product on the market, the UA Lab offers an interoperability test environment, allowing each vendor’s product to connect with and test against all other vendors’ products.  In addition to these, the UA Lab has inaugurated its Worldwide OPC UA Network DEvelopment and Research (WONDER) program to test various ways of connecting OPC UA.  These include testing on untrusted networks using push technologies, utilzing proxy-enabled DMZs, tunnelling through firewalls, and incorporating the OPC UA Pub/Sub specification when those implementations become available.

“OPC UA is a sophisticated protocol, demanding much attention to detail,” said Minoru Yamazaki, advisor to Skkynet Japan and project organizer.  “Real-world experience is the ultimate evaluation criteria, and we are grateful for the support we have been receiving from a number of OPC UA product distributors, including MOXA, Contec, Comtrol, and Hi-Flying, as well as BellChild, and Puerto.”

Skkynet’s DataHub middleware, SkkyHub service, and ETK provide secure access to industrial data through OPC UA and other protocols, allowing users to fully integrate OT (operations technology) with IT systems and other applications anywhere in the world. Secure by design, it requires no VPN, no open firewall ports, no special programming, and no additional hardware. Secure integration of embedded devices, on-premise systems, and remote locations through seamless, end-to-end connectivity in real time lets users derive maximum value from Industrial IoT and Industrie 4.0.

About Skkynet

Skkynet Cloud Systems, Inc. (OTCQB: SKKY) is a global leader in real-time cloud information systems. The Skkynet Connected Systems platform includes the award-winning SkkyHub™ service, DataHub®, WebView™, and Embedded Toolkit (ETK) software. The platform enables real-time data connectivity for industrial, embedded, and financial systems, with no programming required. Skkynet’s platform is uniquely positioned for the “Internet of Things” and “Industry 4.0” because unlike the traditional approach for networked systems, SkkyHub is secure-by-design. For more information, see https://skkynet.com.

Safe Harbor

This news release contains “forward-looking statements” as that term is defined in the United States Securities Act of 1933, as amended and the Securities Exchange Act of 1934, as amended. Statements in this press release that are not purely historical are forward-looking statements, including beliefs, plans, expectations or intentions regarding the future, and results of new business opportunities. Actual results could differ from those projected in any forward-looking statements due to numerous factors, such as the inherent uncertainties associated with new business opportunities and development stage companies. Skkynet assumes no obligation to update the forward-looking statements. Although Skkynet believes that any beliefs, plans, expectations and intentions contained in this press release are reasonable, there can be no assurance that they will prove to be accurate. Investors should refer to the risk factors disclosure outlined in Skkynet’s annual report on Form 10-K for the most recent fiscal year, quarterly reports on Form 10-Q and other periodic reports filed from time-to-time with the U.S. Securities and Exchange Commission.

Considering Prefab

An uncle of mine was an entrepreneur and quite a do-it-yourselfer.  His main businesses included a restaurant and a propane gas distributorship, but he was a real hands-on kind of guy, and spent a few summers building a cottage on Seneca Lake in Upstate New York.  It was an ongoing project, always in a state of “finishing.”

The first stage, a small one-story, was mostly done, with panelled living room and functional kitchen, although some of the bedrooms in the back were unfinished—partially drywalled with exposed plumbing and electrical.  The next stage was planned as a large two-car garage to be capped by a second story master bedroom and office with large glass doors and picture windows overlooking the lake.

That was the plan, anyway.  The reality was that his various businesses and other interests intervened.  For the several summers that my brother and I worked with and for him, the garage was his workshop, while progress on the second story proceeded in fits and starts.  A year or two after I’d moved away from the area, it was a heartbreak to find out that the cottage had caught fire and burned to the ground,  due to a short-circuit in the wiring.  Nothing useful was left but the original concrete slab.

I never got to see that cottage completed.  But my uncle was not deterred.  He rebuilt, prefab.  In a few weeks he had a very nice two-story cottage, with a two car garage and great views of the lake from picture windows on both stories.  Rather than wasting his time framing rooms, running wiring, joining pipes and hanging sheetrock, he was out on the water sailing, or cooking up a barbeque with his cousins and family.

The lesson for me?  Sure, maybe you can do it all yourself.  But should you?  It could take more time than you expect, and the results may not be what you were hoping for.  Sometimes it’s best to leave the tedious, difficult, and specialized work to the experts, and focus on what brings the most value, or the most fun.

As we explained in a recent article published in Automation.com, this is the principle behind working with Skkynet’s ETK, and its OPC UA framework, rather than a software development kit (SDK).  Using an SDK can take an expert programmer 12 to 18 months to build an OPC UA server.  Meanwhile, a developer who uses the ETK gets a pre-built OPC UA server, and can focus on his or her applications.

Some people, like my uncle, seem to enjoy doing it themselves.  They rise to the challenge, and given enough time they can succeed.  And then there’s the prefab option: buy, install, and run.  The grunt work is done.  Drop your hammer and rig the sailboat.  That’s the benefit of the ETK’s OPC UA framework—the difficult and boring work is done, so the developer can focus on what he or she knows and does best.

Need to Speed Up OPC UA Development? Use a Framework

Developers who want to put OPC UA on an embedded device typically use an SDK (Sofware Development Kit) to speed up the project. Although an SDK can be helpful, using one to build an OPC UA server is still a big task, typically taking 12 to 18 months for an expert in OPC. Thankfully, there is another approach—use a framework. This article explains the three main advantages of using a framework:

  1. It resolves protocol blocking, a challenging obstacle to development .
  2. It can convert the OPC UA to the protocol the device may be using.
  3. You don’t need to learn OPC UA.

Using a framework (like the one provided by Skkynet’s ETK) allows a developer to bridge between the application logic and the OPC UA protocol and speed up development time.

The Kaspersky Report: It’s Not Really About OPC UA

Automation.com, a leading online publisher of automation-related content, recently ran a commentary on a new report from Kaspersky Labs about OPC UA. The Kaspersky report identified 17 critical security flaws in OPC UA software. But although the Kaspersky methodology may be sound, the commentary in Automation.com suggested caution in drawing conclusions.

It turns out that the flaws noted by Kaspersky were simply because an OPC UA must listen for connections on a network, just like any other server on a TCP/IP network. The real problem is deeper, according to the commentary. Put simply, the standard approach to industrial data communications is not suitable for untrusted networks like the Internet. A better solution is not to allow any inbound connections at all.

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 see 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 Automation.com website.