Tag Archive for: Security


Don’t WannaCry on your Industrial IoT System

Pretty much anyone who has a computer or listens to the news has heard about the WannaCry virus that swept across the world a few days ago, installing itself on computers in businesses, hospitals, government agencies, and homes, encrypting hard drives and demanding ransom payments.  After scrambling to ensure that our operating systems are up-to-date and protected against this latest threat, the question soon comes up: How can we protect ourselves against similar threats in the future?

“How?” indeed.  That would seem difficult.  Our reliance on networked computers for business and personal use is fully entrenched, and business/personal PCs will remain vulnerable for the foreseeable future.  In the industrial arena, some may conclude this latest attack is yet another reason to hold off on their IoT strategy.  Or, at least: “You should use a VPN to keep it safe.”

And yet neither of these instincts is necessarily correct because (i) it is possible to build a secure Industrial IoT (“IIoT”) system, and (ii) VPN is not the way to do it.  Industrial control systems may use the same underlying operating systems as PCs but they are different in one critical aspect.  They exchange real-time control data, not files and emails.

How WannaCry Got In

WannaCry comes in two parts – an email “bomb” that exploits your anti-virus software and a “worm” that propagates throughout your network by exploiting configuration weaknesses and operating system bugs.  The special danger of WannaCry is that it can infect a computer through email even if you never open the email message.  Once WannaCry arrives through email, the worm takes over to attack the rest of the computers on your network.

The worm portion of the virus spreads itself by finding other machines on the network.  According to analysis of the code by Zammis Clark at Malwarebytes Labs, “After initializing the functionality used by the worm, two threads are created. The first thread scans hosts on the LAN. … The scanning thread tries to connect to port 445, and if so creates a new thread to try to exploit the system using MS17-010/EternalBlue.” (the bug that the virus exploits)

If there is no open port on the other computer, the virus cannot spread.  But the VPN is not much help here.  If anyone on the VPN is struck by the virus, then every machine on the LAN is exposed.  Suppose you have an IIoT system connecting a corporate office to a process control system over a VPN.  If the virus activates on any of the connected machines in the IT department, it can easily propagate itself to any of the connected machines on the industrial LAN.

How to Keep WannaCry Out

The tongue-in-cheek answer is “don’t use email”.  More seriously, industrial systems and IT systems should be separated from one another.  There is no need to read email from the industrial LAN.  Don’t install email software on your industrial computers, and don’t allow email traffic through your firewall.

But industrial systems still need to communicate their data.  How can you reach the data without exposing the industrial network?  The solution is spelled out in detail in the latest white paper from Cogent (a Skkynet company) titled: Access Your Data, Not Your Network. This paper explains why the traditional architecture of industrial systems is not suitable for secure Industrial IoT or Industrie 4.0 applications, and discusses the inherent risks of using a VPN.  But most important, it introduces the best approach for secure IIoT and Industrie 4.0, which is to provide access to industrial data without exposing the network at all.

Specifically, the Skkynet-provisioned devices and the DataHub can make outbound connections to SkkyHub without opening any firewall ports.  These connections are robust channels that support bidirectional, real-time communications for doing monitoring and supervisory control.  The WannaCry virus or anything similar cannot spread into this system because they can’t see anything to infect.  The devices on the network are completely invisible.  Skkynet’s approach provides access to the data only, not to the network.

Cyber Security: Over 90% of IIoT Experts Express Concerns

Respondents to the 2017 Industrial Internet of Things Security Survey by Tripwire paint a pretty bleak picture of cyber security for the Industrial IoT (IIoT).  Among the more than 400 IT professionals responsible for securing their companies against IIoT-related threats, 96% said they expect to see an increase in cyber attacks in the coming year.  At the same time, less than 50% of them feel prepared for those attacks.

This is cause for concern, according to David Meltzer, chief technology officer at Tripwire, who said, Industry professionals know that the Industrial Internet of Things security is a problem today. More than half of the respondents said they don’t feel prepared to detect and stop cyber attacks against IIoT.

