Internet of Things Security: Moving Forward

It’s no secret that there’s a lot of worry about Internet of Things security (IoT). Just recently, a drone flew over Austin, TX that detected 1,600 hackable, mostly consumable, devices. And who wants hackers (other than hackers) taking control of baby monitors, cars on the highway, or unlocking doors to homes and offices? On a business level, executives are worried that their data will be stolen, or that they’ll lose control of their devices in the field.

We are an IoT services and solutions provider, and trust me when I say, we understand these concerns. Because connected devices are expected to reach a global population of 20-50 billion in next few years, hacking certainly becomes a lot more scary. If you google something like “iot security concerns”, you’ll find a plethora of results and articles with a “the sky is falling!” mantra. However, rarely do these posts add helpful conversations that help improve IoT security. IoT solutions provide quality business value with reporting, monitoring, and remote control of assets. Because of these capabilities, companies are going to pursue it no matter what. Instead of just voicing concerns, it’s time to start putting forth answers and proactive responses. In this article, I’m not attempting to compile an exhaustive list of IoT security solutions, because security requirements can change by the hour, but this can be a starting point. Approaches to Security Ken North writes that “system architects must focus on security at endpoints and when data is in transit: device security, cloud security, and network security.” Essentially, security must get attention throughout a device’s and a data record’s lifecycle. Wind River says, “Security must be addressed throughout the device lifecycle, from the initial design to the operational environment.” Amazon Web Services’ head of cloud security, Stephen Shmidt describes their approach to security as “job zero” with four areas IoT needs it most: Physical, network, platform, people/procedures. In this article, we’ll add a few extra topics.

Reducing Privacy Concerns

Before we get into the nitty gritty details, there are some other high-level principles that will reduce the problems of security threats.

  1. Only collect data that’s critical to the functionality of the device.
  2. Try not to collect sensitive data.
  3. Collected data should be de-identified or anonymized then properly protected with encryption.
  4. All personal information should be protected.
  5. Only authorized individuals should have access to any personal information.
  6. Retention limits should be set for collected data.
  7. And a disclosure agreement to consumers and customers should be given if data collected is more than what would be expected from a particular product.


Devices might very well be the most difficult layer of an IoT solution to secure. For devices that are out in the field, remotely chirping small bits of information with simple processors and firmware, it’s going to be difficult to control malicious or accidental environments. Schmidt says, “Everything is encrypted. Good security starts with encryption”.  This is true, and with particular device encryptions, they will be as secure as credit cards. It will also require devices to continuously update firmware, and as North says, devices “should include the use of security processors or encryption chips, and even use lightweight encryption for low-bandwidth devices. But others suggest security measure should be in place from the very beginning of a device lifecycle. Wind River writes:

When power is first introduced to the device, the authenticity and integrity of the software on the device is verified using cryptographically generated digital signatures. In much the same way that a person signs a check or a legal document, a digital signature attached to the software image and verified by the device ensures that only the software that has been authorized to run on that device, and signed by the entity that authorized it, will be loaded.The foundation of trust has been established, but the device still needs protection from various run-time threats and malicious intentions.

Device authentication must also be in place. “Just as user authentication allows a user to access a corporate network based on username and password, machine authentication allows a device to access a network based on a similar set of credentials stored in a secure storage area.” And in many instances, devices should require multi-factor authentication and firewall (or ‘deep packet’) inspection abilities to “control traffic that is destined to terminate at the device.” Patches and updates need to be a recurring but for devices performing critical functions, updates cant’ consume too much bandwidth or spotty connectivity so as not to interfere with functional safety. And this process must be scalable to thousands of devices. A few more items about device security that must be take into consideration:

  1. Device must have the ability to update
  2. Update file should be encrypted
  3. Update file should be transmitted via an encrypted connection
  4. Update should not not expose sensitive data
  5. Update should be signed and verified before allowing the update to be uploaded and applied
  6. Update server should be secure


The next level requiring security precaution is the network, or the “in-transit” stage of data-transmission. The OWASP Internet of Things Top Ten Project, reports four requirements exist for a secure network:

  1. Ensure that only necessary ports are exposed and available.
  2. Services should not be vulnerable to buffer overflow and fuzzing attacks.
  3. Services should not be vulnerable to DoS attacks which can affect the device itself or other devices and/or users on the local network or other networks.
  4. Network ports or services should not be exposed to the internet (for example, UPnP).

