GA/T 989-2012 Information security technology Electronic document security management product security technical requirements GA/T989-2012 Standard compression package decompression password: www.bzxz.net
This standard specifies the security function requirements, inherent security function requirements, security assurance requirements and level classification requirements of electronic document security management products. This standard is applicable to the design, development and testing of electronic document security management products. This standard
is drafted in accordance with the rules given in GB/T1.1-2009.
This standard is proposed by the Cyber ​​Security Bureau of the Ministry of Public Security.
This standard is under the jurisdiction of the Information System Security Standardization Technical Committee of the Ministry of Public Security.
This standard was drafted by: Computer Information System Security Product Quality Supervision and Inspection Center of the Ministry of Public Security, Shenzhen Hongan Information Technology Co., Ltd., and Beijing Dingpu Technology Co., Ltd.
The main drafters of this standard are: Song Haohao, Zhang Yan, Gu Jian, Zhao Yun, Zhang Xiaoxiao, Wu Qicong, Zou Chunming, Wang Zhijia, Zhang Guanchun, Wang Jiangbo.
The following documents are indispensable for the application of this document. For all dated referenced documents, only the dated version applies to this document. For all undated referenced documents, the latest version (including all amendments) applies to this document.
GB/T5271.8—2001 Information technology vocabulary Part 8: Security
GB17859—1999 Criteria for classification of security protection levels of computer information systems
GB/T18336.3—2008 Information technology security technology Information technology security assessment criteria Part 3: Security assurance requirements
Foreword I
1 Scope1
2 Normative references1
3 Terms and definitions1
4 Security function requirements1
5 Intrinsic security function requirements3
6 Security assurance requirements6
7 Classification requirements9

