End-to-End IoT Security Evaluation Methods for the Next Decade

DZone 's Guide to

End-to-End IoT Security Evaluation Methods for the Next Decade

Are you properly securing your IoT devices? This post can help you evaluate your IoT security needs. Click here to learn more.

· IoT Zone ·
Free Resource

When testing the security of an IoT network, people naturally take embedded devices as the key test objects. This approach, while convenient, provides only a partial understanding of the entire end-to-end ecosystem. Effective evaluation methods should consider the entire IoT solution or the entire IoT product ecosystem. In short, security teams should evaluate every item in the product security evaluation in the context of the entire IoT product ecosystem.

End-to-End Ecosystem Methodology

The IoT product ecosystem consists of the following aspects:

  1. The relationship between embedded devices and related sensors, receivers, and actuators.
  2. The relationship between mobile applications and command control software.
  3. The relationship between the cloud APIs and related network services. Developers can use a cloud API for encoding, and each API has a service of the cloud provider.
  4. All related network communication protocols in use, such as the Ethernet, 802.11 wireless networking protocols, and inter-component communication protocols (Zigbee, Z-Wave, and Bluetooth).

The following figure shows the complete IoT product ecosystem:

Image title

Security teams must conduct a comprehensive security check on the entire IoT ecosystem to ensure that all related products or components are secure. Failures of any component in the product ecosystem may affect the security of the ecosystem. For example, due to the security vulnerabilities of the cloud APIs, it is easy for hackers to access and control embedded hardware without authorization. Consequently, they can launch malicious attacks on users' IoT products, such as refrigerators and DVDs, among others.

We will show how to conduct a complete IoT security evaluation, covering every aspect of the IoT product ecosystem.

Configuring the Security Test Environment

When testing the IoT product ecosystem, we will first configure various functions of IoT products under the common product specifications. To achieve better test effects, we need to configure two mutually independent Internet product-running environments to test the danger of attacks. This is because hackers may implement cross-user or cross-system attacks on two independent environments. Besides, we can use the two independent environments to compare security configuration of products. By testing the functions of each product, we can efficiently evaluate functional security features, component features, and the communication path of every product in the product ecosystem, thus covering the entire IoT product ecosystem.

In addition to testing, we will also need to obtain all IoT information related to the tested product. This kind of data includes the information about the related product components, infrastructure that supports running of the product, support software required for running the product, and external components that are used to implement various cloud functions of the product.

Cloud Security Test

An IoT network typically uses various network services for remote control, data collection, and product management. Generally, network services and cloud APIs are the weakest parts of the IoT product ecosystem. Developers can use cloud APIs for encoding, and each API has a service of the cloud provider. Meanwhile, cloud APIs may bring security risks to cloud applications, because threat actors can easily attack APIs putting sensitive service data at risk. This means that providers and software developers must determine the security of cloud APIs on priority.

Therefore, to ensure authentication security on the cloud, we need to test functions of and communications between the cloud service and all components in the IoT product ecosystem, to perform a comprehensive evaluation on the related cloud service. In this way, we can verify the general security status of the product and confirm security problems that are caused by the cloud. Consequently, we can evaluate the impact of these problems on security between the components.

Additionally, we will use OWASP Top10 for the focus test during the cloud test.

Note: Open Web Application Security Project (OWASP) is an open community dedicated to the discussion of applications and code development threats. OWASP Top10 aims to locate the top 10 risks faced by enterprises or organizations to increase people's concerns on security of applications.

Mobile Application or Control System Test

The IoT technology often uses various types of remote control services, such as mobile applications (Android or iOS), to remotely manage and control IoT. In this test process, we perform an in-depth test and analysis of the mobile and remote applications that are used to manage IoT products. Like the cloud test, we test all functions of and communications between mobile applications and all components in the IoT product ecosystem to verify the general security state of the product. Also, we will use OWASP Top10 for the focus test during the mobile application test.

IoT often uses standard network communication paths, such as Ethernet and Wi-Fi, to access various services. This is convenient, but it also introduces many risks. In this test phase, we are going to identify all TCP and UDP ports in the IoT ecosystem infrastructure that are connected to the product. Through these ports, we can conduct a thorough penetration test to identify services that are vulnerable to attacks or have configuration errors. Hackers often use these service vulnerabilities to attack the IoT system and obtain key access information.

IoT Device (Hardware) Security Test

We will also check IoT devices to evaluate security against the physical layer attacks. Checked objects also include devices with the JTAG port and serial port, power devices of various components, and data and control pins. Although devices have different components or configurations, they have some common attack vectors, for example:

  1. External USB port
  2. Access from external channels
  3. Location and storage media
  4. Access availability of the debug console
  5. Operations required to disassemble a device
  6. Risks caused by simple physical access to devices
  7. Risks caused by extended physical access to devices
  8. Risks caused by connection media, such as wireless connection, wired connection, and Bluetooth

The physical check of a device is the key to thwarting physical attacks. As mentioned earlier, after checking each component of the device, we can start the physical attack test. Although the attack media may be different, the measures and methods are the same as we have listed above:

  1. Initiate attacks through available ports
  2. Disable equipment protection, for example, 'boot loader' restriction or restricted BIOS
  3. Access and modify the device configuration
  4. Steal users' access credentials when users are using the cloud service
  5. Access firmware that is only accessible by users
  6. Monitor operations by accessing the background or run logs when the device is communicating with the cloud component

Currently, most of the IoT devices still rely on radio communication. Testing security of the communication methods is also a key task of security evaluation. For this purpose, we conduct dedicated tests and analysis on radio communication to check whether communication meets the following expected encryption and protection requirements:

  1. The assembly pairing process is tamper-proof.
  2. The system prohibits unauthorized access or control.
  3. It is difficult for hackers to map communication with the bottom-layer commands and control traffic.
  4. It is difficult to initiate a rebroadcast attack.


We hope that this article will provide a fresh perspective to cybersecurity practitioners for evaluating security in the world of IoT devices.

security ,trends ,iot ,endtoend ,cloud ,test

Published at DZone with permission of Leona Zhang . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}