The majority of popular use cases, such as an event triggered by a door opening or a
motion sensor detecting activity in the middle of the night, are clearly aligned toward protect-
ing our safety. In cases in which our physical safety is the paramount issue of concern, it
becomes extremely important that the technology supporting and enabling it be designed
securely. In this chapter, we discussed why products like those offered by SmartThings need
to enable authentication that goes beyond the traditional username and password approach.
We’ve learned the hard way why a mere password is not enough to protect our online
accounts, and we can’t risk doing the same with devices that are put in place to ensure our
physical safety.
A popular concern with IoT devices is the ability to issue security patches to fix known
security flaws. Security researchers have pointed out a major weakness in the SmartThings
Hub that can lead to a man-in-the-middle attack, which was duly patched by SmartThings.
This is a good example of IoT device manufacturers doing the right thing, by communicating
with security researchers and diligently issuing firmware updates to their customers to rem-
edy the issues that are identified.
We also studied how the powerful SmartThings developer IDE can be tied with traditional
technologies, such as text messaging, and how this can be abused to spoof messages to users
to scare them or to distract them. As we enable further IoT sensors in the home, we ought to
think through all the various avenues of notifications and communications and have a strategy
for gradually retiring traditional mechanisms such as text messaging. Such an approach
might have to be more gradual than we’d like, given spotty data coverage in some areas. How-
ever, it is important that we begin to have the discussion now and educate users on the cur-
rent shortcomings.
Unlike the Philips hue lighting system and the WeMo suite of products, the SmartThings
Hub and devices do not connect directly. Instead, they connect to an external cloud infrastruc-
ture and exchange instructions. The SmartThings architecture is therefore less likely to fall
victim to another rogue device on the same local network, because there is no implicit trust of
local devices.
Given the frequency of successful phishing attempts and workstation compromise due to
malware, this is a welcome design decision, because it keeps the SmartThings devices from
falling prey to other infected machines on the same network. However, the SmartThings
approach to this design does not stem from a conscious intent to be secure, but rather is more
of a side effect of going to market with dependability on the cloud as the first step:
We made the decision at SmartThings to support a “Cloud First” approach for our platform. This
means that in our initial release, there is a dependency on the Cloud. SmartApps run in the
SmartThings Cloud, so for everything to work, your hub does need to be online and connected to
our cloud. This will generally be the case, even when we implement hub-local capabilities as
described below.CONCLUSION 119