Implementing IoT securely in your company – Part 2

January 12, 2017

After Part 1 which focused on setting up your network for IoT this post focus on making sure that the devices are the right ones and that they work in your network. The first can be accomplished by asking basic security questions and talking only with the more secure vendors further.  In my experience that also leads to the better vendors which know IT and whom will make your life easier in the long run. There are plenty of vendors out there for whom the whole IT part is new as they are an old vendor in a given field which now needs to do the “network thing” and don’t have the employees for it. Johannes B. Ullrich at SANS ISC InfoSec came up with the idea to preselect IoT vendors with 5 questions. (You can read more on his reasoning behind each question in his post):

5 preselect questions

1. For how long, after I purchase a device, should I expect security updates?
   This time frame will show us how long we can plan to use the device in our network, as using devices which get no security updates will be a compliance violation in most companies.
2. How will I learn about security updates?
   Responsible vendors will add you to a security mailing list where you will get informed on all security related stuff via email.
3. Can you share a pentest report for your device?
   If the vendor cares at all at security he let an external expert make a pentest, which will at least find the worst and stupid security holes. If the vendor is able to show you such an report, you should really take that vendor in consideration.
4. How can I report vulnerabilities?
   We often found security holes in programs or devices and sometimes it is really hard to report that to the vendor in a way he accepts it and fixes the hole in a reasonable time frame. Sometimes we needed to go via our local Austrian CERT and sometimes that even was not enough as the vendor was in the US and only did something after their CERT asked them pointed questions. So a direct connection the guy(s) responsible for the security of device is important.
5. If you use encryption, then disclose what algorithms you use and how it is implemented
   If the vendor tells you something about “Proprietary” run away from the product!  If you read that they use MD5 or RC4, the software on the device seems a little bit dated.

After selecting the best vendors ranked by the preselect questions you should make sure that the devices will run in your network. If you’re new to this kind of work you will not believe what garbage some vendors deliver. Some points are connected to your network and how it will look in the future.

• The device needs to support DHCP!
  • Use DHCP reservations to provide fixed IP addresses
  • Special case in a secure network is to disable ARP learning on the Layer 3 switches (makes MitM attack a lot harder). In this case DHCP is used for filling the ARP table.
• Check if the device will work with MAC oder 802.1x authentication flawlessly
  • Some devices only send a packet if queried, which won’t work if the device got de-authenticated e.g. idle timeout or network problem. The device needs to send a packet ever so often so the switch sees the MAC address and can make a RADIUS request.
• The devices needs to support routing
  • We had devices that where only able to talk within the subnet. In some cases we were not sure if the product really didn’t support it or just the technician was unable to configure it.
  • As the PCs and servers need to be separated via a Firewall (see Part 1), this feature is a deal breaker
• It should be possible to configure a local NTP Server
  • If not, the device time runs off or you need to allow the device to connect to the Internet, which can get complicated or insecure if you’ve different devices each using an other NTP server
• The devices needs to support automatic restart of services after power or network outage
  • We had some devices which needed manual interventions to reconnect to the servers again after a network problem
• Embedding of external resources should be looked at. e.g. If a device needs jquery for its web GUI and lets the browser load that via jquery.org it will not work it your Internet is down. In some cases that does not matter, in some thats a deal breaker.
• support of 1Gbit Ethernet connection
  • Sure I know that IoT devices do not need 1Gibt, but the devices will maybe run 10 years and you’ll have 10Gbit switches by than. It is not sure that 100Mbit will be supported or work flawlessly. e.g. Some current Broadcom 10Gbit chipsets don’t support 100Mbit half duplex anymore. You need an other chipset which is a little bit more expensive .. and you know what switch vendors will pick? 😉

So so far for part 2 of this series … the next part will be on some policy stuff you need to agree with department wanting that devices.

Implementing IoT securely in your company – Part 1

January 6, 2017

The last articles in this blog about IoT (often called Internet of Targets 😉 ) where about a specific cam or about IoT at home. This article series will be different, it will focus on the IoT in companies. Part one will talk about what you need to in order to prepare your network for IoT.

Prepare your network for IoT

There are 2 kinds of IoT devices/setups:

• ones that are directly connected to your network (e.g. house automation, access systems, …)
• ones that are connected via a mobile operator via GPRS, LTE, …. (e.g. car traffic counter, weather stations, webcam at remote places, …)

For the first ones it is a good idea to implement a separate virtual network, which means the traffic from and to the IoT devices always goes over a firewall before going to your servers or PCs. A normal company network should have following separate virtual networks outside the data centers.

• PC
• VoIP
• printer/scanner/MFD
• external Clients / visitors
• services = IoT

All those networks are connected to each other via a firewall and only required ports are opened. This separation is not arbitrary as it runs along some important differentiating factors:

• You’re PCs are normally centrally managed (monthly software updates, no administrator privileges for the users, …) and are allowed to access many and critical servers and services.  Also there is normally no communication needed between 2 PCs, so you can block that to make an attacker the lateral movement harder/impossible.
• The VoIP phones need QoS and talk directly which each other, as only SIP runs to the server, the (S)RTP media streams run between the phones – peer to peer.
• Let’s face it, nobody installs software updates on their printers, but they are full computers often with Windows CE or Linux. So like IoT devices we need to contain them. Also one printer does not need to talk to an other printer – block printer to printer traffic.

So lets talk about the IoT network:

• Put the servers of IoT devices (if they are not fully cloud based) into you’re data centers in the proper DMZ.
• IoT normally don’t talk directly which each other as the don’t require that the different devices are in the same network at all. So I highly recommend to block client 2 client traffic also in the IoT network. This blocking is important as if an attacker got his hand on one device, he cannot exploit wholes in other IoT devices by simply leap frogging from the first.

After you got your internal IoT network set up we take a look at the devices you need to connect via a mobile operator. First it is never a good idea to put IoT devices directly onto the Internet. Sure you can can use a VPN router for each IoT device to connect back to your data centers, but there is an easier way if you’ve more than a few devices. Most mobile operators provide a service that contains following:

• separate APN (access point name in GSM/UMTS/LTE speech) which allows authorized SIM cards to connect to a private non Internet network
• you can choose the IP range of this special mad-for-you network
• Each SIM card gets assigned a fixed IP address in this network
• IPsec tunnel which connects the private network to you data center(s)

Here in Austria you pay a setup fee and monthly for the private network but the SIM cards and the cost for bandwidth are basically the same as for normal SIM cards which connect to the Internet.  I recommend to choose 2 providers for this kind of setup as it will happen that one as a bad coverage at a given spot.  With this network and the fixed IP addresses it is quite easy to configure the firewall securely.

The next part will take a look at the policy for implementing new IoT devices, on making sure that the devices are the right ones and that they work in your network.