At the same time, 90% of these same IIoT experts expect the use of IIoT to increase.  They acknowledge that innovation must go forward, and that the benefits of the IIoT outweigh the costs.  Two out of three of them recognize the need to protect against cyber attacks, despite the fact that less than half of them feel prepared for attacks on insecure IIoT devices.

The Industrial Internet of Things ultimately delivers value to organizations, and that’s why we’re seeing an increase in deployments, said Meltzer.  Security can’t be an industry of ‘no’ in the face of innovation, and businesses can’t be effective without addressing risks. The apparent contradiction of known risks and continued deployment demonstrates that security and operations need to coordinate on these issues.

Meltzer points out that the consequences of insecure IoT implementations leading to a cyber attack are far more severe for industrial applications.  Greater connectivity with operational technology (OT) exposes operational teams to the types of attacks that IT teams are used to seeing, but with even higher stakes, he said.  The concern for a cyber attack is no longer focused on loss of data, but safety and availability. Consider an energy utility as an example – cyber attacks could disrupt power supply for communities and potentially have impact to life and safety.

Here at Skkynet, we could not agree more. It was this kind of thinking that led us to develop our secure-by-design SkkyHub service. Those who understand the risks of the IIoT and the difficulty of securing it using conventional IT or OT approaches recognize the value of what we are doing. We invite every survey participant and anyone else who wants to get the most out of the IIoT to see for themselves how these concerns fall away when using an IIoT platform that is secure by design.

IIoT: Choose the right tools for the job

Note: This article was originally published in Plant Services magazine.

The American poet Carl Sandburg wrote, “They will go far and see much, and they will never be any good for sitting with the sitters and knitting with the knitters.” As true today as it was almost 100 years ago, those who sit tight and stick to their knitting rarely accomplish much. Right now in the world of manufacturing and industry, a new horizon is opening up: the industrial internet of things (IIoT). Are you curious? Do you want to go far and see how much you can do with it, or will you just sit back and knit?

Even from a distance, the benefits of the IIoT are visible. Plant Services contributing editor Sheila Kennedy highlighted many of them in August in her article Yes, IIoT can drive operational improvements. Put briefly, the IIoT offers a number of ways to optimize your system performance by providing data-driven insights into your processes. Among other things, you can see how well your assets are performing, implement predictive maintenance, simplify logistics, coordinate procurement, and drive down resource costs.

OK, you may say, that all sounds fine. Suppose I am interested. How will it work? Can the IIoT fit with my current system? How much will all of this cost? What about security? And supposing I do want to build IIoT connectivity and capabilities in my plant, how should I get started? Should our company try this on our own, or should we seek expert outside guidance or assistance?

Who builds it?

Taking the last question first, building your own system from scratch may not be the best way, according to those who have tried it. A recent Machina Research survey, “Lessons Learned from Early Adopters of the IoT,” shows that most early adopters in the IoT space who took a do-it-yourself approach found the task to be more complicated to implement than they had expected. “When asked about primary concerns around IoT, adopters have some insight that nonadopters just don’t yet have,” the report’s authors wrote. “Adopters point to ‘complexity of the IoT solution’ as the largest concern around IoT, a concern that nonadopters have yet to consider fully.”

On the other hand, if you do decide to bring in an expert, you’ll have to decide who is most qualified for the job. In her blog post “The IIoT Integrators Are Coming“, Stephanie Neil at AutomationWorld claims that control system integrators are not gearing up for the IIoT quickly enough and that SIs from the IT world are stepping in to fill the gap. They are more than happy to bring their experience implementing IoT for IT applications to the OT world. Naturally, some OT system integrators see things quite differently. They point out that it is easier for an OT company to add IoT to its portfolio than for an IoT company operating in the IT space to learn industrial process control. Jeff Miller of Avid Solutions wrote a blog post titled “We Are Ready for IIoT” to make the case that control system integrators are gearing up for the task.

The right tools for the job

Whomever you choose, an in-house team or a system integrator, you can save a lot of time and money by not reinventing the wheel. You can benefit by using tools, and you’ll want to choose the right ones. Because the IIoT looks a lot like SCADA, some may be tempted to continue using the same tools. This can be a mistake, though, because industrial data communications software was not built for the open spaces of the Internet.

Take security, for example. The IIoT presents security challenges that industrial system designers never contemplated. First, there is the obvious need to eliminate the chance of attack from outside the perimeter. But there’s also a need to protect the system and its data from inside as well. Using designed-for-IT approaches like Microsoft’s RDP or a VPN may seem like the logical choice, but Microsoft Developer Clemens Vasters raises valid concerns in a paper titled “Internet of Things: Is VPN a False Friend?” Useful as they are for the purposes for which they were designed, RDPs and VPNs give each user the keys to the kingdom – access to applications and data far beyond what they might need or what you might want them to see. The 2014 attack on Target via a VPN shows how dangerous and costly that can be.

What is needed is a secure-by-design technology that does not rely on a VPN and keeps all firewall ports closed. This can be done by making outbound-only connections to a secure cloud service. This design exposes zero attack surface and makes your system invisible to hackers. At the same time, it allows for bidirectional data communication through reverse proxies, which corporate IT departments are increasingly recommending as a standard for ensuring the security of OT systems. Needless to say, developing this kind of technology from scratch is not a project for your average plant engineering team. Instead, you can get the most out of your team and keep costs down by using a tool designed for the job.

The tool you choose should also support real-time data throughput speeds at scant milliseconds above network or Internet latencies. Ad-hoc approaches like collecting process data in an SQL database and then accessing it from the cloud will slow down your applications like a sloth at the DMV in “Zootopia.” You won’t get the response you need. Just because you may be using the Internet is no reason to compromise on speed.

And the tool should be convenient. It should fit unobtrusively and connect seamlessly with any new or existing system, with no need for programming and no dependencies. If the outside network or the Internet goes down, your primary control system should experience no effect whatsoever. The IIoT should be considered as data access or at most supervisory control. All low-level control should be completely isolated.

Start gradually

With the IIoT team assembled and tools in hand, start gradually. There is no need to tackle a huge project. Pick the low-hanging fruit. Kennedy suggests identifying functionality that is already close to the IIoT and using components that are easy to access. You may be able to connect sensors, monitors, or other devices in different locations and aggregate their data or even bridge their data sets.

A well-designed, cloud-based IIoT system does not require much upfront investment in time or money. As long as you work with a provider who offers a monthly subscription, you should be able to start a pilot project for as little as $100 per month. And if the service is reasonably complete, it should only take a few days to get up and running. Of course, you’ll need to ensure that such a system meets your specific needs, whether that means offering data archiving options, web-based HMI, access to analytics packages, or something else.

The adage “well begun is half done” applies here. If you work with a good team, choose the right tools, and start with something manageable, chances are you will succeed. Once you’ve got some initial experience, the next project can be more elaborate and ambitious, and the one after that even more so. Soon you will be going far and seeing for yourself what the IIoT can do for you and your bottom line.

Making OPC UA Secure for the Industrial IoT

Note: This article was originally published on the Automation.com website.

OPC UA was designed to be secure in an industrial environment, and it does a good job of it. In the world of Operations Technology (OT) you need reliable and secure data communications to run mission-critical systems. OPC UA provides robust connectivity, allowing your devices and machines to communicate, yet keeping them secure and locked down. But today’s OT world is expanding, being propelled into the larger, corporate world of IT, and beyond that, into the Industrial Internet of Things (IIoT) and Industrie 4.0. When connecting to IT and the IIoT, making OPC UA secure requires a new approach to meet new and different threats to security.

