GB/T 47689-2026Cybersecurity technology - Security technical specification for embedded operating systems (English PDF)

6.1.1 Network Access Security

6.1.1.1 Network Access Authentication The functional requirements are as follows:

a) It should have the function of uniquely identifying terminal devices on the network;

b) It should have a two-way authentication mechanism for terminal devices accessing the network.

6.1.1.2 Network Access Control The functional requirements are as follows:

a) The principle of minimizing network port exposure should be followed, and communication ports other than those required for business needs should be disabled;

b) It should be able to set network access control policies to prevent unauthorized network access;

c) It should have the function of limiting network traffic.

6.1.2 Communication security The functional requirements are as follows:

a) A security mechanism based on cryptography should be adopted to ensure the integrity of important data transmissions such as control commands, authentication data, and key data. The cryptographic techniques used are in accordance with the relevant regulations of the national cryptography administration department, ensuring security and confidentiality.

b) Security measures, such as using sequence codes or timestamps, should be adopted to prevent replay attacks.

6.1.3 Identity Authentication For scenarios involving user login to the operating system, the system must have identity authentication capabilities, with the following requirements.

a) User identities should be identified and verified;

b) When using password authentication, a function to verify the complexity of identity authentication information should be provided;

c) A login failure handling function should be provided, such as limiting the number of consecutive login failures;

6.1.14 Data Security

6.1.14.1 Data Integrity The functional requirements are as follows:

a) Perform integrity checks on important stored data (such as authentication data, key data, system configuration data, etc.);

b) Necessary recovery measures should be taken when an integrity error is detected.

6.1.14.2 Data Availability The functional requirements are as follows:

a) It should be able to back up important data (such as basic data that ensures the normal operation of the system);

b) It should have a data loss protection mechanism, and be able to take necessary measures (such as alarms, opening new storage spaces) when it detects that the system storage space is about to run out. Temporary storage areas, etc., to prevent data loss.

6.1.14.3 Data Confidentiality Important data such as authentication data, key data, and system configuration data should be encrypted and protected.

6.1.15 Reliability Requirements

6.1.15.1 Resource Constraints The system should provide a mechanism for detecting and controlling resource usage to prevent applications from consuming resources without limit due to logical errors or malicious behavior.

6.1.15.2 Failure Protection The system should be able to self-detect defined system faults and provide corresponding protection measures to prevent the system from being in a state of failure due to faults.

6.1.15.3 Reliable Clock The system should provide functions such as manually setting the system clock or automatically synchronizing the clock through a remote clock service.

6.2.1 Development

6.2.1.1 Security Architecture Developers should provide a security architecture description for the embedded operating system's security features. This security architecture description should meet the following requirements.

a) Consistent with the level of abstract description of security functions in the system design document;

b) Describe the security domains of the embedded operating system security functions that are consistent with the security function requirements;

c) Describe why the initialization process of the embedded operating system's security features is secure;

d) Verify that the embedded operating system's security features can prevent breaches;

e) Verify that the embedded operating system's security features can prevent security features from being bypassed.

6.2.1.2 Functional Specifications Developers should provide a system functional specification, which should meet the following requirements.

a) Describe the security features of the embedded operating system;

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

c) Identify and describe all parameters associated with each security function interface;

d) Describe the implementation behavior of security functions related to the security function interfaces;

e) Describe the direct error message caused by the behavior processing implemented by the security function;

f) Verify the traceability from security function requirements to security function interfaces.

6.2.1.3 Implementation Representation Developers should provide implementation representations for all security features, and these should meet the following requirements.

6.2.2 Guidance Documents

6.2.2.1 User Guide Developers should provide clear and reasonable user guidelines, which should be consistent with all other documentation provided for the evaluation. Therefore, the description of each user role should meet the following requirements.

a) Describe the user-accessible functions and privileges controlled within the secure processing environment, including appropriate warning messages;

b) Describe how to use the available interfaces provided by the embedded operating system in a safe manner;

c) Describe the available functions and interfaces, especially all security parameters under user control, and specify the security values where appropriate;

d) Clearly describe every security-related event associated with the user-accessible functionality that needs to be performed, including changes to the security functionality controlled by it. Safety characteristics of the controlled entity;

e) Identify all possible states of the embedded operating system (including operational failures or operational errors), and their... The causal relationship and connection between and maintaining safe operation;

f) Clearly state the security policies implemented to achieve security objectives.

6.2.2.2 Preparation Procedure Developers should provide an embedded operating system and its preparatory procedures. The description of the preparatory procedures should meet the following requirements.

