Embedded systems and the Internet of Things (IoT)

Developing applications for embedded systems and the Internet of Things (IoT) requires more than just software development. Because there is a “thing” involved, the hardware matters. And, of course, the user matters. And, because we write more than just code, the marketability of the product matters.

internet of things (IoT) icon
internet of things (IoT) icon

IoT areas of risk:

  • Network defense

  • Device defense

  • Application defense

  • Shared threat intelligence

  • User-created issues

When we develop IoT applications and products, we often find we are working with clients who are experts in their industry, having developed the hardware (the “things”) that they now want to transform into intelligent sensing, communicating, and control devices. This development requires more than just adding technical functions to the “thing” or connecting it to the internet. There are still those considerations involving market readiness, goals, functions, cost, platforms and, often most importantly, usability of the application being used to sense, communicate, and control.

Contact us
Contact us

There’s also the reporting function, something that is almost always overlooked by coders who aren’t looking at the whole picture. Once the data has been gathered, someone in the field or in management will want to make sense of it and make appropriate operational and business decisions. Dumping a CSV file is rarely the answer. How will that data be presented? Sorted, filtered, or otherwise manipulated? How often should it be displayed or distributed? What kind of value is the customer expecting to get from that data? How easy can it be for them to do something meaningful with the data?

Finally, coders often miss that high-quality code and high-quality security need to be woven together to create an application that is truly secure. When the application is high-quality, the code does what it is supposed to do. When the application is secure, the code does not do what it shouldn’t do.

Get started

Areas of risk for an Internet of Things application

Areas of risk for an Internet of Things application

This aspect should be covered external to the device by intrusion detection systems (IDS), which monitor a network for unauthorized activity; intrusion prevention systems, which follow traffic to prevent network vulnerability exploits; firewalls; and antivirus scanners.

This includes simple things such as password protection, policy management, and patching systems to keep up-to-date with new security protocols. Two-factor authentication should be employed whenever practical. For example, withdrawing funds from an ATM requires both a debit card and a PIN; having one or the other is not enough.

Security standards should be in place during the development process. Vulnerabilities should be found during the development stage, not after the application is completed. Third-party code that is embedded into the application—especially open-source libraries—should be scrutinized for vulnerabilities. Any software that is purchased to help produce the application—indeed, any that is used on terminals upon which the application is developed, including things unrelated to it—should also be held to high security standards. Even things like third-party browser toolbars should be monitored closely to make sure they do not represent a security risk. Finally, the application should be protected by a firewall.

It’s extremely important for developers to share information concerning cybersecurity threats. Not only could learning something new protect your own application, but any information you provide may also help another developer do the same. The Information Technology Information Sharing and Analysis Center, or IT-ISAC, is an invaluable resource for developers to help prevent cyberattacks, as is the Common Vulnerability Enumeration (CVE).

Users themselves will often unknowingly create vulnerabilities within an application’s infrastructure. For example, users often will only keep a few simple passwords to access multiple applications and accounts; their email password is usually the same as the one they’ll use when they shop on Amazon, or when they access their banking information online. A vulnerability in one account, even if it’s entirely unrelated to your application, can create a security risk for others because of this. Your users need to be educated as best as possible to maintain a secure environment for themselves and other users.

Network Defense

This aspect should be covered external to the device by intrusion detection systems (IDS), which monitor a network for unauthorized activity; intrusion prevention systems, which follow traffic to prevent network vulnerability exploits; firewalls; and antivirus scanners.

Device Defense

This includes simple things such as password protection, policy management, and patching systems to keep up-to-date with new security protocols. Two-factor authentication should be employed whenever practical. For example, withdrawing funds from an ATM requires both a debit card and a PIN; having one or the other is not enough.

Application Defense

Security standards should be in place during the development process. Vulnerabilities should be found during the development stage, not after the application is completed. Third-party code that is embedded into the application—especially open-source libraries—should be scrutinized for vulnerabilities. Any software that is purchased to help produce the application—indeed, any that is used on terminals upon which the application is developed, including things unrelated to it—should also be held to high security standards. Even things like third-party browser toolbars should be monitored closely to make sure they do not represent a security risk. Finally, the application should be protected by a firewall.

Shared Threat Intelligence

It’s extremely important for developers to share information concerning cybersecurity threats. Not only could learning something new protect your own application, but any information you provide may also help another developer do the same. The Information Technology Information Sharing and Analysis Center, or IT-ISAC, is an invaluable resource for developers to help prevent cyberattacks, as is the Common Vulnerability Enumeration (CVE).

User-Created Issues

Users themselves will often unknowingly create vulnerabilities within an application’s infrastructure. For example, users often will only keep a few simple passwords to access multiple applications and accounts; their email password is usually the same as the one they’ll use when they shop on Amazon, or when they access their banking information online. A vulnerability in one account, even if it’s entirely unrelated to your application, can create a security risk for others because of this. Your users need to be educated as best as possible to maintain a secure environment for themselves and other users.

We typically do a physical mockup for Internet of Things applications. Our team members have significant mockup experience, from the simplest device to things as complex as aircraft cockpits. Usability is not a niche aspect of product development; it is essential to commercial success. We are eager to hear from you.

Get started today!