Securing an industrial system requires at the very least securing the perimeter against unauthorized access. Whether or not anything in the plant is connected to IT or the IIoT, this perimeter must remain intact for optimal security. In the past, perimeter protection was often accomplished by air-gapping, where the industrial network was physically isolated from any other network connection. Until recently, this approach or similar solutions like DMZs were sufficient. But these make it difficult if not impossible to share OT data with the company’s own IT department, much less on the IIoT. The challenge is to fully protect the perimeter, and yet still provide access to the data from OPC UA servers inside.

Are VPNs secure enough?

Accessing OPC UA servers or any other industrial system from the IIoT should be done through a secure network connection. The typical approach, one that many take for granted, is to use a VPN (Virtual Private Network). VPN technology is well known, having been used for decades in the IT world. In essence, a VPN provides an outside user with a log-in to the network, and establishes a secure tunnel through the Internet to allow access to the system―the entire system. And that can lead to problems.

While OPC UA can work over a VPN, that doesn’t guarantee robust security. VPNs were not designed for use with industrial process control systems. In fact, they can open vulnerabilities even in the IT world. The attack on Target stores in North America that cost the company millions of dollars was perpetrated through a VPN. Hackers got hold of a user name and password, and gained access to the system. Once in, they quickly found their way to customer records and credit card numbers, and had a field day. The problem with using a VPN to access an industrial system is not only that every VPN user account is a potential access point, but that once someone is inside the perimeter they gain access to the whole system.

The drawbacks of using a VPN for the IoT are examined in detail by Clemens Vasters, a Microsoft Developer. In a paper titled Internet of Things: Is VPN a False Friend? Vasters said, “VPN provides a virtualized and private (isolated) network space. The secure tunnels are a mechanism to achieve an appropriately protected path into that space, but the space per-se is not secured, at all. It is indeed a feature that the established VPN space is fully transparent to all protocol and traffic above the link layer.”

Using Reverse Proxies

Forward-thinking people who are working on the IIoT recognize this inherent risk in using VPNs. Many IT departments now require reverse proxies for OT systems to mask all internal servers and expose just one server to the Internet. But this approach does not secure OPC UA for the IIoT.

OPC UA clients can connect through reverse proxies using HTTP, but not HTTPS due to certificate handling. The proxy will either require opening a new firewall port, or effectively create a path to the control system that could easily be overlooked in the future. Either way an attack surface gets opened in the corporate perimeter. Furthermore, even if the message itself is encrypted, the message headers are exposed to outside observers. The only alternatives involve effectively tunneling through the proxy directly to the control system, which is what the proxy is trying to prevent.

The bottom line is that a reverse proxy is an improvement over a VPN, but it still requires a point of access into the control system from the Internet or IT network. Any point of access is an attack surface, and even if the server code is bulletproof it is still a candidate for a spear-phishing compromise.

Push Instead of Pull

The best way to completely close the plant perimeter is to eliminate all inbound connections, allowing only outbound connections. This is a good idea in principle, as it does not expose the plant to attack. The system presents zero attack surface, becoming invisible to hackers who cannot attack what they cannot see.

However, outbound connections run afoul of traditional design expectations. Effectively they turn the paradigm of industrial data communications on its head. Most client/server architectures, including OPC UA, assume that the server holds the data and the client initiates a connection to interact with it. The server is the authority on the data set, while the client is the non-authoritative user. Thus, in the OPC UA world-view the server must be situated with the primary data source, inside the control system.

To make a push design work in the IIoT, the server/client relationship must be reversed. The client must be the authority (inside the control system), and the server must be a non-authoritative receiver of the data. The client must be able to construct the data set on the server on the fly, based on its knowledge of the control system. This reversal of the client/server roles is something that OPC UA cannot accomplish on its own, but can be added through appropriate gateway software.

Using Forward Proxies

