This is the 2nd in a series. The first post is here. Part 3 is here
As discussed in the previous post, for the purpose of this series, I am looking at five different device classes:
In this post we will discuss the first three.
This part 2 is called "general computing devices", because essentially that is what they are: These devices are based on 32-bit or 64-bit boards that can run a full Operating System, typically Linux. You could think of a Raspberry Pi, but also your smart phone. Or your laptop. Or a base station for your IoT-enabled lights. Network routers. The entertainment console in your car. Smart Refrigerators. Smart meters.
The wide variety of products mentioned should already give you a clue: these devices can do anything a normal "computer" can do. They are likely to be in a different case, and may not have a keyboard or even a screen, but under the covers there are not really different from the laptop that I am typing on. Some may have a hard disk, while others use Flash memory. Some may have a lot of physical memory and a GPU, others may just have enough to do the task the device is designed for. They may have ethernet ports, wireless connectivity and/or a SIM card to use a mobile phone network for communication.
The nice thing though, is that if they are really under the cover the same thing, we can treat them largely the same, too. That is, they will simply be a collection of Linux hosts, and we can use techniques we've learnt and developed in more traditional IT to protect IoT environments made up of such general computing devices. That is, the best practices laid out in this post from last year fully or largely apply to these first three device classes, most notably, we can use modern X.509 PKI certificates and encryption, and we have a firewall baked into the kernel.
Let's have a closer look at those devices in our landscape:
For clarity, I've removed the other two device classes and the web front-end from the diagram so it is a little easier to follow. You can see the full landscape diagram in the previous post in the series.
The "dumb" device is the simplest, but as a result also the easiest to secure. First, we need to physically protect the device where that is pertinent. Physical access often allows access to debug pins on the board, so if an attacker gains physical access and control over the device, there is not much we can do. Secondly, we need to protect the assets and services it relies on for secure communication: a DNS we can trust, a certificate authority we trust, and the end point we need to communicate with.
Then, we have to consider the manufacturer of the device itself: how are updates handled? Is this done securely and signed appropriately? Does this open an interface on the device we need to protect? Can the manufacturer overwrite the system we trust with its own? After what we have seen with the Mirai botnet we would be wise to fully understand this mechanism, including the use of any default manufacturer passwords and insecure communication channels like telnet.
If we have control over the firmware, or it has at least the ability for us to configure the device to the level we need, and place a certificate on it, we can otherwise lock it down very tightly: set up strict firewall rules following a white listing approach, run any processes on it with the lowest possible privilege that allows them to operate, etc. Any communication with our end point should be over TLS, where both the server and the client validate each others' certificates.
For smart devices, or devices with edge processing capabilities, largely the same applies. However, the risk profile goes up necessarily, simply because it has more capabilities. A smart device needs more processing power, and will typically include a writable file system where data can be aggregated and pre-processed before it is sent on to a central endpoint, or otherwise acts on the collected data. It will as a result have more libraries included that can be turned against the device. In some cases, it may even include a compiler.
Communication might also be bi-directional. That is, while in the dumb device model the device simply sends data on a periodic interval or when certain thresholds are met, the smart device likely also receives messages and therefore may have an open interface(not to be confused with a device that periodically polls a central server and gets a message when there is one, that is still a single-direction device).
This means our configuration has to be a bit more involved. We may want to set up a specific firewall rule, for instance, that only allows machines within a particular (limited) IP address range to send messages to this device.
The final device class to discuss in this post is the GSM connected device. In every way but one is this identical to the dumb and the smart devices: it uses a mobile phone network for communication, rather than a wired or wireless network we can control ourselves. Of course, we can, and should, still use X.509 PKI certificates for encrypted communication, so the issue is not so much here that the telecommunications provider could listen in on the communication. (They could, of course, if we did not encrypt the communication) The issue is that this largely removes the device from our monitoring.
For the first two devices, these will run inside of our networks, whether wireless or wired, in a physical location. We can monitor this network, and place against on our devices to assist with that. We can use SDN and NAC to protect the network from intruders and raise alerts when we see anything out of the ordinary.
With the GSM connected device we completely lose this capability, as the device completely bypasses our own networks, until a message finally arrives at the end point. Rather than connect to our wireless routers or ethernet network routers, it directly talks to a cell phone tower, runs through the telco's network, and then out through the public internet to our end point. As long as this traffic is encrypted and certificates are validated, there should be no opportunity to tamper or eavesdrop on that communication. But it does mean the devices disappear entirely from our monitoring, which means that early detection of attempted attacks is likely not possible.
There is one other possible threat, and that is that the device maybe connected up to an app store. This will certainly be the case where a person's cellphone is used to bridge to a low power device, but the capability may even be present in GSM connected devices that look nothing like a phone. There is almost certainly no legitimate reason for the device to connect to this app store, unless it is the delivery mechanism for software updates (or it is a person's cellphone). If not, I suggest we should consider whether we need it at all, and firewall it off if we find we don't.
These first three device classes are reasonably well capable of being secured, simply by using the features that come with the Operating System (even if it might be slightly out of date). We may need to consult with the manufacturer how to configure it to our liking, and where such cooperation proves difficult or the manufacturer doesn't allow access to the device, you may want to consider another supplier. In many cases, alternatives exist.
In the following two blogs in this series, we'll discuss microcontrollers and low-power networks, as well as industrial networks and systems.
Part 3: microcontrollers
As discussed in the previous post, for the purpose of this series, I am looking at five different device classes:
- "Dumb" 32-bit+ device
- Smart/Edge Processing 32-bit+ device
- GSM connected 32-bit+ device
- Microcontrollers
- SCADA/ICS, PLC systems
In this post we will discuss the first three.
This part 2 is called "general computing devices", because essentially that is what they are: These devices are based on 32-bit or 64-bit boards that can run a full Operating System, typically Linux. You could think of a Raspberry Pi, but also your smart phone. Or your laptop. Or a base station for your IoT-enabled lights. Network routers. The entertainment console in your car. Smart Refrigerators. Smart meters.
The wide variety of products mentioned should already give you a clue: these devices can do anything a normal "computer" can do. They are likely to be in a different case, and may not have a keyboard or even a screen, but under the covers there are not really different from the laptop that I am typing on. Some may have a hard disk, while others use Flash memory. Some may have a lot of physical memory and a GPU, others may just have enough to do the task the device is designed for. They may have ethernet ports, wireless connectivity and/or a SIM card to use a mobile phone network for communication.
The nice thing though, is that if they are really under the cover the same thing, we can treat them largely the same, too. That is, they will simply be a collection of Linux hosts, and we can use techniques we've learnt and developed in more traditional IT to protect IoT environments made up of such general computing devices. That is, the best practices laid out in this post from last year fully or largely apply to these first three device classes, most notably, we can use modern X.509 PKI certificates and encryption, and we have a firewall baked into the kernel.
Let's have a closer look at those devices in our landscape:
For clarity, I've removed the other two device classes and the web front-end from the diagram so it is a little easier to follow. You can see the full landscape diagram in the previous post in the series.
"Dumb" device
The "dumb" device is the simplest, but as a result also the easiest to secure. First, we need to physically protect the device where that is pertinent. Physical access often allows access to debug pins on the board, so if an attacker gains physical access and control over the device, there is not much we can do. Secondly, we need to protect the assets and services it relies on for secure communication: a DNS we can trust, a certificate authority we trust, and the end point we need to communicate with.
Then, we have to consider the manufacturer of the device itself: how are updates handled? Is this done securely and signed appropriately? Does this open an interface on the device we need to protect? Can the manufacturer overwrite the system we trust with its own? After what we have seen with the Mirai botnet we would be wise to fully understand this mechanism, including the use of any default manufacturer passwords and insecure communication channels like telnet.
If we have control over the firmware, or it has at least the ability for us to configure the device to the level we need, and place a certificate on it, we can otherwise lock it down very tightly: set up strict firewall rules following a white listing approach, run any processes on it with the lowest possible privilege that allows them to operate, etc. Any communication with our end point should be over TLS, where both the server and the client validate each others' certificates.
Smart/Edge Processing device
For smart devices, or devices with edge processing capabilities, largely the same applies. However, the risk profile goes up necessarily, simply because it has more capabilities. A smart device needs more processing power, and will typically include a writable file system where data can be aggregated and pre-processed before it is sent on to a central endpoint, or otherwise acts on the collected data. It will as a result have more libraries included that can be turned against the device. In some cases, it may even include a compiler.
Communication might also be bi-directional. That is, while in the dumb device model the device simply sends data on a periodic interval or when certain thresholds are met, the smart device likely also receives messages and therefore may have an open interface(not to be confused with a device that periodically polls a central server and gets a message when there is one, that is still a single-direction device).
This means our configuration has to be a bit more involved. We may want to set up a specific firewall rule, for instance, that only allows machines within a particular (limited) IP address range to send messages to this device.
GSM connected device
The final device class to discuss in this post is the GSM connected device. In every way but one is this identical to the dumb and the smart devices: it uses a mobile phone network for communication, rather than a wired or wireless network we can control ourselves. Of course, we can, and should, still use X.509 PKI certificates for encrypted communication, so the issue is not so much here that the telecommunications provider could listen in on the communication. (They could, of course, if we did not encrypt the communication) The issue is that this largely removes the device from our monitoring.
For the first two devices, these will run inside of our networks, whether wireless or wired, in a physical location. We can monitor this network, and place against on our devices to assist with that. We can use SDN and NAC to protect the network from intruders and raise alerts when we see anything out of the ordinary.
With the GSM connected device we completely lose this capability, as the device completely bypasses our own networks, until a message finally arrives at the end point. Rather than connect to our wireless routers or ethernet network routers, it directly talks to a cell phone tower, runs through the telco's network, and then out through the public internet to our end point. As long as this traffic is encrypted and certificates are validated, there should be no opportunity to tamper or eavesdrop on that communication. But it does mean the devices disappear entirely from our monitoring, which means that early detection of attempted attacks is likely not possible.
There is one other possible threat, and that is that the device maybe connected up to an app store. This will certainly be the case where a person's cellphone is used to bridge to a low power device, but the capability may even be present in GSM connected devices that look nothing like a phone. There is almost certainly no legitimate reason for the device to connect to this app store, unless it is the delivery mechanism for software updates (or it is a person's cellphone). If not, I suggest we should consider whether we need it at all, and firewall it off if we find we don't.
These first three device classes are reasonably well capable of being secured, simply by using the features that come with the Operating System (even if it might be slightly out of date). We may need to consult with the manufacturer how to configure it to our liking, and where such cooperation proves difficult or the manufacturer doesn't allow access to the device, you may want to consider another supplier. In many cases, alternatives exist.
In the following two blogs in this series, we'll discuss microcontrollers and low-power networks, as well as industrial networks and systems.
Part 3: microcontrollers
- SAP Managed Tags:
