Written By

Aaron Kamphuis



Written By

Aaron Kamphuis



Stay up-to-date with OST blog posts.

September 13, 2016

This post is Part VII  and  the final post of the “IoT… are we all doing it wrong?” series. Check out Part I,  Part II, Part III, Part IV, Part V, and Part VI.

An attack on an IoT device is inevitable. It is up to the project team to set parameters in place to help mitigate these risks and handle a breech if it happens. This article will explain different aspects of security to keep in mind while working to develop an IoT project.


PEN Testing

Penetration (PEN) testing has been a practice in IT since the late 1960’s. PEN testing’s approach is to attack IT systems using known techniques, searching out and triaging vulnerabilities before black hat hackers uncover and exploit them. It is estimated that cyber crimes will cost the global economy $445 Billon in 2016. PEN testing is a valid and recommended approach for traditional IT systems. There are security departments and security vendors that have built amazing amounts of knowledge, experiences and services that deliver PEN testing at scale. However, these approaches have targeted IT systems that are built mostly from out of the box hardware, and IT infrastructure and software that mostly lies within a walled garden. IoT systems are much more complex in terms of architectural design, custom hardware / firmware solutions, and custom software, as well as the speed in which these solutions evolve over the lifetime of the product.


Physical Access

A typical IT solution’s physical address is a very secure location. Access is controlled through very mature processes that use a combination of security personnel and building access controls. One data center that I have visited has external fences that would repel the largest of trucks, crumble zones, armed guards, and retina scanners, to name a few of the protections in place.

Can you imagine if we told the security architects of that solution that we were going to take a key part of the architecture, make millions of them and send them to anyone to anonymously purchase? One could imagine their reaction, and it would not be favorable. One also could assume that the processes they have in place aren’t geared for that scenario.

Physical access allows hackers to tear the durable apart, looking for hardware vulnerabilities that would allow them to access the firmware, as well as any security mechanisms utilized within the durable. Compromising the durable onboarding process offers a hacker a great opportunity for unauthorized access to the IoT platform. Once they have access, they will use this access to manipulate any or all of the features afforded to the device to take advantage of the IoT platform. If the implementers of the IoT platform haven’t used a good approach to lock down durable permissions, they may be able to call services that are much more dangerous that the developers imagined.

Another factor to consider is that durables typically are designed to be low power / low cost devices. As such, there are limited resources that the durable can dedicate to security. Ensuring that the design team is striking the right balance between performance, cost and security is crucial.


Approach and Team Makeup

IoT projects have many different components in their architecture. IoT solutions typically involve a durable, a mobile application, cloud/cloud connectivity, and a web application, as well as integration back to an organization’s existing IT infrastructure. Depending on the component, there may be different approaches to design and development. For instance, hardware/firmware may have a multi-year waterfall prototype approach for development to production. Other component teams may follow an agile approach. Regardless of the approach each component team uses, the security activities should be built into the design, implementation and long term lifecycle of the IoT platform.


The IoT team should engage multiple security professionals that specialize in the following areas:

– Hardware design and implementation

– Firmware

– Mobile development

– Web development

– Cloud development

– Cloud infrastructure implementation

– Authentication and Authorization


Activities may include:

– Design review and recommendations

– Code review and recommendations

– Threat modeling and test design

– Security test execution

– Design long term security policies and procedures


The security team at Microsoft have developed 6 categories for classifying security threats, called STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Attackers can use any combination of these hacks to compromise a system. Security professionals will evaluate a system’s architecture, use their understanding of common hacking techniques and these classifications to develop threat models. Threat modeling not only will identify potential security issues, but also help develop mitigation approaches to minimize the effects of an attack.

Securing the whole ecosystem

A security strategy cannot only focus on each subsystem, it must consider the ecosystem as a whole. IoT systems use technologies such as: Wi-Fi, Bluetooth, and cloud connectivity. These integration points can be exploited by attackers. Developing flow diagrams on key activities including device provisioning, account creation, etc. will help outline areas that have potential vulnerabilities.

An Introduction to All the Basics of Bluetooth Low Energy (BLE)

Protecting your User’s information

Personally Identifiable Information (PII) should be handled with care. The most secure approach is to minimize or avoid storing PII. For example, a platform could integrate to a 3rd party identity management system. Another approach would be to store PII on secure local storage on the mobile app. If a platform must store PII, this information should be encrypted. Also, users should have an option to “exit” the platform, permanently scrubbing PII. Many localities have PII regulations. A global IoT deployment may have to make special provisions for local PII regulations.

Successful hacks can result in the following: information leaks, user information theft, compromise of intellectual property, system stability, data loss and others. A security breach can be catastrophic for end users, products, and companies. One potential risk that IoT device manufacturers need to consider is that their device, attached to a customer’s network, could become a backdoor to compromise internal systems. This scenario is similar to the Target data breach.

An attack on an IoT system is inevitable. We owe it to our stakeholders to be responsible enough to implement security best practices for an IoT project. The project needs to have processes to test for new vulnerabilities, proactively address security issues and have a plan in place in case of a security breach.

OST is one of the few AWS IoT Competency holders in the world. This distinction points to our unique expertise in connected products.



Stay up-to-date with OST blog posts.

About the Author

Aaron Kamphuis has spent 20+ years in data analytics, application development, cloud architectures and software testing with a background leading development teams in the use of cutting-edge technologies to satisfy unique business/end user requirements.

Aaron spent several years with Sagestone Consulting Inc., where he worked with his partners to build out 65+ people for a multi-million dollar application development services organization.

At OST, Aaron and his teammates have worked with clients to build global scale IoT solutions, Data Analytics solutions for packaged software, and companies that range from large multi-national enterprises to small businesses.