- By Michael Clark
- June 11, 2020
- OPC Foundation
Learn from an interview with Darek Kominek of Matrikon about the concepts of built-in security, the IT-OT gap, protecting against hacker/malware attacks, and many other features that have made OPC UA the secure data-exchange standard it is today. his is the third in the series of OPC Experts Interviews.
The OPC Experts Interviews is a series taking a deep dive into open platform communications, OPC/OPC UA and related technology. In this interview with Darek Kominek of Matrikon, you will learn about the concepts of built-in security, the IT-OT gap, protecting against hacker/malware attacks, and features that make OPC UA a secure data-exchange standard.
Darek, please introduce yourself to our readers: Tell us a bit about yourself, your company, Matrikon, and your involvement with the OPC Foundation.
Kominek: My background is in computer engineering. I did software development for the first ten years of my career before shifting into marketing and product management.
I’ve been with Matrikon for sixteen years. As their marketing director, I look after strategic marketing and product positioning activities. I also run the technical solutions consulting group, which assists our direct and partner sales channels who work with OPC-based solutions. I also run an equal partner program that deals with our partners who use the Matrikon Flex OPC UA SDK.
Outside of Matrikon, I'm a member of the OPC Foundation’s Marketing Control Board. There, I get to take part in shaping the OPC Foundation brand and working with OPC UA. I enjoy seeing all of the exciting initiatives that are being undertaken around the world.
Security is a big topic nowadays; what role does OPC UA play in it? What does OPC UA help protect?
Kominek: Great question. We hear in the news all kinds of things that are happening around the world – all kinds of threats that we have to deal with, including threats against network communications. Since everybody is relying on networks, there's a lot more that’s threatened. When we talk about industrial automation – whether it's the excitement of Industrie 4.0 in Europe, or the Industrial Internet of Things [IIoT] – everything is based on the information that's coming from the underlying data sources. OPC UA is right in the sweet-spot of this topic, because it focuses on moving data from point-A to point-B.
When talking about security and what happens with data, data is basically in three states:
The first state is data-at-rest. This includes storing it in databases, historians, or within a device.
The second state is data-in-process. This describes data as it’s being used.
And, lastly, is the concept of data-in-motion. This is the event of transferring data.
OPC UA focuses primarily on the third state, data-in-motion. It looks at data holistically, not just how data may be encrypted as it moves across the wire, but also, who should have access to the information, and what they are permitted to do with it.
What does OPC UA protect? Well, all industrial data – starting from sources at the lowest levels of the shop floor, all the way up to data stores within cloud applications.
It is said that OPC UA has “built-in” security. What does that mean?
Kominek: That's an essential ingredient within OPC UA; it was built secure-by-design from the ground up. Its security aspects are based on lessons learned over the past twenty-plus years. One key principal, that OPC Foundation realized, is that the goal is not just about connectivity; security is an integral part of the mission. This is especially true in an industry in which IT departments are trying to protect their networks, while OT guys are trying to keep their plants running. The path forward has to include the best IT practices built into OT standards for communications. Of note, based on these objectives, the OPC UA standard has fourteen core parts; of those, six are directly influenced by security principals.
How well-suited is OPC UA for Industrial IoT, also called Industrie 4.0? Does OPC UA address the IT-OT gap, as far as security is concerned?
Kominek: Absolutely! The OPC Foundation didn't invent how it bridges IT and OT. Instead, it leverages best practices from both disciplines to provide end-to-end security, ensuring we know where the data originated and where it’s going.
OPC UA security incorporates know-how from other groups. For example, the NSA [National Security Agency], and their concept of defence-in-depth, ensures there are multiple layers of security so that users aren’t simply depending on one gate. It's kind of like a castle structure comprised of multiple moats and walls. Another example is NIST [National Institute of Standards and Technology], when dealing with algorithms. Even though encryption may be solid today, things continue to evolve. Certain departments are monitoring which algorithms are starting to become vulnerable or no longer effective.
Since OPC UA has the ability to continue to evolve, it's not tied to any particular technology; it's more global in its scope. Whether we’re talking about small microprocessors – things that don't even have operating systems onboard – or large servers and cloud-based systems, each has the ability to use certificates. This includes some of the latest advancements in role-based security, which makes it easier to minimize the headaches of configuring a secure system. The list goes on, and all of these best practices have been built into the OPC UA standard.
Let’s get into a bit more detail. What are some key security concepts?
Kominek: The topic of security is so huge that people are sometimes overwhelmed by the breadth of things one must know. Since OPC UA limits its scope to data transfer – the data-in-motion aspect to which I referred earlier – I would suggest we talk about the broader concept of trustworthiness.So, what are the aspects that make communications trustworthy? There are seven general security principles which neatly breakdown into three categories. The first category has three aspects called the triple “A” of security – Authentication, Authorization, and Auditability.
- Authentication is what is used to confirm that device-A is really A and that device-B is really B when communicating between A and B. This is where PKI (Public Key Infrastructure) is used to establish trust between the two entities, or applications, that intend to communicate with one another.
- Authorization deals with who is allowed to do things with the data once they've been authenticated on a system.
- And lastly, Auditability is the ability to trace what actually happened. For example, if you're doing a post mortem analysis, you can see who made which requests, when they were made, and from where.
The next set of security principles is the CIA triad, which stands for Confidentiality, Integrity, and Availability with respect to data.
- Confidentiality deals with keeping the information sent between entities private.
- Integrity means that the data is not being changed.
- Availability is ensuring that communications stay online as much as possible.
The final aspect of security is called Nonrepudiation. By signing transmitted data, recipients are assured of the integrity and origin of the data and that it is not spoofed.
How do users know which security functions are implemented in a given product?
Kominek: If the product is OPC UA enabled, users will recognize that the OPC UA server exposes endpoints to which clients can establish secure connections. When we talk about endpoints, an OPC client, seeking to establish a connection with an OPC UA server, will see, within that server, a list of which security mechanisms are available for establishing such connections.
You mentioned endpoints. Can you share some examples of endpoints with our readers?
Kominek: For those who are familiar with security concepts, they may know some of the names that are used to identify various algorithms and security systems, but for others it might sound a bit more cryptic. The endpoints that a server might expose may include encryption like AES-128, SHA-256, AES-256 and so on. These endpoints reflect various security policies that a server can implement.
Just to give some insight, we could compare this to a menu board at a drive-thru restaurant. You can either openly choose those things you want to eat and drink from the entire menu or you might, instead, order a combo meal – Combo 1 or Combo 2. Compare this to security policies in OPC UA servers; they combine – or create a combo – of different types of algorithms and exchanges that can be established between a client and a server to mutually prove their identity. Next, it’s necessary to establish the encryption standards of how clients and servers are going to sign messages; how they are going to encrypt and subsequently decrypt the data.
This combo of different algorithms, used to create tokens and hashing values, comes together under what is called a security policy. Endpoints are what expose these combinations. It ultimately comes down to whether you choose to sign the data, encrypt it, or to do both. The worst-case scenario is to do neither of them – something called none-none – neither signing nor encrypting the data. Obviously, this is the least secure implementation.
How do users know which endpoints are available in a given OPC UA Server?
Kominek: When a user begins to establish a connection from an OPC UA client, the server will advise the client of its available endpoints – it will advertise it. The user can then choose which of those features (endpoints) they want to use. Of course, the vendor documentation will specify which security options are available in the OPC UA server.
How does OPC UA protect against common hacker or malware attacks?
Kominek: There are ten common attack types; each one attempts to breach the security features I mentioned earlier. I’ll give a few examples:
Message flooding is a denial of service (DoS) attack. This kind of attack tries to affect “availability”, as defined in the CIA triad. OPC UA servers combat this by processing incoming packets as minimally as necessary. If information in the packet doesn't immediately align, the server simply drops it. It doesn't try to recover the data, try to figure it out, or try to have further exchanges with that client – it just drops it. This feature minimizes OPC UA server processing, which preserves the resilience of the server.
Another type of attack is message spoofing or, in other words, forging of messages. This is sometimes called a man-in-the-middle attack, wherein messages are manipulated to appear as though they are authentic, when in reality, they're not. Since OPC UA packets utilize encryption, certificates, embedded Session ID’s, and Channel ID’s, fake messages have a snowballs chance in hell of actually making it through – so long as you’ve chosen to apply these security measures.
Message alteration, or replay, is another way in which hackers try to take a valid message and attempt to replay it a number of times. Imagine if this message was a command to activate a valve positioner. If permitted to pass, it could have disastrous effects. OPC UA session ID’s, channel ID’s, timestamp sequence numbers, request IDs, and so forth, all take these things into account, thus preventing replaying of messages.
Lastly, the most obvious breach, is eavesdropping. By using data encryption, OPC UA removes that possibility. The list of preventative measures goes on, but those are a few effective examples.
Does every OPC UA enabled product have to implement all security profiles?
Kominek: No, it’s not necessary. For the OPC UA standards to be applicable, it was necessary to define specific profiles for servers with differing capabilities – profiles like nano, micro, embedded profiles, and standard profiles. Usually, the compute power will be proportional to the complexity of what is being processed by a particular subcomponent.
If you have something so small that it can't run a full implementation of OPC UA security, then reflect back to the idea of defence-in-depth. Steps must be taken to ensure that IT (or OT) personnel properly isolate these devices, mitigating risk by using other protection methods around the components that don’t utilize a full implementation of OPC UA security policies.
Does implementing OPC UA security make a product secure?
Kominek: That's a very important question and I hope the vendors pay as much attention to my answer as the end users.
If you implement OPC UA security correctly, yes, it is effective, but it is extremely important that vendors properly implement additional aspects of the product. Let me illustrate:
OPC UA uses certificates to establish trust among peer components. Imagine if a product was to store its root certificate in an unprotected area, somewhere onboard the product. Even if this product had properly deployed OPC UA security features, if the product’s network presence is compromised in a way in which someone gains access to those root certificates, the security of that product is then jeopardized.
It is so important that manufacturers take a holistic view when building their products. Furthermore, end-user administrators must properly configure their systems and supporting networks.
Can you share any empirical evidence about the built-in security of OPC UA?
Kominek: Yes. The OPC Foundation has certainly performed testing within its own laboratories, but an example of a more in-depth examination was completed by the German government.
BSI, The Federal Office for Information Security, in Germany, has the obligation to systematically test available standards in support of the Industrie 4.0 initiative. They hired a third-party company to perform thorough testing, which included proofs and implementation validation. OPC UA did very well, passing their rigorous testing. This brought a great boost of confidence to the industry.
Furthermore, testing has been done in other countries. For example, OPC UA is one of China's national standards, which has been woven into their Made in China 2025 initiative.
Security is a cat-and-mouse game between hackers and the security community. How does OPC UA keep up?
Kominek: It is definitely a never-ending story. The layered approach of defining OPC UA, with its service architecture bridging different layers, was designed to account for continuous evolution. This means that you can continue to use what you have currently implemented, but, when the next product version comes out, it may be necessary to update some of the onboard security features.
For example, encryption algorithms may require updating. The OPC UA specification follows NIST guidelines which recommend expiration dates for various algorithms. OPC UA has already deprecated some of these algorithms.
What information sources can you suggest for those who want to learn more about the practical implementation of OPC UA security?
Kominek: One of the best places to start is the OPC Foundation website. Among the many resources here, you’ll find a brochure that describes how to securely deploy OPC UA. There's also a Wikipedia page about OPC UA security, directly accessible from the OPC Foundation website. Furthermore, you can always refer to the OPC UA standards themselves, free of charge. OPC Members can also preview items that are in-progress. I think these would all be great starting points.
- Article adapted from an interview conducted by Peter SeebergLearn More
Did you enjoy this great article?
Check out our free e-newsletters to read more great articles..Subscribe