Operations
9/24/2016
09:30 AM
Lysa Myers
Lysa Myers
Commentary
Connect Directly
Facebook
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

7 New Rules For IoT Safety & Vuln Disclosure

In the Internet of Things, even the lowliest smart device can be used for a malicious purpose. Manufacturers take heed!

If you've ever been irked by someone who has spent an entire shared meal staring at their phone, you know that social norms around technology are slow to catch up with our actual use of it. It's no secret that most "smart" devices haven’t kept up with the state of the art in security knowledge, but manufacturers of the Internet of Things are also failing to keep up to date when it comes to safety notification and vulnerability disclosure. Here are seven new rules to safeguard users from the unknown "things" that could do them harm.

Image Source: Montri Nipitvittaya via Shutterstock
Image Source: Montri Nipitvittaya via Shutterstock

Rule #1 – Notify Users of Significant Changes
If a device is designed to be interacted with several times a day, repeated actions will quickly become muscle memory. Once that memory is in place, you'll probably always interact with a device in that way. People need to be clearly (maybe even repeatedly) notified of significant changes. Any feature changes that remove or alter safety features, or that would introduce a safety hazard, should be not be considered a feasible option.

Rule #2 – Be Thorough with Vulnerability Reports
Device manufacturers should have a protocol for handling vulnerability reports, and a responsible disclosure policy posted in a prominent place on their website. Because vulnerabilities in medical devices may literally be a matter of life and death, it is a good idea – especially if a vendor does not yet have a publicly posted responsible disclosure policy – to send vulnerability reports to the attention of the Food and Drug Administration (FDA) via MedWatcher.

Rule #3 – Give Humans Veto Power
While no one would argue that humans are infallible, there are times when it is imperative to let a human expert give the final decision. If reputations, livelihoods, health, or lives are on the line, software makers have a moral obligation to give the most qualified available human the ability to weigh in on the decision. In the case of automated medical diagnosis, that will most likely be a doctor. In the case of an auto-piloted car, that should be a driver who is still responding to what's on the road even if they’re not pressing pedals or steering. The more serious the potential outcome of the choice, the more heavily the inclusion of human decision (or at least active interaction) should be weighted towards being mandatory.

Rule #4 – Provide a Method for Prompt and Easy Updates
The code used for just about any sort of software application is incredibly long and complex, and with complexity come errors. Devices need to have the ability to quickly and easily update software when an error is identified. Whatever method is used, it should be easy for customers to spot fraudulent updates and it should not require them to go to a service center that may be hundreds of miles away from rural users.

Rule #5 – Provide a Method for Audit Logging
While we might like to think our Internet-connected washing machine might be too uninteresting for criminals to bother with, this line of thought is simply naïve. Even the lowliest devices can hold some utility for malicious purposes such as spamming or DDoS. And without behavior-logging functions to keep track of what’s happening, we can't know when that's occurring. When limited storage dictates a diminutively-sized log file, users should have the option to export or sync that file with another device.

Rule #6 – Authenticate Input
I’m sure we've all had the experience where a child or a pet pressed a button that made unexpected changes to some setting or other. When the change is something benign like enabling foreign subtitles, the stakes are fairly low. When devices have the ability or information to affect our lives, our health, or our reputations, even simple changes can have very powerful effects. This being the case, we need to make extra sure that changes are made by the authorized user or a designated representative, rather than a malicious individual or a meandering pet.

Rule #7 – Have an Exit Plan
Many IoT devices require cloud-based services to operate. If a company is discontinuing a device, going out of business or otherwise ending support for the cloud-based service, provide a mechanism for allowing users to transition the service. This could include selecting an alternate cloud-based service or publishing enough technical information so that users can create their own replacement.

It takes time for appropriate social mores to coalesce for new things, and while we might like for certain norms and rules to be obvious right out of the gate where security and safety are concerned, that is not the case. Until we get an official Miss Manners guide dictating etiquette for new technology, vendors and users will likely create some awkward situations. Hopefully, in higher-risk areas this will be hashed out more quickly so there will be little loss of life and limb and the lessons learned can then trickle down to lower-risk devices. 

Related Content:

Lysa Myers began her tenure in malware research labs in the weeks before the Melissa virus outbreak in 1999. She has watched both the malware landscape and the security technologies used to prevent threats from growing and changing dramatically. Because keeping up with all ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Cybersecurity's 'Broken' Hiring Process
Kelly Jackson Higgins, Executive Editor at Dark Reading,  10/11/2017
Ransomware Grabs Headlines but BEC May Be a Bigger Threat
Marc Wilczek, Digital Strategist & CIO Advisor,  10/12/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Search Cybersecuruty and you will get unicorn.
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
The State of Ransomware
The State of Ransomware
Ransomware has become one of the most prevalent new cybersecurity threats faced by today's enterprises. This new report from Dark Reading includes feedback from IT and IT security professionals about their organization's ransomware experiences, defense plans, and malware challenges. Find out what they had to say!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript 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 ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.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).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper 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.

CVE-2017-0890
Published: 2017-05-08
Nextcloud 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.