Software Toolbox Technical Blog

With the rising security demands of Industry 4.0, OPC UA provides us with the means to encrypt data as it is transferred between client and server. But what if encrypting data to prevent outside extraction is not enough? What if UA client applications become compromised? What tools do we have to protect against deliberate or even accidental manipulation or consumption of data?

Continuing our Tech Support Corner blog series, this post covers how to leverage the built-in TOP Server User Group Security settings, alongside OPC UA username and password authentication, for greater control over which users have read/write capabilities as well as what tags a user is permitted to access.

So far in our ongoing Exploring OPC UA blog series, we have taken a primarily general look at OPC UA Certificates and how they are used by OPC UA clients and OPC UA servers to keep industrial data secure.

In this third post of the series, we'll take a step back and look at OPC UA security in general with respect to the layered approach that is employed to cover aspects such as authentication, confidentiality and the integrity of communications.

It can be tricky in this era of increasing cross-connectivity of anything and everything, from a lowly household appliance to IT/OT hybrid systems applying predictive analytics to an industrial process, to balance connectivity everywhere and the required security to mitigate cyber threats.  In the past, remote access to industrial process data often required network access to the actual HMI or SCADA system on the process network.  But why do you need network access to your SCADA system, when all you really need is just to access the data?

In this blog post, we'll discuss a few of the key benefits to having remote access to your industrial process data, which can be essential to making timely business decisions and discuss a flexible solution for enabling remote access without exposing your industrial process network to outside threats, including how to sign up for a free account for a limited time.

In the first post of our ongoing Exploring OPC UA blog series, we covered the three functions that OPC UA Certificates (also known as Application Certificates) serve in the context of OPC UA security.

In this second post, we'll take a look at what happens to messages after you have trusted the application certificates and have enabled security on the OPC UA endpoint. Specifically, what does Sign&Encrypt mean on an endpoint and how can we be sure that the data is truly secure.

The use of certificates in cryptographic applications and online communication protocols is nothing new and can practically be traced all the way back to the 1970's when the "framework" for public key encryption (more on this in a future blog) came into being. With the (now-not-so-recent) Industry 4.0 movement coming out of Europe, and the design and operation changes brought about by the IIoT phenomenon, we are seeing more and more systems – that have traditionally been air-gapped and kept offline – being brought online to take advantage of the digital revolution in which we find ourselves.

Despite how you feel about this (r)evolution there are several exciting changes that are being brought about, including the one I want to discuss is the increased adoption of OPC Unified Architecture (OPC UA) in automation systems.

In this first post in our ongoing Exploring OPC UA blog series, we will look at what OPC UA Certificates are and what they provide and subsequent posts will further explore how they are used in OPC UA, how they fit into the security ‘stack’ of OPC UA and will then look at how OPC UA Certificates are utilized and managed in several Software Toolbox applications. First thing’s first however; what are OPC UA Certificates and what are they used for?

While Cogent DataHub is, of course, primarily known for its extensive connectivity interfaces, just as important is how you, the user, are able to intuitively use and configure the functions in DataHub, both locally and remotely.

In this first blog post of a detailed series on specific DataHub Version 9 features, I'll provide insight into the new Remote Configuration capabilities and show you how Cogent DataHub V9 provides a secure, reliable and easy-to-use configuration experience locally and remotely.

Cogent DataHub is known for its extensive connectivity to OPC DA, OPC UA, OPC A&E, Databases, Excel, ODBC, DDE, Linux, Modbus.  The new V9 takes our saying that "once the data is in DataHub, it can go anywhere" to a new level with IoT connectors and more as listed below.

In this blog post, I'll provide insight into these new features and show you how Cogent DataHub delivers secure, scalable, integrated connections within and between your plants, to the cloud and beyond.

OPC has been around as an industry standard since 1996.  If you’ve been working in the space very long, you have probably heard all the different acronyms thrown around.  If you’re new, well there are different specifications in the OPC software interoperability standards that are used to meet different information integration needs.

In this first post of our “I Can Do That?” blog series, I’ll explore examples of the connections between different OPC standards we hear about from users, ways to address them using OPC Gateway software, and use cases highlighting solutions we’ve seen other users implement successfully.

By now, I’m sure you’re aware of the Cogent DataHub v8 release.  Since announcing the release date, we have had many good questions from existing users like you.

This blog post will address the most common questions we have received and provide the answers you need to plan your DataHub V8 migration.

You may have heard about the upcoming release of Cogent DataHub Version 8 on March 1.  The new features in Version 8 are focused on enabling the Cogent DataHub to deliver high-quality data communication – secure, fast, and fully integrated within the plant and beyond.

In this blog post, to give you a bit more insight into what you can expect, I will provide further details on each of the new features.

Complications of Domains, Workgroups, & Mixed Windows Versions & Solutions

In the Operations Technology or OT world that most of our users live in, it’s normal to have multiple versions of Windows and systems that may not always be setup consistently but we have to make it all work anyway.   Connecting OPC clients and servers when the Windows computers are not on the same version, not in an Active Directory or, using older terminology, a domain, and having everything work well takes skill, and keeping it secure involves a lot of details.

In this blog post, our team asked me to explore with you the details involved to assist you with better understanding Windows Security and to converse more productively with your IT Team.  I’ll also share how you can learn more about how to make things easier on yourself through the use of OPC UA or with Tunneling.

The more regulated your industry, the more likely it is that you have a cybersecurity team that is extremely vigilant about gaps in security.  Traditionally, remote OPC tunneling has generally always required that network firewalls have at least one port open for data transfers to work successfully.

But what if you work in one of these highly regulated industries and your IT/cybersecurity department won't allow you to open any firewall ports for remote data sharing?

This blog post will discuss why it's important for a tunneler solution to support alternatives to the traditional methods of tunneling with open firewall ports to ensure network integrity.