a) Describe all steps necessary for securely receiving the delivered embedded operating system, consistent with the developer's delivery procedure;

b) Describe all the steps necessary for the secure installation of an embedded operating system and its operating environment.

6.2.3 Lifecycle Support

6.2.3.1 Configuration Management Capabilities Developers' configuration management capabilities should meet the following requirements.

a) Provide a unique identifier for different versions of the system;

b) Use a configuration management system to maintain all configuration items that make up the system and uniquely identify each configuration item;

c) Provide configuration management documentation that describes methods for uniquely identifying configuration items;

d) The configuration management system provides an automated way to support system production, ensuring that only the implementation representation of the system can be accessed. Make the authorized changes;

e) The configuration management documentation includes a configuration management plan, which describes how to develop the system using the configuration management system;

f) The configuration management plan describes the procedures used to accept modified or newly created configuration items as part of the system;

g) The implemented configuration management is consistent with the configuration management plan.

6.2.3.2 Configuration Management Scope Developers should provide a list of embedded operating system configuration items, which should meet the following requirements.

a) Includes assessment evidence of the system and security requirements, and the components of the system;

b) Implement the representation, security defect reporting, and resolution status.

6.2.3.3 Delivery Procedure Developers should use a defined delivery procedure to deliver the embedded operating system and document the delivery process. This should be done before delivering the embedded operating system to the user. When delivering different versions of the operating system, the delivery documentation should describe all the programs necessary to maintain security.

6.2.3.4 Development Security Developers should provide development security documentation, which should describe the security measures taken in the system's development environment to protect the system's design and implementation. All physical, procedural, personnel and other security measures necessary for confidentiality and integrity.

6.2.3.5 Lifecycle Definition Developers should establish a lifecycle model to exercise necessary control over the development and maintenance of the system, and provide a lifecycle definition document. Describe the model used for developing and maintaining the system.

6.2.4 Testing

6.2.4.1 Covering Evidence Developers should provide test coverage documentation, and the test coverage description should indicate the tests identified in the test documentation and those described in the functional specifications. The correspondence between security functions of embedded operating systems.

6.2.4.2 Coverage Analysis Developers should provide test coverage documentation, and the test coverage description should meet the following requirements.

a) Indicate the correspondence between the test interfaces identified in the test documentation and the security function interfaces of the system described in the functional specifications;

b) This demonstrates that the above correspondence is complete and confirms that all security function interfaces in the functional specification have been tested.

6.2.4.3 In-depth analysis Developers should provide test depth analysis, which should meet the following requirements.

a) Demonstrate the implementation of the embedded operating system security function subsystem and security function requirements in the test and system design within the test documentation. Consistency between modules;

b) All embedded operating system security function subsystems in the system design have been tested;

c) The safety function requirements of the system design have been demonstrated and the execution modules have been tested.

6.2.4.4 Functional Testing Developers should test the security features of the embedded operating system, document the results, and provide test documentation. The test documentation should include the following. content.

a) Test plan, which identifies the tests to be performed and describes the execution plan for each test, including considerations for other test results. Any order dependency;

b) Expected test results, indicating the anticipated output after a successful test;

c) The actual test results are consistent with the expected test results.

6.2.4.5 Independent Testing Developers should provide a set of resources equivalent to those used when self-testing security features for sampling testing of security features.

6.2.5 Vulnerability Assessment

6.2.5.1 Basic-level vulnerability analysis Based on identified potential vulnerabilities, embedded operating systems can resist attacks from attackers with basic attack potential.

6.2.5.2 Enhanced Vulnerability Analysis Based on identified potential vulnerabilities, embedded operating systems can resist attacks from attackers with enhanced attack potential.

7.1.1 Network Access Security

7.1.1.1 Network Access Authentication The testing methods for network access authentication are as follows:

a) Review the system design documents to confirm whether the system has the function of generating network identity identifiers for terminal devices, and check its functionality for terminal devices. Establish a mechanism for network identity identification and verify whether this mechanism can guarantee the uniqueness of the identifier.

b) Log in to the system, use tools or view the source code to verify whether the network is generated for the terminal device according to the mechanism described in the design document. An identity identifier, and the identifier is unique;

c) Connect the terminal device to the network, use packet capture tools to check the authentication mechanism used, and examine the embedded operating system of the terminal device. Can the system side use authentication techniques based on identification or cryptography to authenticate the platform side and confirm whether the terminal device provides [authentication/verification]? Providing credentials is required to successfully access the platform network.