Using a push mechanism allows both OT and IT to completely close the network perimeter. If there is no way to make a connection from outside the network then there is no attack surface to exploit and there is no user to fool into revealing his password.

But even a closed perimeter is not sufficient. Best practice in IT networks is to route outgoing web traffic through a forward proxy, and to deny all other network traffic to the Internet. This substantially improves security by effectively shielding the internal network from a direct Internet connection. To be robust and IT-compliant the outbound IIoT connection must be able to pass through a standard forward proxy. Although OPC UA doesn’t inherently support forward proxies, appropriate gateway software can once again add this capability.

Secure by Design

The Chatham House Report, Cyber Security at Civil Nuclear Facilities Understanding the Risks, points out an alarming lack of security at some of the most critical infrastructure installations in the world, and makes a number of design recommendations. At one point it states, “Many industrial control systems are insecure by design, since cyber security measures were not designed in from the beginning.” And this does not just apply to nuclear facilities. Indeed, the “many industrial systems” may well include those which now or soon might incorporate OPC UA. And they require a new approach, a new design for security on the IIoT.

The new design approach must allow OPC UA clients from any location to connect and acquire data from OPC UA servers within the plant perimeter, to eliminate the need for reverse proxies and VPNs and to avoid opening any inbound firewall ports. At the same time, to fully support OPC UA’s real-time data access, the design must support bi-directional data communication between OT and IT systems and across the Internet at speeds very close to network propagation times. Secure-by-design for the IIoT should take a no-compromise approach, offering the best possible combination of speed, security, and convenience.

With this level of security, and near-real-time speeds, there is one more design consideration: practicality. To gain traction among users, the design should be convenient to implement. It should, for example, allow for seamless integration with legacy installations using OPC Classic and other industrial protocols, as well as newer OPC UA-enabled systems. It should provide a loose coupling to the IIoT, one that allows remote, authorized and secure access the data, optionally including supervisory control, but that has no impact on the primary control system if it gets disconnected. And it should be easy enough to implement that it doesn’t overly tax the time or resources of the system integrator or plant engineer who is implementing it.

This is the kind of design that is needed to secure the IIoT, and make it compatible with today’s factory or process. OPC UA is the industrial protocol of the present, and of the future. It has the ability to integrate plant data from virtually any machine or device, large or small, as well as to bring the disparate worlds of OT and IT together. When OPC UA is wedded to the appropriate, secure-by-design IoT technology, it will play a key role in Industrie 4.0 and IIoT applications.

Cybersecurity Top Concern for Oil and Gas Sector

Among the growing concerns about cybersecurity and the IoT, the industrial sector stands out.  Industrial IoT applications are in some ways more at risk than others.  Control networks traditionally safeguarded through complete isolation are now seen as sources for valuable data for companies to tap.  But connecting plant data to outside networks or the Internet must be done securely.  The consequences of a hack can cost thousands or millions of dollars, and possible loss of life.  Nowhere is this more evident than in the oil and gas sector.

In a recent report, Countering the Threat of Cyberattacks in Oil and Gas, the Boston Consulting Group (BCG) enumerates the concerns in that sector for cybersecurity.  They pointed in particular to upstream systems, such as remote data acquisition systems, gateways, transmission bridges, and controllers in exploratory rigs and drilling control systems.  This equipment and these networks are spread across vast areas, and are responsible for tracking and controlling the extraction and production of the oil and gas resources in the field.  Once considered too remote to worry about, as these systems come online, they should be considered possible targets for an attack.

“Until recently, the industry considered the traditional upstream systems in the oil and gas sector to be relatively safe because they were, in most cases, isolated,” the report said.  “But the industry’s growing use of connected industrial systems and networking technology—coupled with the ever-increasing need for real-time data and analytics—has introduced new risks.”

