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

GB/T 20272-2019: Information security technology - Security technical requirements for operating system
Delivery: 9 seconds. Download (& Email) true-PDF + Invoice.
Get Quotation: Click GB/T 20272-2019 (Self-service in 1-minute)
Historical versions (Master-website): GB/T 20272-2019
Preview True-PDF (Reload/Scroll-down if blank)

GB/T 20272-2019
NATIONAL STANDARD OF THE
PEOPLE’S 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 ...