Three Security Practices That IoT Will Disrupt

I made it back from DEFCON with both my phone and tablet intact, but I'm happy I didn't bring a light bulb. You see, if had brought a light bulb, and that light bulb was a smart LED bulb running Linux, it might be running someone else's software by now.

Right now, there are hundreds of companies churning out "Internet of Things" (IoT) devices as fast as they can. The people slapping these devices together are often doing things on a shoestring budget, with an incomplete understanding of the full potential of their components, and rarely any eye toward security.

Learn IoT Security

Learn how ethical hackers exploit the growing number of internet-connected devices and become a Certified IoT Security Practitioner.

Get Started

The result so far has been millions of devices reaching the market with Clinton-era network, web and physical security. Today we're seeing IoT devices, even medical devices, ship with:

• default passwords such as "1234"
• vulnerable services such as "telnet" enabled
• firmware updates that depend on (easy to spoof) HTTP calls
• web applications that allow users to easily bypass authentication
• ...and other vulnerabilities that we (as a security community) thought we addressed more than a decade ago.

Is Help on the Way?

Some companies and communities are starting to realize that many IoT devices pose a threat to their security and privacy, but most still do not. However, there are some organizations with the courage and foresight to swim against the tide of insecure IoT devices.

• For developers and IoT vendors, there is a "Top 10 IoT Vulnerability" guide now available from OWASP (the organization that previously brought you the "Top 10 Web Vulnerability" list) and a resource site called "BuiltItSecure.ly" that digs into security best practices on several popular IoT platforms.
• For consumers and businesses, organizations such as the Internet of Things Security Laboratory promise to list and rate devices by their "hackability," allowing people to make informed decisions before buying insecure devices.

But How Does This Affect Established Security Practices?

As an IT professional concerned about security, you are already probably familiar with several secure best practices, each backed up with millions of man-years of actual use in high value environments. Three of these secure best practices include:

• Putting your internal resources behind a good firewall
• Putting your Internet-communicating applications in the DMZ, proxying your outbound web traffic and relaying your email
• Centralizing credential management and using shared authentication services (a.k.a. "single sign on" or "unified login")

One of the popular attributes of IoT technology is that it's "disruptive" technology. Normally, when you hear that term, it means that it threatens the market share of an established player, or that it may replace a different kind of application used for a similar purpose. But when "disruptive" is applied to IoT, it also means that IoT threatens a number of well-established security practices.

Three Security Best Practices Threatened by IoT

IoT vs. Internal Resources Behind a Firewall

The most common network topology we see in homes and businesses today looks like this:

• Internet --- Firewall --- Internal Network

...where:

• all of the devices on the Internet are untrusted and prevented from connecting to the Internet Network.
• all of the devices on the Internal Network are allowed to talk together using "internal" protocols like SMB.

This works, but only as long as all the devices on the Internal Network can be trusted to talk to each other, or at least are protected with other good security practices like regular patching and using antivirus.

The "BYOD" ("bring your own device" - really mostly smart phones and tablets) movement that began around 2010 lobbed the first grenade into this orderly world, and led many businesses (and a few consumers) to build a separate "guest" or "mobile" network for devices their employees, partners and contractors brought into the home or office. Today, IoT devices threaten to completely upend this model.

Many people install IoT devices (such as security cameras) for business purposes and expect them to be readily available on their Internet Network. Others install new devices (such as smart TVs, kitchen appliances and light bulbs), without expecting them to have any computing abilities or need to talk to anything else. The wide range of intentions and business purposes can quickly lead to a chaotic Internal Network environment where cheap, easily hackable devices may share signals with core storage and database servers.

A solution to this problem exists in the form of network segmentation (by business purpose and class of device), but deploying separate cables and wireless access points consistently across a business campus can strike many companies as cost-prohibitive.

Cost-driven compromises and the common error that people make when installing the wrong device in the wrong network mean that untrusted IoT devices will continue to have access to critical data across Internal Networks. However, the massive exposure weak segmentation creates gives me hope that the outdated practice of "just putting Internet Network resources behind the firewall" may soon be a thing of the past.

IoT vs. DMZs, Web Proxies and Email Relays

It is accepted best practice in larger organizations to use DMZ network segments to isolate outbound traffic emitters, including web proxies for all internally-initiated web traffic and email relays for all internally-composed email messages. IoT devices disrupt this model in several ways.

• IoT devices are almost never installed in DMZ segments, so typical DMZ firewall rules provide no protection.
• Some IoT devices do not support a web proxy configuration, so people are forced to abandon their devices or make web proxy exceptions for them.
• Some IoT devices can use cellular network services to "dial out" for updates and new information, rendering DMZ and all other firewall rules useless.
• Rather than send email alerts and messages locally, some IoT devices "phone home" (connect to a web service) and use their home service to send email back to the installer's email account across the Internet.

To defend against behavior that challenges established DMZ, proxy and relay practices, device capabilities must be researched before they are purchased. Specifically, you need to know if your IoT device:

• Needs to connect to the Internet using web services.
  • If it does, whether it supports a configured web proxy. (If it doesn't, avoid it.)
• Connects to a cellular network for Internet services or SMS (text) access. (If it uses cellular services, allow it to connect to your Internet Network with care.)
• Sends email alerts or other messages.
  • If it does, whether these messages are sent locally or across the Internet from a vendor's remote service. (Either case may be OK if the emails are not sensitive; otherwise internal-only systems should be preferred.)

IoT vs. Centralized Credential Management and Shared Authentication Services

A movement toward centralized credential management built on shared authentication services (such as Active Directory) has long been a central tenet of system architecture. Network security has benefited from this as well, since access to multiple systems can be quickly revoked from a central console, and users have fewer incentives to reveal "post-it" passwords when they can use the same credential on multiple systems.

The early days of cloud services provided a direct challenge to central management, but this challenge has largely been beaten back by cloud services that support "external authentication" (such as Active Directory agents or SAML). The BYOD movement also challenged this tenet, but is being defeated through integrations that require common credentials to access email, IM and file servers.

Now a similar challenge to centralized credential management is now being mounted by the onslaught of IoT devices, most of which only allow local user management, and associated IoT management systems which frequently also only allow local user management.

Business-facing cloud services were brought to heel eventually because their "freemium" business strategies required business customers to buy the premium services, and businesses demanded integration with their local authentication systems. However, it remains to be seen if IoT devices will face the same pressure, especially in arenas such as kitchen appliances, light bulbs and security cameras where so many of the potential buyers are home consumers (who don't value centralized authentication).

In the meantime, it is worth seeking out devices and management consoles that support Active Directory, SAML, RADIUS and other well-established "external authentication" methods that allow you to control access to IoT functionality with your existing systems

Conclusion: Three Security Practices Shaken By IoT But Only One Will Fall

As we saw, IoT devices will disrupt three well-established security practices, but only one is likely to fall permanently into the dustbin of history.

Learn IoT Security

Learn how ethical hackers exploit the growing number of internet-connected devices and become a Certified IoT Security Practitioner.

Get Started

• SHAKEN BUT SAFE: Using DMZs, web proxies and email relays.
• SHAKEN BUT SHOULD EVENTUALLY BE SAFE: Using centralized credential management.
• SHAKEN AND FALLING: Using one big Internal Network behind a firewall.

Nonetheless, it pays to do your research on the security attributes and integration points of any IoT device before purchasing it. Without certain key features (like web proxy support and external authentication), the workarounds required to support IoT devices may end up disrupting the security of your network.