The BCG report outlines several specific areas of risk, and recommends a number of steps for CIOs and other executives to take.  These fall into three categories:

  • Boundary protection – The exploding popularity of mobile devices has driven operators and others to request or expect the same convenience they get at home or anywhere else in the world at their workplace.  Each device adds to the potential attack surface.  Wherever possible, remote users in the oil and gas sector should be given access to the data only, and not to the control system itself.
  • Remote access – This is essential to monitoring and controlling a wide-spread enterprise like oil and gas production.  Strong control over remote access points includes both physical access and software-based safeguards.  On the software side, we would recommend a secure-by-design, outbound-only architecture wherever possible for remote equipment or devices.
  • Information flows – If a malicious agent is able to interrupt, alter, or redirect the flow of information through the system, it could cause significant problems.  Firewalls, reverse proxies, DMZ technology and hardware solutions like data diodes can reduce or eliminate unauthorized access, while employing network-monitoring equipment and network-use rules can help identify any intrusions that do occur.

In all of these, there are both human and technical factors.  On the human side, operators and managers need to be trained and supervised to ensure that they are keeping security as a top priority, and adhering to the relevant policies.  The technology, for its part, should support those efforts by being as convenient and unobtrusive as possible, while still providing the highest possible level of security.

The BCG report concludes, “To protect themselves, their shareholders, and their customers adequately, industry players must make cybersecurity a highest priority and an ongoing consideration at the executive level.”  We agree.  And we would add that starting from there, this attitude should spread throughout the organization, and be present in each of its members, and the tools they use.

Recent IoT Attack on Dyn Calls for Secure By Design

The recent denial of service attack on Dyn, a DNS service company for a huge chunk of the Internet, sure woke up a lot of people.  Somehow when it happens to you, you tend to feel it more.  Twitter, Netflix, Reddit, eBay, and Paypal users certainly felt it when they couldn’t access those sites.  Now that most of us are awake, what can we do about it?

In the short term, not a lot, apparently.  In a recent article about the attack titled Vulnerability Is the Internet’s Original Sin, Internet security expert and author of Dark Territory: The Secret History of Cyber War, Fred Kaplan points out that from the beginning the costs and challenges of designing security into the Internet from the ground up was considered too challenging and costly.

Kaplan tells how, back in 1967, Willis Ware, the head of the Rand Corporation’s computer science department and a NSA scientific advisory board member, wrote a paper warning the ARPANET team and others that “once you put information on a network—once you make it accessible online from multiple, unsecure locations—you create inherent vulnerabilities … You won’t be able to keep secrets anymore.”

The Dyn attack was simple in concept and easy to execute.  The devices used were accessible household appliances and electronics, configured out of the box with simple default user names and passwords like “username”, “password”, and “12345”.  The virus cycled through these default credentials to recruit thousands of devices into a giant collective, which was then coordinated to flood Dyn with traffic.

To prevent this kind of hack, device manufacturers may start updating their devices to ensure more secure usernames and passwords.  But that ignores the elephant in the room.  The fundamental problem is that these IoT devices are available (they are always on, ready to communicate over the internet), they are accessible (they can be seen on the internet), and they are numerous (with numbers growing exponentially).  This combination of availability and accessibility, multiplied by the huge numbers, makes IoT devices perfect for coordinated attacks.  We can be sure that the bad actors are already working hard on defeating username/password protection on IoT devices.

Considering the first of these three critical factors, IoT functionality requires that IoT devices are available for communication.  There is not a lot we can do about availability.  Secondly, the business opportunities and economic promise make device proliferation unstoppable.  We have to expect continued rapid growth.  But we can do something about the third critical factor: accessibility.

No IoT device should be sitting on the Internet with one or more open ports, waiting for something to connect to it.  The device can and should be invisible to incoming probes and requests to connect.  A hacker or bot should not even see the device, let alone be given the chance to try a username or password.  That technology exists, is easy and inexpensive to implement, and has been proven in thousands of industrial installations for over a decade.  Governments and manufacturers need to be employing it across the full range of IoT applications.