ICS35.240
People's Republic of China Public Security Industry Standard GA/T 989—2012
Information security technology
Security technical requirements for security management products of electronic documents2012-04-25Promulgated
Ministry of Public Security of the People's Republic of China
Implementation on 2012-04-25
GA/T989—2012
1Scope
2Normative references
3Terms and definitions
4Security function requirements
5Original security function requirements
6Security assurance requirements
Grade classification requirements
This standard was drafted in accordance with the rules given in GB/T1.1-2009. This standard was proposed by the Cyber ​​Security Bureau of the Ministry of Public Security. This standard is under the jurisdiction of the Information System Security Standardization Technical Committee of the Ministry of Public Security. GA/T989-2012
The drafting units of this standard are: Computer Information System Security Product Quality Supervision and Inspection Center of the Ministry of Public Security, Shenzhen Hongan Information Technology Co., Ltd., and Beijing Dingpu Technology Co., Ltd. The main drafters of this standard are: Song Haohao, Zhang Yan, Gu Jian, Zhao Yun, Zhang Xiaoxiao, Wu Qicong, Zou Chunming, Wang Zhijia, Zhang Guanchun, and Wang Jiangbo. 1 Scope
Information security technology
Technical requirements for security of electronic document security management products GA/T 989—2012
This standard specifies the security function requirements, inherent security function requirements, security assurance requirements, and grading requirements of electronic document security management products.
This standard applies to the design, development, and testing of electronic document security management products. 2 Normative references
The following documents are indispensable for the application of this document. For all referenced documents with dates, only the versions with dates apply to this document. For any undated referenced documents, the latest version (including all amendments) shall apply to this document. GB/T5271.8—2001 Information technology vocabulary Part 8: Security GB17859-1999 Criteria for classification of security protection levels of computer information systems GB/T18336.3-2008 Information technology security technology Information technology security assessment criteria Part 3: Security assurance requirements
3 Terms and definitions
GB/T5271.8—2001, GB17859—1999 and GB/T18336.3—2008 and the following terms and definitions shall apply to this document.
Secure electronic document securityelectronicdocument An electronic document that is restricted and protected by a security management policy. 3.2
Security management products for electronic documents securitymanagementproducts of electronic documents Products that manage, monitor and audit secure electronic documents in a unified manner by creating secure electronic documents or converting electronic documents into secure electronic documents. This type of product prevents unauthorized access to secure electronic documents through management means such as user identity authentication, access control, and audit mechanisms.
Trusted host trustedhost
A host that is authorized by the electronic document security management product to identify and access secure electronic documents. 3.4
Untrusted host untrustedhost
A host that is not authorized by the electronic document security management product to identify and access secure electronic documents. 4 Security function requirements
4.1 Trusted host management
4.1.1 Trusted host registration
Electronic document security management products should be able to register hosts as trusted hosts. 1
HKicaCiaikAca
GA/T989—2012
4.1.2 Trusted host grouping
Electronic document security management products should be able to group trusted hosts and specify secure electronic documents that can be accessed by trusted hosts in different groups.
4.1.3 Trusted host deregistration
Electronic document security management products should be able to deregister trusted hosts. 4.2 Secure electronic document management
4.2.1 Secure electronic document generation
Electronic document security management products should be able to produce secure electronic documents or convert electronic documents into secure electronic documents according to security management policies, and the integrity of the electronic document content should be ensured during the conversion process. 4.2.2 Security management strategy
The security management strategy for secure electronic documents should include the following elements: a) Legal users/user groups:
Whether the content is limited to "read-only";
Use period;
Restrict the number of times it is opened;
Whether printing is allowed and the number of prints is limited; whether the content is allowed to be modified;
Whether the content is allowed to be copied;
Whether it is allowed to be converted into electronic documents. 4.2.3
Security Management Policy Management
Electronic document security management products should be able to:
a) Import and export security management policies;
b) Customize security management policy templates.
4.2.4 Security Management Policy Viewing
The generator of secure electronic documents should have the function of viewing the security attributes of the secure electronic documents. 4.2.5 Security Management Policy Change
The generator of secure electronic documents should have the function of changing the security management policy of the secure electronic documents. 4.3 Secure Electronic Document Authentication
4.3.1 Host Authentication
When a user requests to access a secure electronic document, the secure electronic document should authenticate the host. 4.3.2 User Identity Authentication
When a user requests to access a secure electronic document, the electronic document security management product should authenticate the user's identity. If a password signing mechanism is used, the password should not be displayed in plain text. 4.3.3 Minimum feedback
GA/T 989—2012
When authenticating a user's identity, the electronic document security management product should provide only the minimum feedback (e.g., the number of characters entered, success or failure of authentication) to the authenticated user.
4.3.4 Authentication data protection
The electronic document security management product should ensure that the user's authentication data is not accessed by unauthorized persons. 4.3.5 Authentication failure processing
The electronic document security management product should be able to set a threshold for the number of authentication attempts for user authentication that can be modified by the authorized administrator. When the number of unsuccessful user authentications exceeds the threshold, the product should prevent the user from making further authentication requests. 4.3.6 Timeout lock
The secure electronic document should have an access timeout lock function. If the authorized user does not perform any operation within the set time period, the session will be terminated and the user needs to perform identity authentication again before being able to operate again. The maximum timeout period can only be set by the authorized administrator. 4.3.7 Session Locking
Electronic document security management products should provide the function of locking the interactive session between authorized users and secure electronic documents. After locking, the current user can only access the secure electronic document after successfully re-authenticating. 4.4 Security Tagging
Electronic document security management products should be able to set sensitive tags for all users and secure electronic documents, and enable them after the product is installed. 4.5 Access Control
4.5.1 Autonomous Access Control
Electronic document security management products should be able to:
Allow authorized users to access secure electronic documents on trusted hosts: a)
Deny operations to access secure electronic documents on untrusted hosts: b)
Deny operations to access secure electronic documents on trusted hosts by unauthorized users: Execute autonomous access control policies and control authorized users' access to secure electronic documents on trusted hosts according to security management policies. d)

