DevOps Plays A Key Role In IoT Security

Get Dad Something Smart for Father’s Day
June 15, 2017
IoT DevOps For Continuous Integration
June 22, 2017
Show all

This is the fifth in a series of Arrayent blog posts on IoT security. The series is written for employees of companies who sell connected products, especially those new to IoT. With this series, we hope to bring a basic level of awareness and understanding of key issues that face everyone who develops connected consumer products. We also hope to stimulate an ongoing dialog that helps move the conversation about connected products security forward.


DevOps best practices play a key role in IoT security.

If the world has learned anything from the high-profile connected device hacks of the past year, it’s that IoT security cannot be an afterthought. Security has to be baked-in to all aspects of business and technology, especially for consumer brands because the very public risks are far too great if devices get hacked and customers become vulnerable. One high-profile hack and your brand is front page news. That could spell DISASTER and is worth looking at from the viewpoint of software DEVelopment and information technology OPerationS: i.e. DevOps.

There are fundamental differences in product development practices that should be followed when creating Internet-connected devices versus unconnected hardware. One of the unique challenges connectivity poses is realizing that the manufacturer is responsible throughout the entire lifetime of the product. This includes managing, updating, and maintaining existing device software along with firmware updates and any connected applications. This not only creates ongoing costs, it creates new challenges for groups responsible for testing, support, security, privacy, compliance and in-field maintenance.

Presumably, the business model that underpins each connected product has been designed to take all of this into account, ensuring that the ongoing costs are more than offset by ongoing revenue and profits (e.g. from cost efficiencies, consumable or accessory sales, etc.). However, long-term security costs are often misunderstood and go unaccounted-for, becoming an ‘ugly surprise’ to the product plan. That’s why security efforts must start in the design phase for connected products and move all the way from development to deployment, through DevOps processes and activities, and to associated application monitoring and management.


The Cloud Security Alliance (CSA) released a detailed report: Future-proofing the Connected World: 13 Steps to Developing Secure IoT Products in 2016 to help designers and developers of IoT products and services understand the basic security measures that must be incorporated throughout the development process. It’s an excellent and meaty primer that is recommended reading for all those developing connected products. In a nutshell, the top five best security engineering practices identified in the report are as follows:

  1. Design and implement a secure firmware/software update process.
  2. Secure product interfaces with authentication, integrity protection, and encryption.
  3. Obtain an independent security assessment of your connected products.
  4. Secure companion mobile apps and/or gateways that interoperate with your connected products (e.g. encryption/privileges/authentication).
  5. Implement a secure root of trust for root chains and private keys on the device.


Based on our experience, here are key considerations to ask about when vetting an IoT platform partner, specifically in regards to their IoT development processes and practices:

  • Does the platform partner have experience that is applicable to your specific category of connected product?
  • What are the platform partner’s software development methodologies, processes, and tools? Do they follow a secure software development methodology?
  • How robust is the platform partner’s development environment? Does the back-end architecture automate testing and upgrades? Do they provide full visibility into the development cycle as well as a single repository to track changes?
  • What are the platform partner’s security features for data storage, transmission, redundancy, recovery, and more?
  • How does the platform partner handle device management? Do they provide device unique IDs, AES-keys, user binding, firmware versions, etc.?
  • What are the platform provider’s user management capabilities: i.e. for passwords, password resets, device binding, account details, etc.?
  • How does the platform partner handle failure scenario testing, code review, QA, vulnerability analysis, and remediation?

If we have opened your eyes to some questions to ask about IoT security and gotten across that it is your job to ask them when vetting an IoT platform partner, then we have succeeded in our goal. Next week we will dive a bit deeper into some critical areas of DevOps security processes. Until then, if you want to know more about us, visit: