theDocumentId => 745643 Five IoT Endpoint Security Recommendations for the ...

Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint Security //

Firewall

8/27/2018
09:05 AM
Alan
 Zeichick
Alan Zeichick
Alan Zeichick
50%
50%

Five IoT Endpoint Security Recommendations for the Enterprise

It's 2:00 a.m. Do you know where your devices are? Find out five IoT security tips to help you sleep at night.

Change the default passwords! Know what devices you have and where they are! Get rid of old devices! If it can't be patched, yank it out! Those are some of my recommended best practices when it comes to enterprise IoT devices -- whether they're located in corporate offices, out in the field (from farms to mall kiosks), at customer sites or even hiding inside consumers (think medical devices).

Smart photocopiers, factory-floor systems and even handheld scanners used by parcel delivery staff seem like they're new, because of the name "Internet of Things." However, connected and embedded devices have been used for business purposes for decades, and they're getting new attention.

The advent of cellular data modems and ubiquitous. WiFi and Bluetooth have made it easier to deploy IoT devices. Cheap microprocessors, memory, sensors, batteries and radios mean that the price has dropped to, well, under a dollar in some cases. That makes it easy to lose track of such devices -- and forget that anything connected to our corporate network, or to the Internet, is both at risk of a breach and a potential threat if it's compromised, and then subverted to hurt us or others, electronically or in the real world.

Here are five suggestions for enterprises that are currently using embedded or IoT devices (which is probably most of them) or are considering (which is most of the rest). Anything connected to a network with a microprocessor is an IoT device, whether you think of it that way or not. That means risks. Security is not an option -- it's totally required.

1. Look for security information from device makers
Before you attach anything --anythingto your network (or allow a remote connection), make sure you understand its security basics. What are the built-in security features, such as the ROMs (read-only memory) it boots up from? What protections are built into its operation system and microprocessors? Where do patches come from, and how are they delivered to you (or the device) by the vendor?

More questions: Can you remotely manage the device or kill it if necessary, or are those things the vendor can do if you can't? If there is a breach or a reported vulnerability, what channels will the vendor take to notify you? How fast will the vendor promise to respond? Is there are service-level guarantee on how fast patches will be delivered? Lots and lots of questions. You need answers. If you don't like the answers, don't install the device -- because as soon as you do, you've assumed all the risk.

2. Install strong automated asset management
It's 2:00 a.m. Do you know where all your IoT devices are? An organization with large-scale deployments of mobile and portable devices must keep track of them all, but it's impossible to do so manually. The only solution is an automated asset management system that will listen for traffic for occasionally connected devices and reach out to contact devices on a regular schedule. (The schedule will vary depending on the device, of course.)

The asset management system and its agents should be able to monitor report on the health of the devices, check the ROMs and installed software to ensure they are up-to-date and not tampered with. If the device can provide its geolocation, that should be monitored as well, and alerts sent if something is wrong -- think geofencing. (Location can be approximated based on network connectivity.) If possible, the asset management system should be able to temporarily or permanently kill an IoT device, in the event of a breach, theft, or who-knows-what.

innspirito via Pixabay
innspirito via Pixabay

3. Employ robust authentication and encryption
The first thought about authentication is: If there's an administrative log-in to the device, make sure the device is protected by a username and password -- and neither are still the factory defaults. Also make sure that nobody can do a physical reset (with a paperclip) and set the device back to the default administrative login and password. The same goes for remote management, whether it's by an embedded web server, a text console, or SNMP.

That's only the start. Data goes both ways. Make sure that data flowing from the device to your data center, or to a cloud service, can only be received by the correct recipient(s). Also, make sure that only data from authorized sources can be sent to the IoT device. Consider using VPNs, if possible, to ensure that the device is on a secure network. That's especially true if, for example, you're dealing with a portable or mobile device that's connected via WiFi. And encryption -- well, presumably everyone understands why nothing should go via clear text, and why encryption should be strong, up to date and not use buggy protocols or libraries. Right?

