Home/ Blog/Security

Security’ Category

Who Is Responsible for IoT Device Security?

Posted on:

If this was a test question on a college exam, you would have a set of multiple choice answers, such as:

    A. The device manufacturer that initially builds the device.
    B. The device integrator, who builds the device into an end-user product.
    C. The value added reseller that distributes the device to consumers.
    D. The customer, who installs or sets up the device or third-party product in the end-user environment.
    E. All of the above.

The answer may be surprising to some, but it is of course “E. All of the above.” Everyone along the chain from manufacturing to integrating and using the product plays a role in ensuring that the device is properly set up to thwart improper access, device hacking and malware attacks.

Many people believe that security can be fully implemented by the device manufacturer, or that it’s possible to install a security-focused software program to detect and thwart hacking. But in fact, true device security is a combination of technologies, processes and best practices.

Why Device Security Requires a Multi-Pronged Approach

There are several key reasons why device security requires multiple technologies and practices across the chain from manufacturing to end-use:

  1. Each enterprise has a different security requirement. Retail and financial institutions that process transactions need a high level of security to protect customer data. Healthcare organizations that handle sensitive personal information also require a very high level of security. At the other end of the spectrum, there are many use cases in which extreme security is not required, and it does not make sense to take the extra measures, as it results in additional cost to the consumer.
  2. The threats change. The technologies and practices in use today may not be enough to thwart the attackers of tomorrow. See our previous post, Lessons Learned from the KRACK Vulnerability, for additional insights.
  3. Consumers do not want to pay for the amount and type of built-in security that businesses require.

Device Security from the Manufacturing Perspective

In this post, we will talk specifically about the key security measures that should be designed into the product by your device manufacturer if you are a product integrator or value added reseller, so that others further down the chain can implement proper security. For example, if you are seeking to incorporate one or more vendors’ embedded modules and radio frequency products into your product design, it is important to review the security measures taken in the manufacturing phase.

In these instances, the devices must enable secure functionality. The device manufacturer’s responsibility is to build in secure features, which can then be implemented by the integrator or end-user. As a best practice, the manufacturer should include a comprehensive set of controls that can be enabled as needed. These controls are essentially the laws that govern the product and ensure it behaves in a secure manner. In this article, we refer to this set of controls as a “manufacturer security framework.”

To demonstrate, let’s look at some specific examples.

Example 1: A Security Feature Implemented Within a Device

In this example, we will discuss a feature called “secure boot.” The intent of secure boot is to make sure no unauthorized code ever runs on the device. At Digi, for example, we have defined a number of controls within our manufacturer security framework for this purpose.

The controls we have assigned to secure boot include the following:

  • When the device boots, all code objects that are loaded are cryptographically verified as coming from the device manufacture.
  • When software is updated, all updates are cryptographically verified as coming from the device manufacturer.

While we require the secure boot control, our developer has many technical options for how to implement it. For example, when sourcing a manufacturer’s CPU, our developer must first evaluate the capabilities of that component to determine how to implement the control. In the case of secure boot, if the CPU offers the High Assurance Boot (HAB) feature, the Digi developer can implement the HAB on the product under development to meet the secure boot control requirement.

This security framework ensures that a full range of critical security controls is built in during the development of the product, but still provides the developer with some choice as to the method. When all security controls are in place and development is complete, each of these controls must then be tested and validated.

Example 2: A Security Feature Implemented by the End User

Another example of a secure code feature is the ability to do code validation on end-user code that runs on a device. With the future trend of edge computing, code validation and the infrastructure to support this on an edge device is becoming critical. Validating scriptable end-user objects does not happen at the manufacturer’s level, but at the end-user level. The manufacturer needs to support the functions to make this happen. End-users must then enable these functions on their devices and code upon deployment.

It is important to note that it is the validation of a control that ensures secure operation. This happens not only at the manufacturing level, but across all phases of product implementation. For a set of framework controls for end users to implement for device security, see the Center for Internet Security (CIS) site at www.cisecurity.org.

Digi’s framework of manufacturer security controls, called Digi TrustFence™, includes:

  • Secure boot
  • Authentication and secure connections
  • Encrypted storage
  • Secure updates
  • Certificate and policy management
  • Protected hardware ports
  • Device identity
  • Ongoing monitoring and support

