Operations

9/27/2016
05:00 PM
Mark Benson, CTO, and Brian Ericson,
Mark Benson, CTO, and Brian Ericson,
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

5 Best Practices For Winning the IoT Security Arms Race

By focusing on a pragmatic approach to security, it's possible to develop IoT solutions that will reduce future risk without breaking the bank.

Internet of Things (IoT) security is an arms race between the companies developing IoT solutions and the hackers who see value in compromising those solutions. It’s a race hackers are handedly winning in large part because companies—and consumers—haven’t yet taken IoT security seriously. While the race favors the hacker, it's nevertheless possible to "win" via pragmatic strategies that minimize risk.

IoT security is comprised of components (e.g., sensors, devices, gateways, servers), the communication between these components, and the data they store. Securing each component, however, presents unique challenges and considerations. Transport Layer Security (TLS) can secure communication, for example, but low-powered sensors and devices are often ill-equipped to negotiate TLS sessions.

Additionally, companies often have little control over the security of third-party components such as the cloud-hosted servers with which their devices communicate, and must rely on third-party vendors to adequately defend against and respond to attacks. These vendors may lack a satisfactory security architecture, appropriate incident response plans, and transparency about security with customers.

Amidst all of this is the reality that security must be balanced against other requirements. Mitigating against potential physical and remote attacks typically impacts other aspects of the IoT solution, like cost, form factor, power consumption, and user experience, all of which must be taken into consideration. Meanwhile, security itself is a moving target, with attackers constantly developing new attacks; an adequately secure IoT solution today will likely not remain so throughout its useful lifespan.

Although companies will never be able to declare total victory over hackers, it is still possible to "win" the arms race via a balanced and thoughtful approach to security that reduces the value of hacking an IoT solution below the cost of actually doing it. Such a strategy will focus as much on mitigating exploits as on preventing them. Here are some best practices:

  • Ask questions. Attackers may target any component of an IoT solution to accomplish any number of goals, including accessing data, controling components, and disrupting service. It is critical to both understand how an IoT solution might be compromised and what a hacker might gain in doing so. Once understood, mitigation strategies will necessarily vary by component and solution—light bulb security, for example, will differ from that of medical device security. Be aware that mitigation strategies themselves might introduce new risks. Firmware updates, for example, might fix vulnerabilities, but could allow an attacker to inject malicious software.
  • Constrain the scope of potential threats. Consider threats to each component in the IoT solution. Would, for example, a potential compromise affect a single device or the entire fleet? Would an exploit require physical access or might it be executed over the Internet? Does it allow the hacker to falsify data, control devices, or alter the solution's behavior? Favor security strategies, like device-specific authentication against a server, for example, that can only be beaten by physical attacks, only compromise individual units, and that minimize resulting damage.
  • Collect and act on anomalous behavior. Servers, in contrast to other components, generally have "infinite" bandwidth, memory, storage, and computation power. Take advantage of this! Server-side logging, for instance, provides transparency essential to troubleshooting anomalies, including suspect sensor readings, questionable control requests, and unexpected communication frequency. Servers capable of detecting and acting on anomalies are invaluable.
  • Include user validation of critical functions. In the same manner credit card companies might ask for verbal confirmation of recent charges, consider incorporating user validation for critical functions and to validate anomalies. Validation can entail everything from acknowledging a notification to physically interacting with components.
  • Secure data against unauthorized access. Data stored in components ("data at rest"), communicated between components (“data in motion”), and shown to users via interfaces and APIs ("data in use") will be targeted by hackers hoping to access, forge, and disrupt it. Data in motion can be secured via TLS, assuming the component supports it, and data in use should incorporate authentication and access control. Data at rest, which includes passwords and keys, can be the most difficult to secure and may necessitate encrypting the data itself to prevent a successful compromise from yielding usable information.

Insecure IoT solutions are, initially at least, cheaper to build, and it's possible that sites like shodan.io, which, among other things, allows users to watch video feeds from insecure webcams, simply reflect the kind of security companies and consumers are willing to live with relative to what they’re willing to invest. Conversely, secure solutions are more costly upfront but much less likely to result in eventual catastrophes. However, by focusing on a pragmatic, effective approach to security, it is possible to produce secure IoT solutions that will reduce future risk without breaking the bank now.

Related Content:

As chief technology officer, Mark Benson navigates emerging Internet of Things developments and leads Exosite's technology strategy to fuel its industry leadership and growth. Prior to joining Exosite in 2012, Benson was the director of software strategy at Logic PD, where he ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
How the US Chooses Which Zero-Day Vulnerabilities to Stockpile
Ricardo Arroyo, Senior Technical Product Manager, Watchguard Technologies,  1/16/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "He just showed up at my doorstep one day without a geotag."
Current Issue
The Year in Security 2018
This Dark Reading Tech Digest explores the biggest news stories of 2018 that shaped the cybersecurity landscape.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-3906
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 contains hardcoded credentials in the WCF service on port 9003. An authenticated remote attacker can use these credentials to access the badge system database and modify its contents.
CVE-2019-3907
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 stores user credentials and other sensitive information with a known weak encryption method (MD5 hash of a salt and password).
CVE-2019-3908
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 stores backup files as encrypted zip files. The password to the zip is hard-coded and unchangeable. An attacker with access to these backups can decrypt them and obtain sensitive data.
CVE-2019-3909
PUBLISHED: 2019-01-18
Premisys Identicard version 3.1.190 database uses default credentials. Users are unable to change the credentials without vendor intervention.
CVE-2019-3910
PUBLISHED: 2019-01-18
Crestron AM-100 before firmware version 1.6.0.2 contains an authentication bypass in the web interface's return.cgi script. Unauthenticated remote users can use the bypass to access some administrator functionality such as configuring update sources and rebooting the device.