Understanding Security Requirements for IoT Perception Layer Gateways

Since the concept of the Internet of Things (IoT) was proposed, discussions on IoT architecture have taken place, and the IoT industry has rapidly developed. While the IoT accelerates the integration of technology into daily life, security issues have also arisen. Important institutions around the world, such as those in electricity, energy, and airports, frequently face attacks, and IoT security is more complex compared to the Internet. The perception layer of IoT includes various sensors and controllers distributed across different industries, with limited computing capabilities, posing severe challenges to IoT security protection. The perception layer gateway serves as a hub for various sensing devices. Due to the lack of unified security requirements, the security capabilities of different IoT perception layer gateways vary significantly, leading to considerable security risks in IoT technology applications. It is necessary to standardize and formulate security technical requirements for IoT perception layer gateways.

To promote the standardized application of IoT perception layer gateway products and meet actual security needs, the National Standardization Administration has initiated the formulation of the national standard “Information Security Technology – Security Technical Requirements for IoT Perception Layer Gateways.” This standard is drafted according to the rules given in GB/T1.1-2009, proposed by the National Technical Committee for Information Security Standardization (SAT/TC260) and published by the State Administration for Market Regulation and the National Standardization Administration of China.

On December 28, 2018, the national standard “Information Security Technology – Security Technical Requirements for IoT Perception Layer Gateways” was officially released and will be implemented starting from July 1, 2019.

This standard was co-drafted by institutions including Beijing University of Technology, China Cybersecurity Review Technology and Certification Center, China Electronic Technology Standardization Institute, North Industrial University, Beijing Winut Technology Co., Ltd., and Wangshen Information Technology (Beijing) Co., Ltd. Huang Min, Qi Xiangdong, Wu Yunkun, Qu Xiaodong, Sun Ling, Ji Shenglong, and Qiao Siyuan made outstanding contributions to the drafting of the standard.

The release of this national standard for IoT marks that there is now a security standard to follow for the safety of IoT applications. It is a universal security technical standard for perception layer gateways, specifying the security technical requirements for perception layer gateways used in IoT information systems, including the classification of security technical requirements levels and their physical security, security functions, and security guarantees. It is also applicable to the design, development, and testing of perception layer gateways in IoT information systems, providing guidance and reference for the security technical research and product industrialization of IoT perception layer gateways. Below, Winut will interpret some contents of the “Information Security Technology – Security Technical Requirements for IoT Perception Layer Gateways”:

The Internet of Things is an intelligent service system that connects objects, people, systems, and information resources through agreed protocols, processing information from the physical and virtual worlds and responding accordingly. {GB/T33745-2017 Definition 2.1.1}

The IoT is generally considered to be a system with a perception layer, network transmission layer, and processing application layer. The perception layer includes sensor nodes, terminal controller nodes, perception layer gateway nodes, RFID tags, RFID reader devices, and short-range wireless networks (such as Zigbee); the network transmission layer primarily focuses on long-distance wide-area network communication services; the processing application layer is mainly based on cloud computing service platforms, including various services of cloud platforms and user terminals. Since cloud computing can simultaneously provide intelligent processing of data and services to end users, the processing layer in the IoT architecture includes application services.

In an IoT system, we need to clarify the boundaries of the perception layer, i.e., what belongs to the perception layer. If the perception layer of the IoT is a sensing network, then the sensing nodes, routing nodes, aggregation nodes, and the network used by the sensing network (usually short-range radio frequency) all belong to the perception layer of the IoT. Note that the aggregation node does not belong to the perception layer as a whole device but only its aggregation function belongs to the perception layer. Because in the IoT system, the aggregation node as part of the perception layer not only communicates with the sensing nodes but also has to be responsible for transmitting the aggregated information to the upper processing center, its function of communication with the upper layer obviously does not belong to the perception layer. Since in the IoT, the aggregation node of the perception layer not only has the aggregation function but also needs to be responsible for transmitting the information of the sensing nodes it manages to the processing center, the aggregation node of the perception layer is generally referred to as the perception layer gateway node. Therefore, the boundary of the perception layer of the IoT system with the sensing network as its basis is the gateway node of the sensing network, and its aggregation function to the sensing node is part of the perception layer of the IoT.

