SBN

Security Standards in IoT

Nowadays, everywhere we see IoT devices, showing their popularity and growth. IoT devices frequently perform a series of collect, exchange, process, and react to data tasks. This exposes them to security issues related to vulnerabilities that IoT devices encounter. As a real-life example, in October 2016, a DDoS attack caused infected IoT devices to overload domain registration services. This article will help readers understand Security Standards in IoT and provide Security in IoT Best Practice Guidelines.

 

1. What are the IoT Security Standards?

Currently, IoT Security Standards are regulatory standards for the security of IoT devices issued by a reputable and widely accepted organization to ensure security requirements for IoT devices, data user data, and related issues. Currently, there are few and not widely available, but only regulated in a specific region. Below are some IoT Security Standards statistics. In addition, the state of California also issued the California civil code, which has a separate section for mandatory security of IoT devices. The California law is one of the few official laws addressing IoT device privacy and security in the world.

Figure 1: Statistics table of some IoT Security Standards (source: IoT Security Best Practice Guidelines (hkcert.org))

In the future, most IoT devices will rely on 5G networks. Therefore, IoT Security Standards will directly affect 5G networks and vice versa.

 

2. IoT Security Best Practice

This section will approach 2 different IoT Security Best Practices that are objectively the best.

2.1 Layered Structure of IoT Security Best Practice solution

Figure 2: IoT Layered Architecture Model (source: IoT Security Best Practice Guidelines (hkcert.org))

Application Layer:

  • Responsibility: firstly, delivering application services (mobile applications, business processes, data analytics, API services, and web applications). Secondly, it manages the processing, analytics, and storage of all application data.
  • Security Issues:
    • Authentication: To offer granular control over data access for each user, role-based access control is required.
    • Default usernames and passwords.
    • A web application is regarded as a significant attack surface.
    • The techniques of web-based attacks are always evolving.
    • The API service is powered by a backend web server that faces the same security threats as a web application.
    • The danger of losing or stealing a mobile phone poses a security risk of information leakage.
    • Because the cloud database and cloud data store are immediately accessible through the Internet, they may be more vulnerable to data breaches as a result of a cyber assault.
  • Best Practices:
    • Whenever authentication is required, strong passwords should be used.
    • For multi-user systems, role-based access control should be included.
    • Should have password recovery procedures that are secure.
    • Support password expiration and a policy of changing passwords on a regular basis.
    • At the first setup step, make it obligatory to alter the default password.
    • Account lockout is supported to protect against brute force attacks.
    • To avoid account lockout DoS attacks, utilize CAPCHA.
    • API clients should be able to verify the API service’s authenticity by using a valid TLS server certificate verified by a trustworthy certificate authority.
    • To slow down volumetric attack attempts, utilize rate limitation.
    • With backend cloud apps or IoT devices, they employ encrypted communications.
    • Other security measures (two-factor authentication, account lockout, strong passwords, digital certificate authenticity, encryption, input validation, session timeout, secure storage, etc).
    • In order to manage the whole lifecycle of encryption key activities (key generation, key storage, key usage, key rotation, key revocation, and key destruction) while utilizing data encryption in the cloud, the solution should use encryption key management.

Figure 3: Key management lifecycle (source: (PDF) A New Approach of Secret Key Management Lifecycle for Military Applications (researchgate.net))

Management Layer:

  • Responsibility: Firstly, managing the IoT services (management platform, deployment, monitoring system, software update platform, and disposal of IoT devices). Secondly, to manage the lifecycle of IoT devices, IoT solution providers engage with this layer via the management interface.
  • Security Issues:
    • During the lifecycle of IoT products, security vulnerabilities must be repaired and patched on a regular basis.
    • Inject malware into patch files, firmware, or delivered software by compromising a software source or delivery mechanism.
    • It’s possible that IoT devices aren’t updated on a regular basis, and the old versions are still in use.
    • Data and event monitoring are frequently lacking in IoT devices.
  • Best Practices:
    • Validation of the supplied products’ integrity is necessary.
    • Invalid or illegitimate IoT devices may be avoided by managing IoT devices using unique IDs.
    • Prevent interfering with the data collection source.
    • Ongoing security monitoring keeps IoT systems secure (storage systems, network or telemetry services, mobile services, cloud services, any devices, etc) and sends out timely notifications so that security problems may be dealt with more quickly.
    • Vulnerability management and disclosure policies for IoT products should be devised by manufacturers or developers.
    • Within a reasonable timescale, manufacturers or developers should deliver security updates to address device vulnerabilities.
    • If there is any abnormality with IoT device integrity, monitor anomalous behavior of IoT devices and quarantine them.
    • It’s important to keep an eye on audit logs and security event logs.
    • Set thresholds for each sort of security incident and receive notifications when the thresholds are surpassed, allowing for further investigation.