4.5.2 Mandatory access control
Electronic document security management products should be able to implement mandatory access control policies, and control authorized users' access to secure electronic documents on trusted hosts by comparing security tags and based on security management policies. 4.5.3 Security management policies cannot be bypassed
Electronic document security management products should ensure that users' access to protected secure electronic documents is subject to security management policies. 5 Self-security function requirements
5.1 Component security
5.1.1 Self-protection function of the trusted host
Electronic document security management products should be able to provide certain protection measures for components installed on the trusted host to prevent unauthorized users from performing the following operations:
a) Forcefully terminate the operation of the component:
b) Forcefully cancel the automatic loading of the component when the system starts:
c) Forcefully uninstall, delete or modify the component. 5.1.2 Prevent unauthorized monitoring
Measures should be taken to ensure that the trusted host only accepts monitoring from the authorized management console. 5.1.3 Remote transmission security
If the components of the electronic document security management product communicate through the network, the data transmitted between the components should be protected to ensure the confidentiality and integrity of the data during the transmission process. 5.2 Administrator security management
5.2.1 Identification and authentication
5.2.1.1 Administrator attribute initialization
Electronic document security management products should provide the ability to initialize the attributes of authorized administrators. 5.2.1.2 Administrator unique identification
Electronic document security management products should provide unique identification for authorized administrators, and associate the identification of authorized administrators with all auditable events of the authorized administrators. 5.2.1.3 Administrator identity authentication
Electronic document security management products should authenticate the identity of any administrator claiming to perform the duties of an authorized administrator before performing any security-related operations.
5.2.1.4 Administrator authentication data protection
Electronic document security management products should ensure that the administrator's authentication data is not accessed by unauthorized persons. 5.2.1.5 Administrator authentication failure processing
When the number of authentication failures for authorized administrators reaches a specified threshold, the electronic document security management product should prevent further authentication requests from authorized administrators.
5.2.2 Security Management Roles
Electronic document security management products should be able to distinguish between administrator roles and provide the following functions to implement security management based on different roles: a) Administrator roles with at least two different permissions; b) According to different functional modules, various roles with different permissions can be customized, and roles can be assigned to administrators. 5.2.3 Administrator Management
Electronic document security management products should provide the following functions to manage administrators: Create and delete administrators:
Modify administrator attributes (including administrator passwords and administrator permissions). 4
5.3 User Security Management
5.3.1 Unique Identification of Authorized Users
GA/T989—2012
Electronic document security management products should provide a unique identity for authorized users, and associate the identity of authorized users with all auditable events of the authorized users. 5.3.2 User Management
Electronic document security management products should have the function of managing users, and can create, modify and delete users. 5.3.3 User Group Management
Electronic document security management products should have the function of group management of authorized users, and can create and delete user groups, and can add, modify and delete users for user groups.
5.3.4 User Role Management
Electronic document security management products should have the function of hierarchical (decentralized) role management of authorized users, and can establish roles with different levels and set different user permissions for each role. 5.4 Audit Function
5.4.1 Audit Log Generation
Electronic document security management products should be able to audit at least the following events: Authorized administrator authentication success and failure;
User identity authentication success and failure:
The number of unsuccessful administrator authentication attempts exceeds the set limit, resulting in the termination of the session connection:)
The number of unsuccessful user identity authentication attempts exceeds the set limit, resulting in the termination of the session connectiond)
Important operations of administrators, such as adding and deleting administrators, user management, backup logs, etc.; Important operations of authorized users, such as making secure electronic documents, converting electronic documents to secure electronic documents, formulating and changing security management policies, etc.:
g) All requests for access to secure electronic documents, including success and failure. Each audit log should at least include the date and time of the event, user ID, event description, and event result (success or failure).
5.4.2 Audit log storage
Electronic document security management products should provide the following functions to store audit logs: a) Store in non-volatile storage media that does not consume power; b) When the storage space reaches the threshold, the authorized administrator should be notified. 5.4.3 Audit log management
Electronic document security management products should provide the following functions to manage audit logs: a) Only authorized administrators are allowed to access audit logs; b) Audit logs should be able to be queried in combination by date, time, user ID, file ID, etc.; c) Audit logs should be able to be backed up.
rrKacaCaaiKAca
GA/T 989—2012
6 Security assurance requirements
6.1 Configuration management
6.1.1 Configuration management capabilities
6.1.1.1 Version number
Developers should provide unique identifiers for different versions of the product. 6.1.1.2 Configuration Items
The developer shall use a configuration management system and provide configuration management documentation. The configuration management documentation shall include a configuration list, which shall uniquely identify all configuration items that make up the product and describe the configuration items. It shall also describe the method of uniquely identifying configuration items and provide evidence that all configuration items are effectively maintained. 6.1.1.3/Authorization Control
The configuration management documentation provided by the developer shall include a configuration management plan, which shall describe how the configuration management system is used. The implemented configuration management shall be consistent with the configuration management plan. The developer shall provide evidence that all configuration items are effectively maintained: and shall ensure that configuration items can only be modified with authorization. 6.1.2 Configuration Management Coverage
The scope of configuration management shall at least include product delivery and operation documents, development documents, guidance documents, life cycle support documents, test documents, vulnerability analysis documents and configuration management documents, so as to ensure that their modifications are carried out in a properly authorized and controlled manner. The configuration management documentation shall at least be able to track the above content and describe how the configuration management system tracks these configuration items. 6.2 Delivery and Operation
6.2.1 Delivery Procedure
Developers should use a certain delivery procedure to deliver products and document the delivery process. The delivery document should describe all procedures necessary to maintain security when delivering each version of the product to the user. 6.2.2 Installation, Generation and Startup Procedure
Developers should provide documents to describe the installation, generation and startup process of the product. 6.3 Development
6.3.1 Informal Functional Specification
Developers should provide a functional specification that uses an informal style to describe the product security function and its external interface. The functional specification should be internally consistent and should describe the purpose and use of all external interfaces. It should provide details of effects, exceptions and error messages when appropriate, and fully represent the product's functions. 6.3.2 High-level Design
6.3.2.1 Descriptive High-level Design
Developers should provide a high-level design of the product's security function. 6
GA/T989—2012
The high-level design should be expressed in an informal style and be internally consistent. To illustrate the structure of the security function, the security function should be decomposed into various security function subsystems for description. For each security function subsystem, the security function it provides should be described, all its interfaces and which interfaces are externally visible should be identified, and the purpose and method of using all its interfaces should be described. The high-level design should also identify all the basic hardware, firmware and software required by the security function, and support the protection mechanisms implemented by these hardware, firmware and software. 6.3.2.2 Security-enhanced high-level design
The developer should explain how the subsystem that contributes to the product security function is separated from other subsystems, and provide appropriate details of the role, exceptions and error messages of the security function subsystem. 6.3.3 Informal correspondence verification
The developer should provide a correspondence analysis between all adjacent pairs of product security function representations. For each adjacent pair of product safety function representations, the analysis shall clarify that all relevant safety functions of the more abstract safety function representation shall be correctly and completely detailed in the more specific safety function representation. 6.4 Guidance Documents
6.4.1 Administrator's Guide
The developer shall provide an administrator's guide, which shall be consistent with all other documents provided for the assessment. The administrator's guide shall describe the following:
a) The management functions and interfaces available to the administrator; how to manage the product securely;
Functions and permissions that should be controlled in a secure processing environment;
d) All assumptions about user behavior related to the secure operation of the product; all security parameters controlled by the administrator, with security values ​​specified if possible;
Each security-related event related to the management function, including changes to the security characteristics of the entity controlled by the security function;
G) All IT environment security requirements related to the administrator. 6.4.2
User's Guide
The developer shall provide a user's guide, which shall be consistent with all other documents provided for the assessment. The user guide should describe the following:
a) The security functions and interfaces that can be used by non-administrator users of the product; b) How to use the security functions and interfaces provided by the product to users: Users can obtain all functions and permissions controlled by the secure processing environment; c
d) The responsibilities that users should assume in the security operation of the product; e) All security requirements of the IT environment related to users. 5 Lifecycle support
The developer should provide development security documentation.
The development security documentation should indicate all physical, procedural, personnel and other security measures necessary to protect the confidentiality and integrity of the product design and implementation in the product development environment, and should also provide evidence of the implementation of security measures during the development and maintenance of the product.
HiiKacaaiKAca
GA/T 989-—2012
6.6 Testing
6.6.1 Coverage
6.6.1.1 Evidence of coverage
The developer should provide evidence of test coverage. In the test coverage evidence, it should be shown that the tests identified in the test documentation correspond to the product's safety functions described in the functional specification.
6.6.1.2 Coverage analysis
The developer shall provide the analysis results of test coverage. The analysis results of test coverage shall show that the correspondence between the tests identified in the test documentation and the product's safety functions described in the functional specification is complete.
6.6.2 Test depth
The developer shall provide an analysis of test depth
In the depth analysis, it should be stated that the tests on the safety functions identified in the test documentation are sufficient to show that the safety functions are consistent with the high-level design.
6.6.3 Functional testing
The developer shall test the security functions, document the results and provide test documentation. The test documentation shall include the following:
a) Test plan, which shall identify the security functions to be tested and describe the test objectives; b) Test process, which shall identify the tests to be performed and describe the test profile of each security function. These profiles shall include the sequential dependencies on other test results; e) Expected test results, which shall indicate the expected output after the test is successful; d) Actual test results, which shall indicate that each tested security function can operate as specified. 6.6.4 Independent testing
6.6.4.1 Consistency
The developer shall provide a product suitable for testing, and the test set provided shall be consistent with the test set used when the developer self-tests the product functions. 6.6.4.2 Sampling
The developer shall provide a set of equivalent resources for sampling testing of security functions. 6.7 Vulnerability Analysis Assurance
6.7.1 Guidance Review
The developer shall provide guidance documents.
In the guidance documents, all possible operation modes of the product (including operation after failure or error), their consequences and significance for maintaining secure operation shall be determined. All assumptions of the target environment and all external security measures (including external procedural, physical or personnel control) requirements shall also be listed.
The guidance documents shall be complete, clear, consistent and reasonable. 8
6.7.2 Security Function Strength Assessment
GA/T989—2012
The developer shall conduct security function strength analysis for each security mechanism with security function strength statement identified in the guidance documents, and explain that the security mechanism meets or exceeds the minimum strength level and specific function strength metric defined in the guidance documents. 6.7.3 Developer Vulnerability Analysis
The developer shall perform vulnerability analysis and provide vulnerability analysis documents. Developers should analyze and document the various functions of the product based on the obvious ways that users may violate security policies. For identified vulnerabilities, developers should clearly record the measures taken. For each vulnerability, there should be evidence that the vulnerability cannot be exploited in the environment where the product is used. In the documentation, it should also be demonstrated that the product with identified vulnerabilities can resist obvious penetrating attacks. 7 Level classification requirements
7.1 Overview
Based on the development, production status and actual application of products related to electronic document security management, security function requirements, inherent security function requirements and security assurance requirements are divided into three levels. 7.2 Level classification of security function requirements
The level classification of security function requirements for electronic document security management products is shown in Table 1. Table 1 Electronic document security management product security function requirements Level classification Security function requirements
Trusted host registration
Trusted host management
Secure electronic document
Secure electronic document
Trusted host grouping
Trusted host deregistration
Secure electronic document
Security management strategy
Security management strategy
Security management policy
Host authentication
User identity authentication
Minimum feedback
Authentication data protection
Authentication failure processing
First level
4.2.2a)4.2.2b)
Second level
4.2. 2a)4.2. 2e)
\KacaOaiKAe
Third level3 Functional testing
The developer shall test the security functions, document the results and provide test documents. The test documents shall include the following:
a) Test plan, which shall identify the security functions to be tested and describe the test objectives; b) Test process, which shall identify the tests to be performed and describe the test profile of each security function. These profiles shall include the sequential dependencies on other test results; e) Expected test results, which shall indicate the expected output after the test is successful; d) Actual test results, which shall indicate that each tested security function can operate as specified. 6.6.4 Independent testing
6.6.4.1 Consistencywww.bzxz.net
The developer shall provide products suitable for testing. The test set provided shall be consistent with the test set used when testing the product functions themselves. 6.6.4.2 Sampling
The developer shall provide a set of equivalent resources for sampling testing of security functions. 6.7 Vulnerability analysis assurance
6.7.1 Guide review
The developer shall provide guide documents.
In the guidance document, all possible modes of operation of the product (including operations after failure or error), their consequences and significance for maintaining secure operation should be identified. All assumptions of the target environment and all external security measures (including external procedural, physical or personnel control) requirements should also be listed.
The guidance document should be complete, clear, consistent and reasonable. 8
6.7.2 Security Function Strength Assessment
GA/T989—2012
The developer shall perform a security function strength analysis for each security mechanism with a security function strength statement identified in the guidance document, and explain that the security mechanism meets or exceeds the minimum strength level and specific function strength measurement defined in the guidance document. 6.7.3 Developer Vulnerability Analysis
The developer shall perform a vulnerability analysis and provide vulnerability analysis documentation. The developer shall analyze and document the various functions of the product based on the obvious ways in which users may violate the security policy. For the identified vulnerabilities, the developer shall clearly record the measures taken. For each vulnerability, there should be evidence that the vulnerability cannot be exploited in the environment where the product is used. In the documentation, it should also be proved that the product with the identified vulnerability can resist obvious penetration attacks. 7 Level classification requirements
7.1 Overview
Based on the development, production status and actual application of products related to electronic document security management, security function requirements, inherent security function requirements and security assurance requirements are divided into three levels. 7.2 Level classification of security function requirements
The level classification of security function requirements for electronic document security management products is shown in Table 1. Table 1 Electronic document security management product security function requirements Level classification Security function requirements
Trusted host registration
Trusted host management
Secure electronic document
Secure electronic document
Trusted host grouping
Trusted host deregistration
Secure electronic document
Security management strategy
Security management strategy
Security management policy
Host authentication
User identity authentication
Minimum feedback
Authentication data protection
Authentication failure processing
First level
4.2.2a)4.2.2b)
Second level
4.2. 2a)4.2. 2e)
\KacaOaiKAe
Third level3 Functional testing
The developer shall test the security functions, document the results and provide test documents. The test documents shall include the following:
a) Test plan, which shall identify the security functions to be tested and describe the test objectives; b) Test process, which shall identify the tests to be performed and describe the test profile of each security function. These profiles shall include the sequential dependencies on other test results; e) Expected test results, which shall indicate the expected output after the test is successful; d) Actual test results, which shall indicate that each tested security function can operate as specified. 6.6.4 Independent testing
6.6.4.1 Consistency
The developer shall provide products suitable for testing. The test set provided shall be consistent with the test set used when testing the product functions themselves. 6.6.4.2 Sampling
The developer shall provide a set of equivalent resources for sampling testing of security functions. 6.7 Vulnerability analysis assurance
6.7.1 Guide review
The developer shall provide guide documents.
In the guidance document, all possible modes of operation of the product (including operations after failure or error), their consequences and significance for maintaining secure operation should be identified. All assumptions of the target environment and all external security measures (including external procedural, physical or personnel control) requirements should also be listed.
The guidance document should be complete, clear, consistent and reasonable. 8
6.7.2 Security Function Strength Assessment
GA/T989—2012
The developer shall perform a security function strength analysis for each security mechanism with a security function strength statement identified in the guidance document, and explain that the security mechanism meets or exceeds the minimum strength level and specific function strength measurement defined in the guidance document. 6.7.3 Developer Vulnerability Analysis
The developer shall perform a vulnerability analysis and provide vulnerability analysis documentation. The developer shall analyze and document the various functions of the product based on the obvious ways in which users may violate the security policy. For the identified vulnerabilities, the developer shall clearly record the measures taken. For each vulnerability, there should be evidence that the vulnerability cannot be exploited in the environment where the product is used. In the documentation, it should also be proved that the product with the identified vulnerability can resist obvious penetration attacks. 7 Level classification requirements
7.1 Overview
Based on the development, production status and actual application of products related to electronic document security management, security function requirements, inherent security function requirements and security assurance requirements are divided into three levels. 7.2 Level classification of security function requirements
The level classification of security function requirements for electronic document security management products is shown in Table 1. Table 1 Electronic document security management product security function requirements classification Security function requirements
Trusted host registration
Trusted host management
Secure electronic document
Secure electronic document
Trusted host grouping
Trusted host deregistration
Secure electronic document
Security management strategy
Security management strategy
Security management policy
Host authentication
User identity authentication
Minimum feedback
Authentication data protection
Authentication failure processing
First level
4.2.2a)4.2.2b)
Second level
4.2. 2a)4.2. 2e)
\KacaOaiKAe
Third level
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.