Workplace IoT Puts Companies on Notice for Smarter Security

Blacklisting every "thing" in sight and banning connections to the corporate network may sound tempting, but it's not a realistic strategy.

The security threats posed by the proliferation of Internet of Things (IoT) devices are top of mind for security practitioners, and with good reason.

Gartner projects 8.4 billion connected things will be in use this year, and that includes far too many devices with vulnerabilities that are a recipe for disaster. IoT devices should have secure passwords that can automatically be updated with the most current patches. Too often, though, that is not the case. In the rush to market, devices are manufactured and shipped with easy-to-guess passwords and outdated operating systems, making devices such as webcams, surveillance cameras, and baby monitors relatively easy targets for attackers.

But it's not just at home where IoT devices can invite disaster. IoT security risks often play out in the workplace. We are a gadget-loving society, especially the younger generations, so it's no surprise to see that employees expect to take their smart watches, fitness devices, and other connected devices to work. Consequently, in ISACA's State of Cyber Security 2017 research, only 13% of respondents indicated their enterprise is unconcerned with IoT in the workplace.

Given the understandable unease, employers may be tempted to take a knee-jerk approach and ban employees from using their connected devices in the workplace, similar to what they did when people started taking smartphones to work. But organizations should avoid that inclination and instead focus on providing clear instructions for how employees can safely and appropriately use their devices in a way that does not put the organization at risk. Otherwise, current and prospective employees may look for a friendlier workplace to take their devices — and their talents.

Putting a sound IoT policy in place — with emphasis on separate network segments for employee-owned devices — is a far better alternative. The policy should address issues such as whether devices will be allowed to connect to the Internet and how to handle devices capable of recording sound or video. If connections to the Internet are allowed, devices should be funneled to a guest or other network segment that is not connected to the corporate network. That way, if those devices are infected or tampered with, they do not spread the infection to the internal network. A monitoring component is also necessary to ensure that unapproved devices are blocked.

There are, however, some connected devices that legitimately rely upon connections to the internal enterprise network — think medical devices at hospitals or clinics that are storing critical data in an internal storage area on the network. These devices should be connected to the enterprise network, but without Internet connectivity that could enable external attacks. Whenever possible, such devices should be locked down so that only trusted apps approved by IT are installed on them.

Organizations committed to sound IoT security also must factor in employee training. If a smart TV is purchased for a conference room, does it need to be connected to the Internet? Should the microphone be turned on? Are staff members allowed to take photos of whiteboards, and if so, to whom could that data eventually be accessible? Most employers would struggle with those answers — and likely not even have thought to ask the questions, underscoring the need for training.

These dynamics are only going to become more pronounced in the foreseeable future. We're still much closer to the beginning than the end of the attack cycle leveraging IoT devices. But as valid as the security concerns are — and I hear them all the time from my colleagues in the industry — blacklisting everything in sight and banning connected devices from the workplace is not a realistic approach.

Instead, having sound policies in place, making effective use of network segmentation, and monitoring the corporate network diligently will position organizations to operate securely, without alienating their workforce.

Learn from the industry’s most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Click for more info and to register.

Robert Clyde, CISM, NACD Board Leadership Fellow, is vice-chair of ISACA's board of directors and is managing director of Clyde Consulting LLC, which provides board and executive advisory services to cybersecurity software companies. He is the executive chair of the board of ... View Full Bio

Published: 2017-05-09NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.