Network Layer:

  • Responsibility: firstly, network connectivity for servers, network devices, and IoT devices. Secondly, it manages data transfer between IoT devices, mobile phones, mobile applications, and backend servers.
  • Support technology: cellular network connectivity (4G, 5G, etc), wireless Internet connectivity (WiFi, etc), the long-range device to carrier gateway wireless connectivity (LoRa, NB-IoT, Sigfox, etc), and short-range device to device wireless connectivity (Bluetooth, Zigbee, NFC, RFID, etc).
  • Security Issues:
    • Use radio sniffing tools to sniff wireless network traffic.
    • Over the network, attackers search for any susceptible network services.
    • During the initial pairing stage, devices may accept any connection.
    • Internet communication paths that pass through a public network hop may be vulnerable to eavesdropping.
    • By using a man-in-the-middle assault between the endpoints of the communication, attackers can intercept network traffic.
  • Best Practices:
    • Using encryption in wireless communications is a good idea.
    • Physical interaction can help prevent unauthorized distant parties from spying on you.
    • IoT gateways can function as firewalls, encrypting communications with TLS and increasing network isolation over the Internet.
    • In the course of Internet connections, Transport Layer Security (TLS) encryption provides end-to-end data confidentiality, authentication, and integrity.
    • The authenticity of communications endpoints can be ensured via transport security.
    • To safeguard the content of wireless data streams, lightweight encryption or tokenization should be used.
    • For IoT solutions that require a greater level of assurance about the validity of each IoT device endpoint, the IoT solution should use a unique API token or a unique TLS digital certificate signed by a trusted certificate authority to confirm the authenticity of each IoT device endpoint.

Perception Layer/Physical Layer:

  • Responsibility: firstly, where IoT devices can be found. Secondly, different sensors on IoT devices interact with the physical environment to acquire various physical metrics (electricity, movement, flow, pressure, humidity, speed, air quality, temperature, etc). Thirdly, robotics, motors, actuators, and other IoT devices will have some type of kinetic interaction with the physical environment. Fourthly, some IoT devices may not be able to connect to the Internet directly via Internet Protocol (IP). IoT gateways are utilized in this scenario to function as a network bridge between IoT devices and the Internet.
  • Security Issues:
    • External interfaces or ports may be used by attackers to exploit vulnerabilities.
    • Physical tampering is increasingly likely in IoT devices.
    • It is possible to physically extract storage from a device.
    • Other users might be able to recycle or repurpose the devices.
    • Different operational circumstances (power outage, network failure, etc.) that may influence device availability.
  • Best Practices:
    • The security risk of obtaining device control locally is reduced by blocking or restricting the capability of physical external interfaces or ports.
    • To maintain data confidentiality, sensitive data must be encrypted at rest.
    • When a device is no longer in use or is being disposed of, users should have discretion over data erasure.
    • IoT devices should be able to recover and resume regular functioning automatically.
    • Unnecessary debug interfaces or ports should be disabled on the device.
    • Each device should have the following 3 elements: Firstly, a unique asymmetric key-pair securely. Secondly, the private key is secured within a Secure Element. Finally, a PKI digital certificate.

Personal Data Privacy:

  • Responsibility: All four layers are affected by personal data privacy. It goes over the different security concerns that arise from each layer, as well as the remedies that are required to reduce the risks.
  • Security Issues: Failure to comply with applicable personal data privacy rules may result in legal responsibility.
  • Best Practices:
    • Should observe the Personal Data (Privacy) Ordinance in use, retention, collection, and security of personal data.
    • Provide end-users with a clear description of the company’s policy and procedure for managing all personal data.
    • Taking all reasonable precautions to ensure security (encryption, key management, etc).
    • Personal data collection and retention should be kept to a minimum (should only process and store de-identified).
    • Should get end users’ permission before collecting data that isn’t absolutely necessary.
    • If personal data is to be utilized for purposes other than the device’s intended primary functionality, end users’ agreement should be sought. 