The Digi TrustFence™ solution is not a single security feature, such as a software program that can be hacked. It is a multi-pronged approach designed to ensure that devices are secure from common attacks, and that device integrators and end users have the ability and functions needed to establish a secure configuration in deployment.

The intent of Digi TrustFence™ is to start the secure IoT story from the manufacturing perspective. If you are an integrator, or application developer, there are similar security frameworks such as the OWASP top 10 (www.owasp.org) for security controls on IoT devices. These frameworks provide controls that can be implemented at multiple phases from the manufacturer to the end user.

To continue this story, your own organization must assess what you have in place for a security framework. Does your organization have a set of published best practices? Does your supplier offer a security framework for its customers? Are you fully implementing all available controls to avoid any single point of failure?

>>Take a look at  Digi TrustFence for more details on how to solve security challenges across the IoT landscape.

Lessons Learned from the KRACK Vulnerability

Posted on:

The KRACK Wi-Fi vulnerability issue of October, 2017 reminded us all, once again, that security should be top of mind for anyone responsible for device security and network communications. KRACK (Key Reinstallation Attack) involved an issue with the WPA2 protocol, which encrypts Wi-Fi traffic for a huge majority of devices and routers today. In other words, this issue impacted almost everyone with a computer.

What can we learn from this?

Image credit: Wikimedia Commons

Lesson 1: Security flaws are no surprise

Unfortunately, these issues are expected, as they are a predictable reality in the world of wireless communications. But there is a silver lining. This knowledge empowers us to establish and follow best practices. The key lesson here is not a news flash that security is critical. It is simply a reminder: under no circumstances should you rely on any one security method to protect your network from attacks.

A typical network follows the OSI 7-layer communication model*, and each of these layers can employ security measures. The layers include:

  1. Physical layer: The functions at the hardware level. The primary purpose of this layer is to define physical signals responsible for transmission through the medium that supports the communication.
  2. Data link layer: The layer responsible for defining the protocol for direct node-to-node bit-level data transfers. The protocols can include the 802.11 wireless protocols between the station and the access point. Communication types, such as Wi-Fi or Ethernet, can vary in this layer. The KRACK vulnerability occurred at this layer.
  3. Network layer: The layer responsible for handling data in a multi-node network and managing communications between hosts that employ various protocols. An example protocol is Internet Protocol (IP) version 4.
  4. Transport layer: The layer that handles flow control of data. This is typically seen as the TCP layer.
  5. Session layer: The layer that handles communication sessions and authentication via common application protocols.
  6. Presentation layer: The layer that converts incoming and outgoing data into another presentation format, and can decrypt encrypted data. This layer is typically where the SSL/TLS encryption streams occur.
  7. Application layer: The layer that handles formatted application data input and output with applications such as email clients and web browsers.

*Note that we’ve take some liberty with the definition of the TCP/IP protocols and the OSI 7-layer model. TCP/IP does not fit nicely into the OSI model. However, we find that using the OSI model is critical in reviewing security in networking and applications.

Lesson 2: Employ the “security in depth” best practice

In a truly secure application, security occurs at multiple layers, and minimally at the data link, transport and presentation layers. Your application’s security strategy must not rely on any one layer. Each of the layers in this model can and will fail, sometimes spectacularly.

Therefore, a best practice is to monitor and implement industry standard security methods in as many of your networking layers as possible. When a security vulnerability or attack targets one of the layers, you will then have other robust measures in place. These measures are your “get out of jail free” card when one layer is compromised.

Let’s look at Wi-Fi and the KRACK vulnerabilities as an example. With Wi-Fi, your data is transmitted from your device to the access point, and no one can read or decode it. By contrast, if everyone is connected with a network hub you can effectively see each other’s traffic. The KRACK vulnerability, which affected all systems that implemented the WPA/WPA2 standard, allowed everyone to effectively see your traffic in the same manner, as if they were on the same wired network. With Wi-Fi (at the Transport layer), you can’t control a rogue station listening to the Wi-Fi radio signal. For this reason, you must have security protocols such as the WPA/WPA2 standard to encrypt the traffic. Further, if you also have the most up-to-date TLS session-level protocols,  you are protected even in the event of a Wi-Fi vulnerability.

Lesson 3: The lifetime of every security measure is limited

Security methods do expire. Since security vulnerabilities can and do occur on a frequent basis (typically measured in months, not years), the standards for protecting our networks and data must be updated regularly. The networking industry has been repeatedly­­ hit with headline makers, such as the POODLE issue that compromised SSL and TLS 1.0, as well as many other attacks on authentication, certification and verification methods across multiple layers and communication methods.

As the security protocols and standards change, it is up to enterprises and their network managers to employ those updates to protect their systems and networks.

Lesson 4: Work with product vendors who are committed to security

Because security requires a multi-pronged approach, not only is it important to ensure that your networking policy is robust, but also that the products you incorporate into your systems are engineered for security.

Meet Digi TrustFence™

The TrustFence™ model, which Digi began putting in place to combat the rise of IoT security issues and concerns, incorporates security methods such as authentication throughout a product’s functionality. The TrustFence approach is two-fold:

  1. Develop products that incorporate features to mitigate the most common security vulnerabilities and attacks against devices.
  2. Commit to keeping up to date on security lifecycle continuous improvement.

Choosing products built on this model enables you to easily integrate device security, device identity, and data privacy capabilities into your systems and designs.

In summary

While being “bullet proof” may not be a realistic goal, it is critical to create a robust strategy that helps you prepare for and respond to security issues, before they occur and when they occur. This includes maintaining updated standards across multiple networking layers, and incorporating products that are engineered to adapt to security threats as they evolve.

>>Learn more about Digi TrustFence™


How to Balance IoT Security for Embedded Solutions

Posted on:

When considering embedded IoT solutions, security is a balance between three parts that are often in tension: economic cost, benefit, and risk.

  • Cost – Pertains to the price for designing security into industrial applications versus “bolting” it on, the urgency of time to market, and the value of your brand’s reputation.
  • Benefit – The benefits of integrated security allow you gain immediate access to critical features such as secure connections, authenticated boot, encrypted data storage, access-controlled ports, secure software updates, and seamless integration of the dedicated on-module Secure Element (SE).
  • Risk – With remote and distributed wireless networks, hackers do not need physical access to devices such as USB outlets or network ports, putting remote industrial applications even more at risk to communication attacks, software attacks, invasive hardware attacks, and non-invasive hardware attacks can be classified in terms of investment, the type of attacker, and equipment involved.

Designing and building connected products can be accelerated by using a secure and cost-effective System-on-Module (SOM) platform, a surface mount form factor that provides simple design freedom with unlimited access to interfaces, and out-of-the-box integrated security that is reliable, allowing you to focus on accelerated product development and delivering products that take advantage of the benefits of connectivity.

To help designers and builders effectively respond to the IoT security mandate, Digi experts developed Digi TrustFence™, a fully integrated, tested, and complete Linux device security framework. The built-in security of Digi TrustFence provides immediate access to critical features and easy integration to handle security for your embedded IoT device.

>>Check out this IoT Device Security Technology Brief to protect your embedded devices with a balanced security framework.

Internet of Things Device Security: Five Simple Steps (video)

Posted on:

Device security is a critical and complex step in designing an Internet of Things strategy. Digi’s Chief Technology Officer, Joel Young, discusses five critical areas of IoT security.

Cover these, and you’re on the right path:

  • secure boot
  • authentication
  • protected ports
  • storage
  • secure connections

In this five minute video, Joel shares which questions to ask and what steps to take in order to ensure strong IoT device security.

You can get the transcript of this video here, and learn more about Digi TrustFence here.

5 Lessons Learned from the Mirai DDoS Attack

Posted on:

Security is always top of mind when it comes to IoT devices and applications. The recent Mirai DDoS attack in October 2016 is an important reminder that IoT device manufacturers—and consumers—need to be vigilant with security, both out of the box and at home.

Recently, Andrew Lund, Digi’s Product Marketing Manager for Wireless M2M and IoT, shared his thoughts with IoT Evolution on the Mirai attack and what lessons could be learned to help improve security for IoT devices and applications. Below is an excerpt of five of Andrew’s best practices from IoT Evolution’s piece, which you can read in full here.

  1. Change default passwords:
    Given the attack vector that Mirai used, it’s clear that one area Device OEMs can make design decisions to increase security is with respect to passwords. The days of leaving the default password unchanged are over, so manufacturers must either force users to change passwords or create a “default” passwords that are unique to each individual IoT device.
  2. Don’t allow insecure ingress protocols:
    Mirai malware contains “killer” scripts that remove other worms and Trojans, allowing Mirai to maximize its use of the infected host device. But Mirai also goes one step further and closes processes that are used for remote ingress attempts, like Telnet, SSH, and HTTP.
  3. Secure remote management tools:
    Efficient, cost-effective method of remotely monitoring, updating and managing connected devices. Users can set performance parameters for healthy devices and create reports and alarms for suspicious activity. Using a remote manager that incorporates PCI-DSS and other relevant security certifications in the cloud such as HIPAA and NIST allow users to define a device profile, assign the profile to all devices in a group, and monitor and auto-remediate any variances. The best remote management tools can also restrict incoming traffic to only allow SSL connections, eliminating unencrypted TCP connections.
  4. Firmware updates:
    Firmware updates must be completed securely (authentication) and automatically, or at a minimum, users must be notified/prompted when a new firmware update is available.
  5. Packet encryption:
    This consists of basic encryption, such as FIPS-197/AES, to protect messages from unauthorized viewing or malicious changes. This method is easy to implement and use, especially in conjunction with private keys.


The Past, Present, and Future of Remote IoT Security

Posted on:

The expansion of IoT applications allows more remote devices to wirelessly collect, store, and transmit information across vast networks and distances to multiple applications. Remote_IoT_SecurityThis advancement now demands that remote IoT solutions be designed to have individualized device security, well thought out IoT hardware and with consideration of risk aversion because hackers now have a larger playing field with even more targets. Industries like Smart Grids, Smart Cities, and the Transportation industry are more susceptible to these cyber attacks because they are constantly trying to go further, do more, and expand network coverage. Remote IoT connected devices can be accessed from both wired and wireless networks, which leave them vulnerable to these basic types of attacks to consider:

  • Access/Authentication of IoT Devices – Hackers can cause mistrust by misleading remote network devices by altering the manufacturer code.
  • Up-to-date security systems – Hackers can attack systems that have fallen behind on updates or lack support to patch issues in large numbers of scattered IoT devices.
  • Encryption Network Security – Hackers can easily access and find encryption keys to decrypt IoT data.
  • Hardware Port access Protection- Hackers can physically attack remote IoT devices and gain access through the JTAG port, network ports, or an Ethernet port.

The IoT solution to help prevent these cyber attacks is to design and implement a futuristic IoT security framework. The security solution will be tailored to a specific IoT solution and will provide advance features like device authentication, using a remote system that will monitor and update devices. Remote services will also help store IoT data and validate that data as originating from the proper device. It will include a hardened coprocessor that add other layers of IoT security by enabling security functions separate from the main processor in a hardened security environment.

Read more about remote IoT Security, cyber attacks, and the future of an IoT Security Framework >>

Is Your JTAG Debug Port Vulnerable to Hackers?

Posted on:

In most Internet of Things (IoT) deployments, it’s good practice to authenticate anyone trying to access your device – typically through the Ethernet, WiFi, or other network protocol. But there’s a more subtle, and dangerous, way to get into your device: through a JTAG debug port. If someone gains physical access, he can create much more havoc because JTAG takes you to the low-level heart of a board or chip, where an expert hacker can take complete low-level control of the system – even replacing firmware with a rogue code.

System Blog Diagram

In this contributed article for Embedded Computing Design, Digi’s Mike Rohrmoser explains the pluses and minuses of the use of Secure JTAG keys. Regardless of the approach you choose, Digi TrustFence™ security framework includes tools for manufacturing and maintenance, including Secure JTAG.


It’s an Uncertain World: Are You Secure?

Posted on:

Security is a mounting concern for both wired and wireless M2M networks.

Their data may seem mundane, but if this information is stolen, impeded, or altered, the potential consequences are too great, particularly in commercial and industrial applications.

IoT SecurityYet M2M networks are populated by small, defenseless devices that are designed to be simple and inexpensive.

With their limited electrical and processing power, desktop and mobile security measures like firewalls or passwords aren’t practical.

Digi acutely understands the need to safeguard M2M networks and offers Strengthening Security in Embedded IoT Solutions, an introduction to security options for designers of M2M implementations.

Reading this paper, you’ll learn about the four types of IoT threats and the tools available to identify and prioritize them.

You’ll discover the six core methods for achieving M2M security: packet encryption, message replay protection, message authentication code, debug port protection, secure bootloaders, and pre-shared keys.

By understanding the threats and means to counter them, you can greatly reduce the risks and vulnerabilities of your M2M networks.

Read the white paper here >>

Contact a Digi expert and get started today! Contact Us
Have a Question?