Skip to product information
1 of 12

PayPal, credit cards. Download editable-PDF & invoice In 1 second!

GB/T 20272-2019 English PDF (GBT20272-2019)

GB/T 20272-2019 English PDF (GBT20272-2019)

Regular price $345.00 USD
Regular price Sale price $345.00 USD
Sale Sold out
Shipping calculated at checkout.
Quotation: In 1-minute, 24-hr self-service. Click here GB/T 20272-2019 to get it for Purchase Approval, Bank TT...

GB/T 20272-2019: Information security technology -- Security technical requirements for operating system

This Standard specifies the security technical requirements for operating system of five security classes. This Standard applies to the research and development, testing, maintenance, and evaluation of security of operating system.
GB/T 20272-2019
NATIONAL STANDARD OF THE
PEOPLE REPUBLIC OF CHINA
ICS 35.040
L 80
Replacing GB/T 20272-2006
Information security technology -
Security technical requirements for operating system
ISSUED ON: AUGUST 30, 2019
IMPLEMENTED ON: MARCH 01, 2020
Issued by: State Administration for Market Regulation;
Standardization Administration of the PRC.
Table of Contents
Foreword ... 3
1 Scope ... 5
2 Normative references ... 5
3 Terms and definitions ... 5
4 Abbreviations ... 6
5 Product description ... 6
6 Security technical requirements ... 6
6.1 Class 1: user self-protection class ... 6
6.1.1 Security function requirements ... 6
6.1.2 Self-security requirements ... 8
6.1.3 Security assurance requirements ... 9
6.2 Class 2: system audit protection class ... 13
6.2.1 Security function requirements ... 13
6.2.2 Self-security requirements ... 16
6.2.3 Security assurance requirements ... 19
6.3 Class 3: security label protection class ... 24
6.3.1 Security function requirements ... 24
6.3.2 Self-security requirements ... 29
6.3.3 Security assurance requirements ... 33
6.4 Class 4: structured protection class ... 39
6.4.1 Security function requirements ... 39
6.4.2 Self-security requirements ... 45
6.4.3 Security assurance requirements ... 48
6.5 Class 5: access verification protection class ... 55
6.5.1 Security function requirements ... 55
6.5.2 Self-security requirements ... 61
6.5.3 Security assurance requirements ... 65
Appendix A (Informative) Table for classing of security technical requirements for operating system ... 74
Bibliography ... 75
Information security technology -
Security technical requirements for operating system
1 Scope
This Standard specifies the security technical requirements for operating system of five security classes.
This Standard applies to the research and development, testing, maintenance, and evaluation of security of operating system.
2 Normative references
The following documents are indispensable for the application of this document. For the dated references, only the editions with the dates indicated are applicable to this document. For the undated references, the latest edition (including all the amendments) are applicable to this document.
GB 17859-1999 Classified criteria for security protection of computer
information system
GB/T 18336.3-2015 Information technology - Security techniques -
Evaluation criteria for IT security - Part 3: Security assurance components GB/T 20271-2006 Information security technology - Common security
techniques requirement for information system
GB/T 29240-2012 Information security technology - General security
technique requirements and testing and evaluation method for terminal
computer
3 Terms and definitions
The terms and definitions defined in GB 17859-1999, GB/T 18336.3-2015,
GB/T 20271-2006, and GB/T 29240-2012 and the following ones apply to this document.
3.1 Security of operating system
The confidentiality, integrity, and availability of operating system itself and of the information it stores, transmits, and processes.
a) User identification function:
1) Before users enter the operating system, they shall be identified first. 2) The user identification of operating system should use the username
and UID.
b) User authentication function:
1) The password is used for authentication and is authenticated each time the user logs into the system and when the system is reconnected;
2) The password shall be invisible; during storage and transmission, shall be securely protected, to ensure that it is not accessed, modified, and deleted without authorization;
3) By predefining the value of unsuccessful authentication attempt
(including the threshold of the number of attempts and time) and clearly specifying the measures taken when the value is reached, achieve the
processing of authentication failure.
c) For users registered to the operating system, the user process shall be associated with its owner user, so that the behavior of user process can be traced back to the owner user of the process.
6.1.1.2 Discretionary access control
The discretionary access control functions of SSOOS are as follows:
a) The owner of the object shall have the right to modify its access rights for all objects owned by it;
b) The owner of the object shall be able to set the access control attributes of other users for the object it owns. The access control attributes include at least: read, write, execute, etc.;
c) The subject?€?s access to the object shall follow the object?€?s discretionary access control right attribute;
d) The granularity of the access control object is controlled in files and directories.
6.1.1.3 Data integrity
For user data transmitted internally the operating system (such as inter-process communication), there shall be a function of ensuring the integrity of user data. e) Identify all possible states of SSOOS operation (including operational failures or operational errors) and their causal relationship and connection with maintaining secure operation;
f) Describe the security policy which shall be enforced to ensure secure operation of SSOOS.
6.1.3.2.2 Preparation procedure
The developer shall provide the operating system and its preparation procedure. The description of preparation procedure shall meet the following requirements: a) Describe all the steps necessary to securely receive an operating system consistent with the developer delivery procedure;
b) Describe all the steps necessary to securely install the operating system and its operation environment.
6.1.3.3 Life cycle support
6.1.3.3.1 Configuration management capability
The developer?€?s configuration management capabilities shall meet the following requirements:
a) Provide a unique identification for different versions of operating system; b) Provide a configuration management document describing a method for
uniquely identifying a configuration item;
c) The configuration management system uniquely identifies all configuration items.
6.1.3.3.2 Configuration management scope
The developer shall provide a list of SSOOS configuration items and a brief description of the developer of the configuration item. The list of configuration items shall contain the following:
a) SSOOS, evaluation evidence for security assurance requirements, and
components of SSOOS;
b) Unique identification of configuration item;
c) For each configuration item related to security function, the list of configuration items briefly describes the developer of the configuration item.
algorithms which comply with national cryptography-related regulations are used.
6.1.3.5 Vulnerability evaluation
Based on the identified potential vulnerabilities, the operating system shall resist attacks by attackers with a basic attack potential.
Note: The resisting to attacks by attackers with basic attack potential needs to be comprehensively considered based on the following 5 specific factors: attack time, attacker ability, level of understanding of the operating system, time of access to operating system or number of attack samples, attack equipment used. See GB/T 30270-2013 Appendix A, A.8.
6.2 Class 2: system audit protection class
6.2.1 Security function requirements
6.2.1.1 Identity authentication
The identity authentication functions of SSOOS are as follows:
a) User identification function:
1) Before users enter the operating system, they shall be identified first; 2) The user identification of operating system shall use the username and UID. Throughout the life cycle of the operating system, achieve
the unique identification of the user, as well as the consistency
between the username or alias, UID, and the like.
b) User authentication function:
1) Adopt mechanisms such as management-enhanced password
authentication/token-based dynamic password authentication.
Authenticate each time the user logs in to the system and the system
is reconnected;
2) The authentication information shall be invisible; during storage
and transmission, shall be securely protected, to ensure that it is not accessed, modified, and deleted without authorization;
3) By predefining the value of unsuccessful authentication attempt
(including the threshold of the number of attempts and time) and clearly specifying the measures taken when the value is reached, achieve the
processing of authentication failure.
configuration parameters. Before initializing and protecting security-
related data structures, it shall define the security policy attributes of user and administrator.
b) It shall distinguish normal operation mode and system maintenance mode. c) Before a normal user accesses the system, the system shall be
installed and configured in a secure manner.
d) For regular system maintenance such as backups which does not
affect SSOOS, it may be performed in normal operation mode.
e) After the operating system is installed, before normal user accesses, the system shall be configured with initial user and administrator
responsibilities, root directories, audit parameters, system audit trail settings, and appropriate access controls for files and directories.
f) Only system administrators are allowed to modify or replace the
executable program provided by the system.
g) After the fault or interruption of SSOOS, it shall be recovered with minimal damage. According to the description of 5.1.2.2 failure protection in GB/T 20271-2006, it shall handle the SSF fault.
h) It shall control and audit the use of system console.
i) Developers of operating systems shall timely release patches for
discovered vulnerabilities. The administrator of operating system shall promptly obtain, uniformly manage, and timely apply patches to repair the vulnerabilities of the operating system.
6.2.2.2 Resource utilization
6.2.2.2.1 Fault tolerance
The fault tolerance functions of SSOOS are as follows:
a) Certain measures shall be taken to ensure that the SSF can maintain
normal operation when certain deterministic fault conditions occur in the system, for example, the service level of system detection and
reporting system has been reduced to a predetermined minimum;
b) When the service level of system resources is reduced to a
predetermined minimum, it shall be able to detect and issue reports;
c) It shall provide the ability to run the system in maintenance mode, in which all security functions are disabled. The system only allows the
1) The date, time, source of this login and last successful login to the system;
2) The identity authentication failure since the last successful access to the system;
3) The number of days the password expires;
4) The number of successful or unsuccessful events can be
expressed by an integer count, a timestamp list, and the like.
6.2.2.4 Trusted measurement
The trusted measurement functions of SSOOS are as follows:
a) When the operating system is started, it shall measure the integrity of the operating system kernel;
b) When the executable program is started, it shall measure the
integrity;
c) The reference values of integrity measurement shall be stored
securely, to prevent them from being tampered with.
6.2.2.5 Security policy configuration
Security policy configuration functions shall be provided for identity
authentication, security audit, network security protection, resource utilization, and user login access control.
6.2.3 Security assurance requirements
6.2.3.1 Development
6.2.3.1.1 Security architecture
The developer shall provide the security architecture description document of SSOOS. The security architecture description document shall meet the
following requirements:
a) Consistent with the description of security function requirements and self- security protection requirements in the SSOOS design document;
b) Describe the security domain of SSOOS;
c) Describe why the SSOOS initialization process is secure;
d) Confirm that SSOOS can prevent damage;
6.2.3.4.1 Coverage
The developer shall provide a testing coverage document. The testing coverage document shall meet the following requirements:
a) Confirm the correspondence between the testing in the testing document and the SSOOS interface in the functional specification description;
b) Confirm that all SSOOS interfaces in the functional specification
description have been tested.
6.2.3.4.2 Depth
Developers shall provide the analysis document of testing depth. The
analysis document of testing depth shall meet the following requirements: a) Confirm the correspondence between the testing and security
functions in the testing document and the self-security protection;
b) Confirm that all security functions and self-security protection
functions in the SSOOS design have been tested.
6.2.3.4.3 Functional testing
Developers shall test SSF and self-security protection functions. The testing document shall include the following:
a) Testing plan: Identify the tests to be performed and describe the scenario for performing each testing. These scenarios include any sequential
dependencies on other testing results;
b) Expected testing results: Indicate the expected output after the testing is completed;
c) Actual testing results: Consistent with the expected testing results; d) Confirm that known vulnerabilities have been corrected, eliminated, or invalidated, and retesting is performed after the vulnerabilities have been removed, to verify that they have been eliminated and that no new
vulnerabilities have been introduced.
6.2.3.4.4 Independent testing
Developers shall provide a set of equivalent resources as they used in self-tests, for testing of SSOOS.
6.2.3.4.5 Cryptographic testing
accessed, modified, and deleted without authorization;
3) By predefining the value of unsuccessful authentication attempt
(including the threshold of the number of attempts and time) and clearly specifying the measures taken when the value is reached, achieve the
processing of authentication failure.
c) For users registered to the operating system, the user process shall be associated with its owner user, so that the behavior of user process can be traced back to the owner user of the process.
6.3.1.2 Discretionary access control
The discretionary access control functions of SSOOS are as follows:
a) The owner of the object shall have the right to modify its access rights for all objects owned by it.
b) The owner of the object shall be able to set the access control attributes of other users for the object it owns. The access control attributes include at least: read, write, execute, etc.
c) The subject?€?s access to the object shall follow the object?€?s discretionary access control right attribute.
d) For discretionary access control with finer granularity, the
granularity of the access control subject is controlled to a single user. The granularity of the access control object is controlled in files and directories.
e) When the subject generates an object, the object shall have a default value of discretionary access control right attribute set by the subject. f) Discretionary access control shall be able to combine identity
authentication and audit to make users bear clear responsibility for their own behavior by confirming the authenticity of the user?€?s identity and
recording the user?€?s various accesses.
g) The object owner shall be able to set the object it owns: The owner
is the only subject who has the right to modify its access rights.
h) The object owner is not allowed to assign control right of the object to other subjects.
6.3.1.3 Label and mandatory access control
The label and mandatory access control functions of SSOOS are as
The object reuse functions of SSOOS are as follows:
a) Ensure that unauthorized users cannot find information which, after
use, is returned to the system?€?s storage media (including at least:
disk and memory, etc.);
b) Ensure that unauthorized users cannot find previous information
which the system has assigned to its storage media (including at
least: disk and memory, etc.).
6.3.1.6.2 Data confidentiality
The data encryption functions of SSOOS are as follows:
a) It shall provide file encryption function. Users may encrypt-protect specified files and directories;
b) SUPPORT for protecting keys in hardware;
c) It shall provide file system encryption function, to transparently
encrypt and decrypt files and directories stored in the encrypted file
system.
6.3.1.7 Network security protection
The network security protection functions of SSOOS are as follows:
a) SUPPORT two-way network access control based on IP address, port,
physical interface, and applications. DISCARD packets which do not
meet the pre-defined policy;
b) The network transmission data shall be able to be encrypted and integrity- protected;
c) SUPPORT two-way network trusted access authentication based on
system identity and system running state;
d) Network access shall be controlled so that only authorized
processes can access the network.
6.3.2 Self-security requirements
6.3.2.1 Operation security protection
The operation security protection functions of SSF are as follows:
a) An installation mechanism shall be provided to set and upgrade
configuration parameters. Before initializing and protecting security-
b) When the service level of system resources is reduced to a predetermined minimum, it shall be able to detect and issue reports.
c) It shall provide the ability to run the system in maintenance mode, in which all security functions are disabled. The system only allows the system
administrator to enter maintenance mode.
d) The system shall provide the process of software and data backup
and recovery and add a restart synchronization point to the system,
to facilitate system recovery.
e) The system shall provide mechanisms and processes which can be
used to periodically confirm the correct operation of the system.
These mechanisms or processes involve monitoring of system
resources, proper operation of hardware and firmware units,
detection of error conditions which may propagate throughout the
system, and detection of communication errors which exceed user-
defined thresholds, etc.
6.3.2.2.2 Service priority
The service priority functions of SSOOS are as follows:
a) The service priority policy shall be adopted to set the subject to use the priority of a subset of resources within the SSF control scope to manage and allocate operating system resources;
b) It shall be ensured that access to all operating system resources is based on the priority set by the subject.
6.3.2.2.3 Resource allocation
The resource allocation functions of SSOOS are as follows:
a) In accordance with the requirements of 5.1.4.2 a) maximum quota
resource allocation in GB/T 20271-2006, it shall carry out the
management and allocation of operating system resources. The quota
mechanism ensures that user...

??

View full details