In an RFID-based IoT application system, the perception layer will include the communication functions of RFID tags and RFID readers. The part from the RFID reader to the backend database will belong to the network transmission layer. Therefore, the boundary of the perception layer is determined by the functions of the RFID reader.

The security technologies of the perception layer include the following:

1) Device security, which refers to the security of the sensor nodes themselves, mainly indicating that the sensor nodes have sufficient power supply and normal operational capabilities. More security requirements may be meaningful for the aggregation nodes in the sensor network.

2) Computing security, which refers to the security of the execution environment of the processor when the sensor processes data, including operating system (COS, Android, Linux, Windows, etc.) security and execution software security.

3) Data security, mainly referring to the secure storage and access interfaces of important data, such as key information, which should be restricted from being directly read through external interfaces.

4) Communication security, which refers to the processing of data during sending and receiving, including the ability to encrypt and decrypt data, integrity verification, and identity authentication capabilities of the communication parties.

The perception layer gateway is a network connection device that is an important component of the IoT information system, with various sensors and controllers distributed across different industries. The perception layer gateway operates at the edge of the perception network, serving as a bridge between traditional information networks (wired networks, mobile networks, etc.) and perception networks, supporting data encoding and conversion functions between one or more wired/wireless short-range communication protocols (Modbus, Profibus, OPC, ZigBee, Bluetooth, Wi-Fi, etc.) and wide-area network communication protocols.

The security functions of the perception layer gateway are closely related to the processing capabilities of the hardware and software platform it operates on, typically equipped with an operating system. Firewall, routing, and other functions are often added to the perception layer gateway.

The deployment environment of perception layer gateway devices is diverse; when deployed outdoors, they are susceptible to physical environmental factors including temperature, humidity, power supply, electromagnetic interference, and human destruction.

The main security threats that perception layer gateways may face include:

a) Attackers can steal or intercept data from perception layer gateways, collecting source addresses, destination addresses, data content, data transmission times, and protocol types from sensing terminals;

b) Attackers can spoof sensing terminals to launch denial-of-service attacks and replay attacks against perception layer gateways;

c) Unauthorized users impersonate authorized users in an attempt to access network resources;

d) Users accessing and modifying data beyond their granted permissions;

e) Theft or human damage leading to a loss of integrity in device components;

f) Insufficient power supply leading to device malfunction;

g) Poor environmental choices, such as high temperatures, humidity, static electricity, lightning, etc., pose threats to device security.

According to the classification principles for gateway security technology in GA/T681-2007, security technical requirements are divided into two levels: basic level and enhanced level. The basic level meets the requirements of the second level of the GA/T681-2007 gateway security protection classification, while the enhanced level meets the requirements of the third level of the GA/T681-2007 gateway security protection classification.

In IoT information systems classified below level three as per GB/T22240, perception layer gateways should meet basic level requirements; in information systems classified as level three and above, perception layer gateways should meet enhanced level requirements.

The basic security technical requirements mainly include three major requirements: physical security requirements, security function requirements, and security assurance requirements.

1.1 Physical Security Requirements

Perception layer gateways should meet the following requirements for physical security:

a) The physical environment should have fire and static electricity protection measures;

b) The physical environment should have moisture and water protection measures;

c) Major components should be fixed and marked with obvious, difficult-to-remove labels.

1.2 Security Function Requirements

1.2.1 Authentication for Sensing Terminal Access

Perception layer gateways should be able to authenticate accessing sensing terminals, meeting the following requirements:

a) Ensure the uniqueness of the sensing terminal identification throughout the lifecycle of the perception layer gateway;

b) Be able to authenticate sensing terminals, supporting at least one of the following mechanisms:

1) Network identification-based authentication;

2) MAC address-based authentication;

3) Communication protocol-based authentication;

4) Communication port-based authentication;

5) Password-based authentication;

c) Ensure secure storage and exchange of keys.

1.2.2 Network Access Control

Perception layer gateways should implement access control for accessing sensing terminals, meeting the following requirements:

a) Support access control policies such as access control lists (ACLs) to prevent illegal access and use of resources;

b) Control local or remote access.

1.2.3 Data Protection

1.2.3.1 Data Storage Protection

Perception layer gateways should meet the following data storage protection requirements:

a) Protect important data stored in the perception layer gateway to prevent unauthorized access;

b) Have mechanisms for integrity checking of stored data in the perception layer gateway, ensuring the integrity of critical data such as identification information, protocol conversion rules, and audit records.

1.2.3.2 Data Transmission Protection

Perception layer gateways should meet the following data transmission protection requirements:

a) Protect data during transmission from being leaked, using cryptographic techniques to ensure the confidentiality of important data (such as command control data, business data);

b) Have mechanisms for integrity checking of transmitted data, ensuring the integrity of important data during transmission (such as checksums, message digests, digital signatures, etc.);

c) Have mechanisms to handle communication delays and interruptions.

1.2.4 System Security Protection

1.2.4.1 Timestamp

Should have a reliable timestamp.

1.2.4.2 Identification and Authentication

Perception layer gateways should be able to identify and authenticate operating system users, meeting the following requirements:

a) Users of the perception layer gateway’s operating system should have unique identifiers;

b) When authenticating users of the perception layer gateway’s operating system using username and password, the password should consist of letters, numbers, and special characters, with a length of at least 8 characters.

1.2.4.3 Access Control

Perception layer gateways should be able to control access for operating system users, meeting the following requirements:

a) Should control the access permissions of operating system users of the perception layer gateway and avoid privilege escalation;

b) Should only grant the minimum permissions necessary for operating system users to complete tasks;

c) Should control local or remote access to data;

d) Should provide security measures to control remote configuration of the perception layer gateway;

e) Control scope should cover all subjects, objects, and their operations.

1.2.4.4 Security Audit

1.2.4.4.1 Audit Data Generation

Should generate audit records for the following auditable events:

a) The activation and deactivation of audit functions;

b) Authentication failures, recording the identity of the user and the identifier of the access device used;

c) Protocol conversion failures, recording the source and time of the converted data packets;

d) Any attempts to read, modify, or destroy audit records;

e) All requests for operations covered by access authorization and denial rules, as well as identifying the affected objects;

f) All attempts to modify security attributes, along with the new values of the modified security attributes;

g) All requests using the identification data management mechanisms in security functions;

h) All requests for accessing identification data and the targets of access requests;

i) Any use of identification mechanisms;

j) All attempts using identification mechanisms;

k) The number of unsuccessful authentication attempts exceeding a set limit.

For each audit record, the security function should at least record the date and time of the event, the type of event, and the identity of the subject.

1.2.4.4.2 Audit Data Access

Should meet the following audit data access requirements:

a) Should restrict access to audit records;

b) Should provide the ability to review audit records.

1.2.4.4.3 Audit Data Storage

Should be able to protect audit record information to prevent modifications to audit records.

1.2.4.5 Failure Protection

Should have protective states to ensure the correctness of security policies upon power restoration of the perception layer gateway.

1.3 Security Assurance Requirements

1.3.1 Development

1.3.1.1 Security Architecture

Developers should provide a security architecture description of the product’s security functions, which should meet the following requirements:

a) Be consistent with the level of abstract description of security functions in the product design documentation;

b) Describe the security domain of product security functions consistent with security function requirements;

c) Describe why the initialization process of product security functions is secure;

d) Certify that product security functions can prevent destruction;

e) Certify that product security functions can prevent bypassing security features.

1.3.1.2 Functional Specifications

Developers should provide complete functional specifications, which should meet the following requirements:

a) Fully describe the product’s security functions;

b) Describe the purpose and usage of all security function interfaces;

c) Identify and describe all parameters related to each security function interface;

d) Describe the implementation behavior of security function interfaces;

e) Describe direct error messages resulting from security function implementation behavior;

f) Certify the traceability of security requirements to security function interfaces.

1.3.1.3 Product Design

Developers should provide product design documentation that meets the following requirements:

a) Describe the product structure based on subsystems;

b) Identify and describe all subsystems of the product’s security functions;

c) Describe the interactions between all subsystems of security functions;

d) Provide mappings that can verify that all behaviors described in the design can be traced to the security function interfaces that call them.

1.3.2 Guidance Documentation

1.3.2.1 User Operation Guide

Developers should provide clear and reasonable user operation guides that are consistent with all other documentation provided for evaluation, meeting the following requirements for each user role:

a) Describe the functions and privileges accessible to users controlled in a secure processing environment, including appropriate warnings;

b) Describe how to securely use the available interfaces provided by the product;

c) Describe the available functions and interfaces, especially all security parameters controlled by users, indicating security values where appropriate;

d) Clearly state all security-related events related to the functions accessible to users that need to be executed, including changes to security features of controlled entities;

e) Identify all possible states of the product operation (including failures or operational errors caused by operations) and their causal relationships and connections with maintaining secure operations;

f) Fully implement the security policies necessary to achieve security objectives.

1.3.2.2 Preparation Procedures

Developers should provide the product and its preparation procedures, which should meet the following requirements:

a) Describe all steps necessary for the secure acceptance of the delivered product that are consistent with the delivery process from the developer;

b) Describe all steps necessary for securely installing the product and its operating environment.

1.3.3 Lifecycle Support

1.3.3.1 Configuration Management Capability

Developers’ configuration management capabilities should meet the following requirements:

a) Provide unique identifiers for different versions of the product;

b) Maintain all configuration items that make up the product using a configuration management system and uniquely identify configuration items;

c) Provide configuration management documentation that describes the methods used to uniquely identify configuration items.

1.3.3.2 Configuration Management Scope

Developers should provide a list of product configuration items and specify the developers of the configuration items. The list should include evidence of evaluation of security assurance requirements and the contents of the product’s components.

1.3.3.3 Delivery Procedures

Developers should deliver products using certain delivery procedures and document the delivery process. When delivering various versions of the product to users, the delivery documentation should describe all procedures necessary for maintaining security.

1.3.4 Testing

1.3.4.1 Testing Coverage

Developers should provide testing coverage documentation and indicate the correspondence between the tests identified in the testing documentation and the security functions described in the functional specifications.

1.3.4.2 Functional Testing

Developers should test the product’s security functions, document the results, and provide testing documentation. Testing documentation should include the following:

a) Testing plans identifying the tests to be executed and describing the schemes for executing each test, including any dependencies on the results of other tests;

b) Expected test results indicating the anticipated output upon successful testing;

c) Actual test results and their consistency with expectations.

1.3.4.3 Independent Testing

Developers should provide a set of resources equivalent to those used for self-testing security functions for sampling tests of security functions.

1.3.5 Vulnerability Assessment

Based on identified potential vulnerabilities, the product should be able to resist attacks from attackers with basic attack capabilities;

The enhanced level adds additional requirements on top of meeting the basic level requirements. For more details, please click Read the Original to view the full text of “Information Security Technology – Security Technical Requirements for IoT Perception Layer Gateways.”

About Winut

Beijing Winut Technology Co., Ltd. (hereinafter referred to as “Winut”) was established in 2014 and is a national high-tech enterprise focused on industrial control security in China. It is one of only six companies globally that has received security certification from the International Society of Automation for safety compliance.

Winut focuses on the innovative “White Environment” overall solution, developing 20 self-controlled products across five categories covering industrial control network security, possessing leading core technologies and market advantages. It has successfully provided comprehensive and effective security guarantees for over 500 customers in key national industries such as electricity, rail transit, tobacco, petrochemical, municipal, smart manufacturing, metallurgy, and military industry. Winut has been invited multiple times to provide network security services for major events such as the 19th National Congress of the Communist Party of China, the Two Sessions, the Belt and Road Initiative, and G20, and has widely participated in the formulation of national and industry standards in the field of industrial control security, receiving high recognition from various national government departments and clients.

Winut is committed to protecting the cybersecurity of China’s critical information infrastructure, safeguarding “Made in China 2025,” and contributing to building a strong cyber nation!