Endpoint
12/12/2016
12:12 PM
Mark Baugher
Mark Baugher
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Whats Naughty & Nice About The Internet Of Things

It's easy to catalogue the worst IoT security hazards. But that's not the whole story.

The press rightly publicizes the worst IoT security hazards, and there’s a hefty catalogue of what’s wrong. The most recent entry on the naughty list is the “IoT-powered DDoS” traffic-flooding attack, where hackers exploit well-known passwords to control insecure connected devices like cameras and use them en masse to disrupt Internet service. Easily exploitable connected devices pollute the public Internet. The situation begs comparison to Ohio’s much-abused Cuyahoga River, which grew so concentrated with industrial sludge that it actually caught fire at least 13 times over the course of a century.

As was the case with the river, the ultimate solution to public Internet pollution problems may be regulation of access to this public resource, but self-correction on the part of industry and the populace also matters. Reputable companies only stay reputable if their products reliably serve their rightful owners. At minimum, reputable suppliers ship non-polluting IoT products — and feature state-of-the-art security, even if the state-of-the-art is not yet all that it needs to be.

What's Wrong with IoT Security: Insecure Onboarding
Shipping a product with a well-known password is not state-of-the-art security. But it’s part of a more general problem that has long plagued IoT: The earliest IoT specifications set contradictory security goals in an attempt to make things easy and spur adoption. One standards group wanted security to be “transparent during setup” and the “best security possible.” Experience has shown that security can be either transparent or the best, but it’s rarely both. To serve transparency, suppliers have used common pre-shared keying material, dispersed keys over networks in plaintext, or shipped with well-known passwords. All are risky practices that are vulnerable to common attacks such as jamming and malware scripts.

In general, some person or provider must take ownership of an Internet-connected device before it commences operation, and too many do a poor job of locking down this initial step. The problem stems from the desire for simple, universal “plug and play” products. Even today, plenty of home routers operate and move packets as soon as you turn them on, even if their well-known passwords remain unchanged. Such a device may work properly for months or years, but is easily accessible to malware from day one. Few consumer routers or IoT devices offer secure plug-and-play — not yet, anyway.

Secure plug-and-play requires a vendor to “pre-provision” a device; for example, provide a factory-provisioned secret, public key, and signed digital certificate stored in a designated cloud account awaiting automatic enrollment. The cloud service automatically and securely associates the device with the user account when the device is plugged in. The service also puts the device under individual user control if done properly. Obviously, the user/owner of the device must trust the cloud provider explicitly for the model to work — and this is a major drawback for some.

The Middle Way: Security Ceremonies
A responsible alternative is to require a security ceremony, so that the user takes ownership and securely associates a device with a local network or cloud account. Typing in a PIN when installing a network camera, router, or other device is a common ceremony, and one of the best. You could argue that forcing the user to do anything (even entering a short number) is not “plug and play” in the literal sense. But provisioning network devices is necessary to prevent pollution: If a provider cannot provision ownership for the user, then the user must assert ownership of the device. This was true before the 2005 specification on UPnP Device Security and it is true today.

Since the root of all evil in IoT security begins with first use of an insecure device, vendors must be somehow compelled to follow best practices in the secure setup of a new device, such as with public-key cryptography, user-supplied input such as a PIN, or other means. Who or how to determine these practices and compel vendors to follow them is not considered here. But we do see the industry defining best practices in the security of both public and proprietary IoT systems such as Z-Wave, ZigBee, HomeKit, and Thread.

What's Improving: Secure Onboarding
Public-key cryptography is being introduced for better IoT security, though not in order to integrate (often low-powered) IoT devices into a public-key infrastructure (like Web clients or servers). Instead, the goal is to securely setup an IoT device prior to operation, which is variously called “onboarding” or “commissioning.” The use of elliptic-curve cryptography (ECC) by Z-Wave, ZigBee, HomeKit, Thread, and other solid IoT standards, solves today’s problem of securely taking ownership of a device like a camera or light bulb before it is activated and before it can be accessed by attackers via the network.

To wit, one of the newer IoT security systems is Z-Wave’s Security 2 (S2), which is in beta. Two of the people who hacked the Z-Wave system, Behrang Fouladi and Sahand Ghanoun, were subsequently recruited to the S2 design team.

S2 improves secure onboarding of new Z-Wave devices by requiring the installer to input a code from the newly introduced device to the Z-Wave gateway. That code is actually part of the public key of the Z-Wave device. Thus, if the gateway vendor decides to cut corners and skip the user input step, the S2 devices won’t work together. The user must supply part of the public key. Without that input, the key is unusable and the device can’t be commissioned into service.

The introduction of public-key cryptography is one small improvement to IoT security, but an important one. Public standards bodies, software developers, and IoT vendors have an important role to play in promoting best practices, which may greatly reduce the power of IoT botnets and ease our pollution problems.

Related Content:

 

 

Mark Baugher is the principal security engineer at Greenwave Systems, a leading international IoT software provider and services integrator partnering with Verizon, NXP, IBM, E.On, and others. Mark is a highly regarded IoT security engineer having created and patented ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
richa_gangwani
50%
50%
richa_gangwani,
User Rank: Apprentice
12/20/2016 | 2:05:35 AM
Good one
Good one! Thank you for sharing such an informative content.

It's my pleasure to inform you about BetaPage (https://betapage.co/) it is a startup directory where you can discover, hunt and upvote on various innovative startups as per your choice.
rayray2016
50%
50%
rayray2016,
User Rank: Apprentice
12/13/2016 | 1:01:23 PM
The 3 Week Diet Reviewsx
I have subscribed to the newsletter. thanks
rayray2016
50%
50%
rayray2016,
User Rank: Apprentice
12/13/2016 | 12:59:46 PM
The 3 Week Diet Reviewsx
I have subscribed to the newsletter. thanks
rayray2016
50%
50%
rayray2016,
User Rank: Apprentice
12/13/2016 | 12:53:56 PM
Re: Twenty Motion
I think thats a classy way to do it
Mark.Baugher
50%
50%
Mark.Baugher,
User Rank: Author
12/13/2016 | 8:54:42 AM
Re: Standards and passwords
The http://www.csoonline.com/article/3148695/security/netgear-working-to-fix-flaw-that-left-thousands-of-devices-open-to-attack.html hack is an example from a company that has long had automated firmware update and one of the better onboarding/commissioning process for the line of home routers I tested in the past.
kbannan100
50%
50%
kbannan100,
User Rank: Apprentice
12/12/2016 | 8:26:37 PM
Standards and passwords
We are at a time that reminds me of when people first realized that printers were a huge target -- and a security risk. While they still are, vendors and users alike are doing things that make them less of a target over the long run. Things like constantly updating firmware, building in self-healing and self-monitoring protection and turning off things like FTP are big leaps ahead for everyone involved. 

--Karen Bannan for IDG and HP
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.