This is the fourth part in a series. Previous parts can be found here and here and here.
We're coming near the end of this series, and in this blog will tackle the fifth device class:
I also have to admit - and I guess that goes for most with an information security background - this is the class most unfamiliar to me. Unfortunately, it is also the device class that is likely most critical, as messages exchanged between the IT and OT (the industrial) network layer can actually have dramatic effect. Whereas most devices in class 1 through 4 will read data, and maybe run some analytics or data processing on that data, Industrial Control Systems (ICS, of which SCADA - Supervisory Control And Data Acquisition systems - are a large subset) by design and by nature operate in the real world: these are the systems that control critical infrastructures like energy generation, transportation systems, oil refineries and chemical plants, manufacturing factories, etc. When we are talking about big adverse effects in IIoT, this is really what we're talking about.
Meanwhile, the promise of IIoT is exactly in optimizing and automating such processes. Given the past of SAP, a future of "ERP-driven manufacturing" in which the orders present in an SAP system drives production is an obvious high value use case.Will Predictive Maintenance seems to be the initial "killer app" of IIoT, such optimized production certainly is one of the key promises of IIoT.
At the same time, though, we're starting from a baseline that from a security perspective makes me worried. These networks operate with safety and reliability as primary concern, don't really use encryption today for communication or integrity, and communicate over proprietary protocols. Older Programmable Logic Controllors (PLC) often run on Windows XP, an OS notorious for its security problems. The end of support for Windows XP caused consternation in the industrial world just a few years ago, leading to articles such as this. Network segmentation within such OT networks is rare to non-existent. And while there is ideally a strong separation between the IT and OT networks (so-called "airgapping") currently, IIoT is all about bridging that IT and OT divide. Rightly so, "Industrial Internet of Things" raises a good number of security concerns.
So, let's look at the threat model for this class:
Connectivity between the IT and OT layer typically is some sort of secure communication channel like a VPN. This would not be unlike the cloud integration between on-premise and cloud you see in SAP hybrid cloud environments.
The OT network is in the red dashed box below. You don't see additional boxes around the items in it, to reflect that there isn't typically much protection at all. Communication between components is typically in clear text - be it proprietary protocols - and no encryption (or even signing) is implemented nor does much of this communication require authentication. That means, as long as an expected response comes back, each component is happy to talk to any other - including potential devices and machines under the control of an attacker.
Let's be explicit about what that means: if the attacker is in the network (or the IT network), is reasonably aware of the landscape and network traffic (which could be harvested from network monitoring and scans), and understands the proprietary protocols, they could send messages to other components in the landscape pretending to be a legitimate sensor, machine or even PLC. Similarly, it could trap messages sent by other components by pretending to be a legitimate component in the landscape, thereby stopping them from being received by that component. Finally, such messages could be altered along the network path, and thereby change the outcome of the communication. If we remember that there is typically no network segmentation, this could jeopardize the entire OT network.
This makes the situation worse, even, than what we saw with microcontrollers in the previous part of this series.
There are a number of startups trying to address this problem. But, given the strong focus on safety and being non-disruptive to communication in OT networks, this means they only monitor, and do not intervene. They tend to be protocol-aware, so they can understand what is going on in the communication, and obviously can create a network map of what communicates with what, including any unauthorized hosts the customer may not have been aware of (which could be largely legitimate, even if contrary to a customers security policy, like a way for an administrator to VPN from home remotely into the OT network).
Such tools therefore can monitor the traffic and flag anything that looks out of the ordinary, or where strange requests are being made. Some of them also can poll the configuration of the PLC periodically to see if it has changed. Any events can be sent to a central SIEM tool.
While this provides a degree of protection - and generally it seems a good idea to implement such a solution - it doesn't really solve the problem. This doesn't magically give us integrity between machines, nor does it provide protection against wiretapping or tampering. At best it gives us a warning that something bad has happened.
OPC-UA is a service-oriented architecture framework that integrates all the functionality of the individual OPC Classic specifications and adds new features on top of that. This comes from the OPC Foundation, of which SAP is one of over 450 members.
OPC-UA has many features, but obviously what concerns us most here is its security capabilities:
Well, that gives us pretty much exactly what we need! We can have end-to-end encryption from each component in the landscape to another. Even if encryption is not used (which ideally you should), you can at the very least use message signing, which at least ensure the communication comes from the machine or device we thought it came from.
Additionally, authentication and user control allows us to further lock things down, by only allowing machines that should be communicating with each other to do so, and not for components in the landscape that shouldn't need to. Finally, having a detailed audit trail (even in addition to any network traces by other OT security tools) will enable any forensics once strange or malicious behavior has been detected.
The main question is adoption, but also there we see progress. OPC-UA is strongly supported by large OEMs, manufacturing industry groups in Germany, as well as certain nations like China. That means we can probably expect adoption sooner rather than later. While such changes might not be very rapid to implement, as machines in OT networks often have a considerable life cycle, there are ways to retrofit on older equipment as well. I would also expect that the drive towards Industrial IoT would accelerate the adoption, rather than slow it down.
Update: We've started to see some interesting models that may help as well: and that is to leave the OT environment as it is currently, then use low-power microcontrollers to capture additional information that the OT network itself doesn't provide. Since such microcontrollers operate on an entirely different network (LPWAN), this creates by itself a strong network segmentation, and where the merging of OT, microcontroller sensor and business data only gets merged and analyzed in the cloud, or on-premise, but outside of the OT network itself. This is a model that warrants further analysis, but is certainly promising and should be a low-impact approach to get started.
We've come to the end of this particular blog series. As we discussed the various device classes, we saw that many of them have significant security issues, but we've also seen that for each of these classes existing and new techniques can be used to secure them. That does mean, of course, that we have to carefully make our purchasing decisions of IoT edge hardware. We should ensure it is capable of modern security practices, that should be part of our hardware requirements, and where devices do not support those, we should at least have the ability to tackle the problem ourselves, rather than be dependent on a manufacturer who may or may not have the security expertise to secure their own devices, or won't give us insight into the device firmware or won't allow us to update it.
And finally, we have to evaluate the risks involved in deploying such infrastructure. Depending on the ability to do damage, different levels of security might be acceptable. Maybe the risk of your office lighting being hacked is acceptable. For actual meaningful components in an IoT landscape that have a real ability to take actions and change outcomes, that is not going to be the case.
We're coming near the end of this series, and in this blog will tackle the fifth device class:
- “Dumb” 32-bit+ device
- Smart/Edge Processing 32-bit+ device
- GSM connected 32-bit+ device
- Microcontrollers
- SCADA/ICS, PLC systems
I also have to admit - and I guess that goes for most with an information security background - this is the class most unfamiliar to me. Unfortunately, it is also the device class that is likely most critical, as messages exchanged between the IT and OT (the industrial) network layer can actually have dramatic effect. Whereas most devices in class 1 through 4 will read data, and maybe run some analytics or data processing on that data, Industrial Control Systems (ICS, of which SCADA - Supervisory Control And Data Acquisition systems - are a large subset) by design and by nature operate in the real world: these are the systems that control critical infrastructures like energy generation, transportation systems, oil refineries and chemical plants, manufacturing factories, etc. When we are talking about big adverse effects in IIoT, this is really what we're talking about.
Meanwhile, the promise of IIoT is exactly in optimizing and automating such processes. Given the past of SAP, a future of "ERP-driven manufacturing" in which the orders present in an SAP system drives production is an obvious high value use case.Will Predictive Maintenance seems to be the initial "killer app" of IIoT, such optimized production certainly is one of the key promises of IIoT.
At the same time, though, we're starting from a baseline that from a security perspective makes me worried. These networks operate with safety and reliability as primary concern, don't really use encryption today for communication or integrity, and communicate over proprietary protocols. Older Programmable Logic Controllors (PLC) often run on Windows XP, an OS notorious for its security problems. The end of support for Windows XP caused consternation in the industrial world just a few years ago, leading to articles such as this. Network segmentation within such OT networks is rare to non-existent. And while there is ideally a strong separation between the IT and OT networks (so-called "airgapping") currently, IIoT is all about bridging that IT and OT divide. Rightly so, "Industrial Internet of Things" raises a good number of security concerns.
So, let's look at the threat model for this class:
Connectivity between the IT and OT layer typically is some sort of secure communication channel like a VPN. This would not be unlike the cloud integration between on-premise and cloud you see in SAP hybrid cloud environments.
The OT network is in the red dashed box below. You don't see additional boxes around the items in it, to reflect that there isn't typically much protection at all. Communication between components is typically in clear text - be it proprietary protocols - and no encryption (or even signing) is implemented nor does much of this communication require authentication. That means, as long as an expected response comes back, each component is happy to talk to any other - including potential devices and machines under the control of an attacker.
Let's be explicit about what that means: if the attacker is in the network (or the IT network), is reasonably aware of the landscape and network traffic (which could be harvested from network monitoring and scans), and understands the proprietary protocols, they could send messages to other components in the landscape pretending to be a legitimate sensor, machine or even PLC. Similarly, it could trap messages sent by other components by pretending to be a legitimate component in the landscape, thereby stopping them from being received by that component. Finally, such messages could be altered along the network path, and thereby change the outcome of the communication. If we remember that there is typically no network segmentation, this could jeopardize the entire OT network.
This makes the situation worse, even, than what we saw with microcontrollers in the previous part of this series.
Security tools for OT networks
There are a number of startups trying to address this problem. But, given the strong focus on safety and being non-disruptive to communication in OT networks, this means they only monitor, and do not intervene. They tend to be protocol-aware, so they can understand what is going on in the communication, and obviously can create a network map of what communicates with what, including any unauthorized hosts the customer may not have been aware of (which could be largely legitimate, even if contrary to a customers security policy, like a way for an administrator to VPN from home remotely into the OT network).
Such tools therefore can monitor the traffic and flag anything that looks out of the ordinary, or where strange requests are being made. Some of them also can poll the configuration of the PLC periodically to see if it has changed. Any events can be sent to a central SIEM tool.
While this provides a degree of protection - and generally it seems a good idea to implement such a solution - it doesn't really solve the problem. This doesn't magically give us integrity between machines, nor does it provide protection against wiretapping or tampering. At best it gives us a warning that something bad has happened.
OPC-UA to the rescue?
OPC-UA is a service-oriented architecture framework that integrates all the functionality of the individual OPC Classic specifications and adds new features on top of that. This comes from the OPC Foundation, of which SAP is one of over 450 members.
OPC-UA has many features, but obviously what concerns us most here is its security capabilities:
- Session encryption (using modern PKI)
- Message signing (i.e. cryptographically signed for integrity)
- Sequenced packets, providing some level of protection against replay attacks
- Authentication, through the use of certificates
- User Control (or ACLs, if you like)
- Auditing, as activities by users and systems are logged
Well, that gives us pretty much exactly what we need! We can have end-to-end encryption from each component in the landscape to another. Even if encryption is not used (which ideally you should), you can at the very least use message signing, which at least ensure the communication comes from the machine or device we thought it came from.
Additionally, authentication and user control allows us to further lock things down, by only allowing machines that should be communicating with each other to do so, and not for components in the landscape that shouldn't need to. Finally, having a detailed audit trail (even in addition to any network traces by other OT security tools) will enable any forensics once strange or malicious behavior has been detected.
The main question is adoption, but also there we see progress. OPC-UA is strongly supported by large OEMs, manufacturing industry groups in Germany, as well as certain nations like China. That means we can probably expect adoption sooner rather than later. While such changes might not be very rapid to implement, as machines in OT networks often have a considerable life cycle, there are ways to retrofit on older equipment as well. I would also expect that the drive towards Industrial IoT would accelerate the adoption, rather than slow it down.
Update: We've started to see some interesting models that may help as well: and that is to leave the OT environment as it is currently, then use low-power microcontrollers to capture additional information that the OT network itself doesn't provide. Since such microcontrollers operate on an entirely different network (LPWAN), this creates by itself a strong network segmentation, and where the merging of OT, microcontroller sensor and business data only gets merged and analyzed in the cloud, or on-premise, but outside of the OT network itself. This is a model that warrants further analysis, but is certainly promising and should be a low-impact approach to get started.
We've come to the end of this particular blog series. As we discussed the various device classes, we saw that many of them have significant security issues, but we've also seen that for each of these classes existing and new techniques can be used to secure them. That does mean, of course, that we have to carefully make our purchasing decisions of IoT edge hardware. We should ensure it is capable of modern security practices, that should be part of our hardware requirements, and where devices do not support those, we should at least have the ability to tackle the problem ourselves, rather than be dependent on a manufacturer who may or may not have the security expertise to secure their own devices, or won't give us insight into the device firmware or won't allow us to update it.
And finally, we have to evaluate the risks involved in deploying such infrastructure. Depending on the ability to do damage, different levels of security might be acceptable. Maybe the risk of your office lighting being hacked is acceptable. For actual meaningful components in an IoT landscape that have a real ability to take actions and change outcomes, that is not going to be the case.
- SAP Managed Tags:
