Documentation

Mistake on this page? Email us
Docs › Security › Edge security considerations

Edge security considerations

Izuma Edge typically hosts many devices and therefore, it is a more appealing target for attacks than Device Management Client (which runs on only one device). The hardware running Izuma Edge is typically more powerful and therefore more capable tool for the attackers.

Because we cannot control many of the security aspects (such as Linux distribution configuration or manufacturing related issues), your development team needs to ensure the end-to-end safety of our solutions.

Secure boot

Devices should have a secure boot, which ensures that no one has tampered with the firmware in the device. Secure boot can include checking of:

  • Signature.
  • Firmware integrity.
  • Version.

Root of Trust

The primary starting point for all security in the device is based on the Root of Trust (RoT). RoT is a secret key used for encrypting the data on the device. Device Management Client and Izuma Edge both want to access and use the RoT for encrypting the Key and Configuration Management data (KCM) through the ESFS module. KCM holds the credentials and identity that Izuma Edge uses to access Device Management.

You need to store the RoT in a secure place. The RoT must be a minimum of 128 bits long and contain full-entropy data, generated by properly seeded cryptographic random bit generator random data. The RoT must not be predictable based on any information you can acquire from the device, such as a MAC, serial number or similar.

In devices that support Arm TrustZone, you should only access the RoT from inside the TrustZone and never use it outside the TrustZone. Having access to the RoT from the user side or application level is always a hazard.

If the device does not support TrustZone, store the RoT on the internal flash or one time programing bits (OTP). Do not store the RoT on any external memory media, such as an SD card. Attackers can more easily reach external memory devices than an internal flash.

If your device is not capable of generating a RoT internally and your device is provisioned in the factory, ensure your factory is secure and the RoT cannot leak.

Limit file system access

Make sure you protect everything possible by limiting the file system access. Only the user running Izuma Edge should have access the KCM data injected for the Device Management Client and Izuma Edge credential. This minimizes the attack vector. If attackers gets in without root access, they still cannot access the KCM data.

Key-based and strong password-based authentication

If your device allows an SSH shell connection, make sure that you have key-based authentication or password-based authentication enabled.

We recommend that you disable password-based authentication and use only key-based authentication on the devices.

If you need to use password-based authentication, apply the following rules:

A strong password must protect any local management access to Izuma Edge and Device Management Client. A strong password contains:

  • A minimum of 8 characters.
  • No words available in any cracking dictionary.
  • A delay after N consecutive wrong username and password tries to slow down brute force attacks.

If your device allows SSH shell connection, you must have a strong password. Alternatively, you can use a server certificate for authentication.

Do not use passwords that are same for all devices by default (factory username and password). The devices should have a unique password straight from the factory. Once you access the local management, modify the password. There have been extremely severe cases where attacks were made using the default factory passwords. For example, the infamous Mirai Botnet attack was based purely on default factory passwords.

Limit the number of hosted devices

You must limit the number of devices Izuma Edge can host. One attack vector is to overload Izuma Edge with too many hosted devices. By default, our implementation can check for an EDGE_REGISTERED_ENDPOINT_LIMIT for the maximum number of protocol translated endpoints, but you must:

  1. Tune the value to match the demands of the translated endpoints (how many resources are needed for each hosted endpoint) and Izuma Edge hosting hardware capability (how much RAM, ROM, CPU and network bandwidth you have available).
  2. Limit the number of translated devices each protocol translator has because you can run multiple protocol translators in one Izuma Edge device.
    • If protocol translator X is feature-heavy and uses lots of resources, and protocol translator A is simple, Izuma Edge may be able to run 100 protocol A translated devices but only 50 protocol X translated devices. Therefore, one limit of 100 may not be sufficient, and you may have to have a separate limit for the protocol translators.

Close all physical ports

All ports allowing shell commands or diagnostic access (kernel log outputs) must be closed, so an attacker cannot open them.

Encrypt all traffic

The translated endpoints communicate with Izuma Edge over some media. Ensure that media and communications between the endpoints and protocol translator are encrypted and integrity protected (with MAC or authenticated encryption) properly. This may not be possible with some legacy endpoints, but in such cases, you must ensure that the connectivity is physically secure. Traffic between the Izuma Edge gateway and Izuma Device Management cloud is secure.

You must use encryption for all new applications and devices.

Remove everything unnecessary

The more software, services and ports you have open, the wider the attack surface you expose. You should:

  • Remove all software you do not need.
  • Disable all services you do not need.
  • Close all network ports you do not need to expose.

Smaller targets are more difficult to hit. This also makes updates easier because there is less to update.

Do not elevate user privileges unless you have to

Do not run your software under root user. If this is not possible, minimize the root usage. Define separate users for general software and Izuma Edge, and define the minimum necessary privileges for each user and software component. Any buffer overflow attack or other weakness in software running as root exposes the whole system to an attacker.

Update your software development kit

By default, software has bugs and weaknesses. We must identify, fix and patch these weaknesses in live environments. Therefore, you must ensure your Operating System (OS), libraries and services are up to date with the latest security patches. Do not use old Linux kernels that no one maintains anymore.

If severe security vulnerabilities are discovered, you must create new software for your devices and push it through Device Management Update service to the devices.

Logging services

Izuma Edge supports two log related security features:

  • Verified logging - use of journald's forward secure sealing.
  • FluentBit - filtering and uploading logs to a remote server for storage and analysis.

You can use these services for audit trails, forensic analysis and attack detection.

Next