2.2 Secure Design Best Practice Guides

Classification of Data: determined through classes corresponding to the sensitivity of the data. From there, corresponding to each layer, there will be an appropriate level of security and commensurate with the nature of the data being processed.

Physical Security: By physically restricting access and eliminating any methods of undesired connection, production devices may be safeguarded from physical access to data and intellectual property. By using measures such as secure protocols, restricted ports, strong credential management, and epoxy chips on circuit boards.

Figure 3: Epoxy chips to the circuit board (source: Non-Premixed and Frozen, One Part Epoxy for Chip Coating | Laser Focus World (laserfocusworld.com))

Device Secure Boot: The danger of a rogue code being launched at boot time is reduced by using a tiered boot sequence, in which each step is verified for validity before being initialized. The initial boot step must be completely reliable in order for the subsequent stages to be trusted.

  • Ensure that the secure boot function based on ROM is always used.
  • Use a tamper-resistant capability based on hardware (Trusted Platform Module (TPM), Secure Access Module (SAM), microcontroller security subsystem, etc).

 

Figure 4: Generic architecture of a Trusted Platform Module (TPM) (source: (PDF) Trusted Platform based Key Establishment & Management for Sensor Networks (researchgate.net))

Secure Operating System: removing all unnecessary access rights and functions, using the latest software.

Application Security: Security must be built in from the start, rather than being tacked on later. Applications should be kept separate from one another (Secure Computing Mode (second), containerization, virtual machines, etc).

  • Integrate security into the software development lifecycle at all levels.

Figure 5: Software development lifecycle (source: Software Development Life Cycle (SDLC) – Big water Consulting (big water. consulting))

  • Make use of secure code and design approaches (remove weak encryption ciphers, use secure protocols, prevent buffer overruns, sanitize and validate all data input before processing).

Credential Management: is evidence of people’s or other entities’ identities. It is used to restrict data access or allow secure conversations. Digital certificates, encryption keys, passwords, and other credential data must be handled safely at all times and updated on a regular basis. Store encryption keys or credentials in a Hardware Security Module (HSM), Trusted Platform Module (TPM), or Secure Access Module (SAM).

Figure 6: Secure Access Module (SAM) (source: ACOS6-SAM Secure Access Module Card (Contact) (acs.com.hk))

Encryption: use the strongest encryption algorithm available. Use unique keys per device instead of global keys when developing public/private key cryptography.

Network Connections: protect connection points used to access the network, making only connections that are specifically required by the device to function. Run firewalls, use secure protocols (HTTPS, SFTP, etc).

 

3. Opportunities and Challenges of Security Standards in IoT

Different Sectors Have Different Priorities: Each sector will have a different approach to securing IoT devices. Some typical examples are: in medicine, it is necessary to develop security for implantable devices, wearable devices, etc. In the automotive industry, it was developed for the automatic mode of operation.

Human Factor of IoT Security: In the future, it is necessary to put people at the center of developing IoT devices, to better understand how people use devices, and to make IoT devices safe and easy to use for everyone to comply with. and use security methods. Vulnerable Legacy Systems: Risk assessments and vulnerability mitigation are often overlooked by system operators.

Challenges Encountered by Generic Security: Includes all network security mechanisms and policies that can be used to keep IoT devices secure. However, due to the diversity and rapid growth of IoT devices, there is not a complete and accurate policy on the security of IoT devices. In the future, a mature policy is needed to make securing IoT devices easy.

Conclusion

Security Standards in IoT are a necessity when building and developing an IoT device. This prevents attacks aimed at obtaining user data, especially sensitive data. The article outlined ways to help secure IoT devices, hoping to help readers protect IoT devices and personal data effectively.

The post Security Standards in IoT appeared first on Speranza.

*** This is a Security Bloggers Network syndicated blog from IoT Blog – Speranza authored by Allen. Read the original post at: https://www.speranzainc.com/security-standards-in-iot/