This notice from LifeThings illustrates that the company had no mechanism to modify its
server architecture or update the firmware in the installed hubs to get around the ongoing
attack. The only solution was to physically swap the old hubs for new ones. At the time, it
wasn’t clear what extra precautions or changes to the security architecture were present in the
new hub.
Not many customers took the time and effort to physically mail back their hubs. Many
high-profile citizens simply unplugged the hubs and terminated their LifeThings service. The
secure.lifethings.com server was eventually taken offline and the venture capital firm back-
ing LifeThings refused to provide it with additional funding, causing the company to file for
bankruptcy.
Looking back, it is clear that the engineers who designed the architecture to include the
secure.lifethings.com server did not comprehend security best practices. The organization
did not have an avenue for security researchers to report issues. Even after researchers
exposed the caller ID spoofing security issue, LifeThings did not institute a mechanism for
additional security issues to be reported. They even dismissed Stan Goodin’s analysis, demon-
strating that they had no understanding of it or regard for their customers’ privacy or security.
The product’s architecture was not designed in a way that could withstand a denial of service
attack. The only solution was to issue every customer a new physical hub, the cost of which
was borne by LifeThings, that required customers to mail back the old hubs and install the
new ones.
There are multiple lessons to be learned here:
- IoT device manufacturers and platform service providers have a tremendous responsibil-
ity to make sure their devices can be patched remotely to withstand and prevent basic
attacks. - Words such as “secure” in product or server names do not indicate that the engineers
have experience in secure design or have managed to implement a secure design. It is
important for the proposed architecture to be inspected and assessed by an independent,
qualified third party. - A clearly defined communication process should be in place for researchers who want to
report security issues. - Security issues exposed by researchers should be paid attention to and investigated.
- When not taken seriously, a single security issue—or, as in this case, a series of reported
issues—can seriously hurt the provider’s business and, ultimately, undermine the protec-
tion promised to the customers.
Every IoT device or platform provider may at some point face a situation in which its
architecture is proven insecure in one way or another. This scenario is a clear illustration of
262 CHAPTER 9: TWO SCENARIOS—INTENTIONS AND OUTCOMES