And as for the Network transportation encryption, it  requires:

  1. Data should be encrypted using protocols such as SSL and TLS while transiting networks.
  2. Other industry standard encryption techniques should be utilized to protect data during transport if SSL or TLS are not available.
  3. Only accepted encryption standards should be used and using proprietary encryption protocols should be avoided.

App Interface

Good visualizations will be a must for a functional IoT solution. Some will simply see their data in current enterprise systems, like Salesforce, which of course means security is already in place. But for more custom projects, secure web interface will require the following (from OWASP):

  1. Default passwords and default usernames should be changed during initial setup
  2. Password recovery mechanisms should be robust and should not supply an attacker with information indicating a valid account
  3. Web interface should not be susceptible to XSS, SQLi or CSRF
  4. Credentials should not be exposed in internal or external network traffic
  5. Account lockout should occur after 3 -5 failed login attempts

Cloud service

Provided that users choose a platform with a proven track record, security at this level shouldn’t be as much of a concern for most. It will soon be common for IoT platforms, like AWS, to require device certification, for making sure every device has a secure connection to their platform. Though this can be a logistical nightmare for configuring and setting up new device batch loads, it will do wonders for a more secure IOT solution. As for the user’s direct interaction with the platform, there are a few noteworthy items. Default passwords and usernames should clearly require a change on the outset, account lockouts should occur after 3- 5 failed login attempts, and it should be coupled with two factor authentication. And the platform should have the capability to log security events and normal actions (via Cloudtrail), and the platform company should always notify users of security-related events/concerns. According to OWASP, user accounts should not be enumerated using functionality such as password reset mechanisms and the cloud-based web interface is not susceptible to XSS, SQLi or CSRF. Lasty, between the user and the platform, there need to be a number of authentication requirements and processes in place:

  1. Strong passwords are required
  2. Granular access control is in place when necessary
  3. Credentials are properly protected
  4. Password recovery mechanisms are secure
  5. Re-authentication is required for sensitive features
  6. Options are available for configuring password controls

A Note from Amazon

We’re not shy in our admiration of Amazon and AWS. It’s justified. In a White Paper of their own, they reported the areas of security risk in IOT and the ways the cloud addresses those concerns: More segmentation, more encryption, strong authentication, more logging and monitoring. In conclusion, they believe

Organizations can be, and probably will be, more secure in the cloud. A thoughtful, properly designed security program will be easier to deploy in the cloud and ultimately lead to lower risk.


We agree with all of the above security measures. It’s lengthy and arduous, but additionally, we strongly believe that every piece of data should be as secure as a credit card transaction. This can be done through requiring  public and private keys for every device. The best way to understand it?

Because the key pair is mathematically related, whatever is encrypted with a Public Key may only be decrypted by its corresponding Private Key and vice versa. For example, if Bob wants to send sensitive data to Alice, and wants to be sure that only Alice may be able to read it, he will encrypt the data with Alice’s Public Key. Only Alice has access to her corresponding Private Key and as a result is the only person with the capability of decrypting the encrypted data back into its original form… As only Alice has access to her Private Key, it is possible that only Alice can decrypt the encrypted data. Even if someone else gains access to the encrypted data, it will remain confidential as they should not have access to Alice’s Private Key.

But even with all these precautions, human error will always remain a concern. According to Zhanna Lyasota, employees will be the biggest threat to digital security.  Companies shouldn’t shy away from IoT or “connected” solutions or services for company operations, but the right processes need to be put in place when using important data. Mistakes, leaks, and malicious infiltrations will most likely occur because of human error, not through faulty technology. That’s why it’s important to use features like CloudTrail, AWS’ robust security approach for standards and device certification:

AWS CloudTrail is a web service that records AWS API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by the AWS service.

Security will always be a concern for every company in any industry. Whether it’s the physical safety of passengers or the privacy of data for a wind turbine, security will always be evolving. If we don’t move forward because of security issues, there will be no advancement. Security shouldn’t stop us. It should propel us forward.

Stay In Touch

Subscribe To Our Newsletter

Please join our mailing list to receive the latest news and updates from our team.