4. Ensure devices can be upgraded over the air
Not long ago, software updates to embedded devices required physical access to the device, to swap out a ROM, plug in an RS-232 patch cable, or place the device into "update" mode. Nowadays, forget that. Devices need to be updated "over the air" (we use that phrase even if the device is physically connected to the network), or they're not going to be updated at all.

There are questions. Who pushes out the updates, you or the vendor? It's best if you can, so that you can test updates and schedule the push. (Sometimes updates change security settings, which is one reason why you need to test.) There should be provisions to ensure that only authorized users (or authorized servers) can push new software into devices, whether it's firmware, operating systems, or applications residing in memory.

In the case of occasionally connected devices, be sure to determine whether you want them to update as soon as they connect, or if that's inconvenient for the user. Make sure you are in charge of updates, and that your asset management system knows what has been updated and where updates may have failed. It happens.

5. Remove insecure and orphaned devices immediately
Devices get old. Support contracts and bug-fixes can be discontinued by the manufacturer. Sometimes there's a show-stopped security flaw that simply can't be remediated through firmware. Make sure that you know about these situations -- and don't leave those devices active any longer than necessary. If you can swap out the hardware quickly, great. If not, consider deactivating the devices, or at least requiring the users to turn in the equipment.

All of this can be very tricky in the IoT domain -- imaging medical devices, farming, remote telemetry and so on. It's a lot harder than scheduling to replace laptops every three or five years! Getting the new devices and then scheduling and performing the device exchange can take a lot of time and cost a lot of money. That's a shame, but consider the risk of leaving insecure and unsupported devices in the field, or on your network.

To emphasize: You need the ability to wipe and shut down devices if they are breached, stolen, lost, or whatever. Make sure that's a capability of your asset management system, and of the IoT devices you purchase and deploy.

Get ready to act
There's risk in deploying any technology on your network. Those risks multiply with the IoT, in large part because of the sheer numbers of devices and the fact that many are portable or mobile. It's often impossible to manage them the same way you'd manage a desktop or a server.

That risk is part of the IoT equation. Make sure you are in change of the security of those IoT endpoints -- because if you're not, someone else might be.

Related posts:

Alan Zeichick is principal analyst at Camden Associates, a technology consultancy in Phoenix, Arizona, specializing in enterprise networking, cybersecurity and software development. Follow him @zeichick.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-37436
PUBLISHED: 2021-07-24
Amazon Echo Dot devices through 2021-07-02 sometimes allow attackers, who have physical access to a device after a factory reset, to obtain sensitive information via a series of complex hardware and software attacks. NOTE: reportedly, there were vendor marketing statements about safely removing pers...
CVE-2021-32686
PUBLISHED: 2021-07-23
PJSIP is a free and open source multimedia communication library written in C language implementing standard based protocols such as SIP, SDP, RTP, STUN, TURN, and ICE. In PJSIP before version 2.11.1, there are a couple of issues found in the SSL socket. First, a race condition between callback and ...
CVE-2021-32783
PUBLISHED: 2021-07-23
Contour is a Kubernetes ingress controller using Envoy proxy. In Contour before version 1.17.1 a specially crafted ExternalName type Service may be used to access Envoy's admin interface, which Contour normally prevents from access outside the Envoy container. This can be used to shut down Envoy rem...
CVE-2021-3169
PUBLISHED: 2021-07-23
An issue in Jumpserver 2.6.2 and below allows attackers to create a connection token through an API which does not have access control and use it to access sensitive assets.
CVE-2020-20741
PUBLISHED: 2021-07-23
Incorrect Access Control in Beckhoff Automation GmbH & Co. KG CX9020 with firmware version CX9020_CB3011_WEC7_HPS_v602_TC31_B4016.6 allows remote attackers to bypass authentication via the "CE Remote Display Tool" as it does not close the incoming connection on the Windows CE side if t...