GA/T 1574-2019Information security technology - Security technology requirements for database security reinforcement products (English PDF)

5.1 Classification of safety technical requirements

This standard divides the database security hardening product security technical requirements into security function requirements, own security function requirements, and security assurance requirements Three categories. Among them, the security function requirements are specific requirements for the security functions that database security hardening products should have, including dual system authentication, Data storage encryption, application permission control, ciphertext access control, ciphertext index, integrity check, permission separation, database status monitoring, Other functional requirements, etc .; the requirements for own security functions are requirements for the security functions that the database security hardening product should have.

Including user identification, identity authentication, anti-unloading functions, security management and audit logs, etc .; security assurance requirements for database security hardening products the content of the product development and use documents put forward specific requirements, including development, instructional documents, life cycle support and testing.

The administrator account of the database security hardening product should adopt at least three separate designs, including system administrator, security administrator, and security Auditor.

5.2 Classification of security levels

This standard divides the level of security function requirements according to the strength of the database security hardening product security function.

GB/T 18336.3-2015 divides the levels of security requirements. The security level highlights security features, and is divided into basic and enhanced levels.

Strength, weakness, and security requirements are the specific basis for the classification.

6.1 Dual system authentication

In addition to the database management system's authentication, the database management system account should also strengthen the identity of the product through database security.

Identification.

6.2 Data storage encryption

The product supports data encryption.

a) should be able to encrypt the specified data;

b) data encryption granularity should support table/field level;

c) Support random number encryption technology to ensure that the same plaintext data is encrypted differently after being encrypted;

d) Encryption algorithms specified by the National Password Administration shall be supported.

6.3 Application permission control

The product should be able to bind the application system, IP address and database management system account to ensure that only trusted database management systems Accounts and application systems have access to ciphertext data only through specific IP addresses.

6.4 Ciphertext Access Control

The product provides access control for ciphertext data.

a) A separate authority control system should be provided for the database management system itself. All accounts (including database management system privileged accounts) Before accessing the ciphertext data, the authorization of the product administrator should be hardened through the database;

b) Should support the range of ciphertext data and access rights (such as database management system privileged accounts) that can be accessed by all accounts (such as database management system privileged accounts) Add, modify, and delete permissions);

c) It should have the function of limiting the time range of ciphertext data access;

d) It shall have the function of limiting the source IP address range for ciphertext data access.

6.5 Ciphertext Index

The product supports the ciphertext index function and can manage the ciphertext index.

6.6 Integrity check

The product supports data integrity check function.

a) It shall be possible to perform integrity checks on the data stored in the database;

b) There should be automatic recovery measures for critical data products where integrity is detected to be compromised.

6.7 Separation of permissions

Products should be separated from database hardening product management permissions to achieve privilege user privilege separation and at least have system management Administrators, security administrators, and security auditors. The system administrator is responsible for system configuration, system operation status monitoring, etc .; the security administrator is responsible for Responsible for security maintenance such as ciphertext data configuration and ciphertext permission control. The security auditor is responsible for controlling audit switches, viewing audit data, Management of audit data. Database hardening products do not allow super administrators with all permissions.

6.8 Database Status Monitoring

The product should support the status monitoring of the database. The monitoring content should include the database startup time, user connection time, and table space status.

Average execution frequency, etc.

6.9 Other functional requirements

The product has the following functions.

a) After the product is installed, it should not affect the original data stored in the database management system;

b) It should have a sensitive data discovery function to automatically discover sensitive data information;

c) It should have a vulnerability scanning function, which can detect risks such as weak passwords, permission configuration, and default account.

7.1 User Identification

7.1.1 Attribute Definition

The product should specify the security attributes associated with each administrator, such as identification, authentication information, membership groups, permissions, and so on.

7.1.2 Property Initialization

The product should be capable of initializing the attributes of each administrator created with default values.

7.1.3 Unique identification

The product shall ensure that any user has a globally unique identity.

7.2 Identity

7.2.1 Basic authentication

The product shall authenticate the user before performing any operation related to the security function.

7.2.2 Authentication Failure Handling

When the number of user authentication failures reaches the specified threshold, the product shall prevent the user from further authentication requests and generate relevant information for review.

Meter event.

7.2.3 Timeout lock or logout

The product should have a user login timeout lockout or logout function that terminates the user when the user has not done anything for more than a predefined time the current management session needs to be authenticated again to resume management operations.

7.2.4 Authentication data protection

The product shall protect authentication data from unauthorized access and modification.

7.3 Anti-unloading function (if applicable)

The product should be able to provide some protection to the security agent installed on the database server to prevent unauthorized users from performing the following operations.

a) Forcibly terminate the operation of this component;

b) Forcibly cancel the automatic loading of the component when the system starts;

c) Forcibly uninstall, delete or modify the component.

7.4 Safety management

7.4.1 Remote secure transmission

The product has the following secure transmission functions.

a) security measures shall be taken to ensure the security of data transmission between components;

b) If the product supports remote management, ensure the confidential transmission of remote management data.

7.4.2 Trusted Management Address

If the product provides remote capabilities, it should be possible to restrict the host addresses that can be remotely managed.

7.5 Audit logs

7.5.1 Audit log generation

The product shall be able to generate audit records for the following events.

a) administrators identify success and failure events;

b) the ciphertext authorization event of the administrator;

c) user identification events;

d) events when users access ciphertext data;

e) events where the administrator encrypts and decrypts sensitive data;

f) the number of unsuccessful authentication attempts by the administrator exceeds the set limit and causes the session connection to be terminated;

g) integrity verification events;

h) other events.

The product shall record the date and time of the event, the identity of the event subject, the event description, the success or failure in each audit record.

Sign.

7.5.2 Audit log management

Products shall provide security audit review tools and meet.

a) allow only authorized administrators to access the audit log;

b) Combine search based on date, time, user identification, etc .;

c) Audit logs can be emptied and exported.

7.5.3 Audit log storage

The audit log should be stored in a non-volatile storage medium after power failure, and the storage period cannot be less than 6 months.

8.1 Development

8.1.1 Security Architecture

The developer should provide a description of the security architecture of the product's security functions. The description of the security architecture should meet the following requirements.

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

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

c) describe why the product safety function initialization process is safe;

d) confirm that product safety functions can be prevented from being compromised;

e) Verify that product safety functions prevent safety features from being bypassed.

8.1.2 Functional Specifications

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

a) fully describe the safety functions of the product;

b) describe the purpose and use of all safety function interfaces;

c) identify and describe all parameters related to each safety function interface;

d) describe the safety function implementation behavior related to the safety function interface;

e) describe direct error messages caused by the behavioral processing of safety functions;

f) confirm that the safety function requires traceability to the safety function interface;

g) describe all actions related to the safety function interface during the implementation of the safety function;

h) Describe all direct error messages that may be caused by the call of the safety function interface.

8.1.3 Implementation Representation

Developers should provide implementation representations for all security functions. Implementation representations should meet the following requirements.

a) Provide a mapping between product design descriptions and implementation representation examples and prove their consistency;

b) Define product safety functions according to the level of detail, to a level of detail that can be generated without further design;

c) Provided in the form used by developers.

8.1.4 Product Design

Developers should provide product design documents, which should meet the following requirements.

a) describe the product structure in terms of subsystems;

b) identify and describe all subsystems of product safety functions;

c) describe the interaction between all subsystems of the safety function;

d) the mapping relationship provided can verify that all the behaviors described in the design can be mapped to the security function interface that calls it;

e) describe safety functions according to the module;

f) Provide the mapping relationship between the safety function subsystem and the module;

g) describe all safety function implementation modules, including their purpose and interaction with other modules;

h) Describe the relevant interfaces required by all modules to implement the security functions, return values from other interfaces, interactions with other modules, and Called interface

i) Describe the supporting or related modules of all safety functions, including their purpose and interaction with other modules.

8.2 Guidance documents

8.2.1 Operation User Guide

Developers should provide clear and reasonable operating user guides that are consistent with all other documentation provided for evaluation, the description of each user role should meet the following requirements.

a) describe the functions and privileges accessible to users controlled in a secure processing environment, including appropriate alert information;

b) describe how to use the available interfaces provided by the product in a secure manner;

c) describe available functions and interfaces, especially all safety parameters controlled by the user, and indicate safety values where appropriate;

d) clearly state each security-related event related to the user-accessible function that needs to be performed, including changes to the control of the security function Security features of the entity;

e) identify all possible states of operation of the product (including failures or operational errors caused by operations), and their relevance to maintaining safety Causality and connection between operations;

f) Security policies that must be implemented to fully achieve security purposes.

8.2.2 Preparation procedures

The developer shall provide the product and its preparation procedures. The preparation procedure description shall meet the following requirements.

a) describe all steps necessary to securely receive the delivered product in accordance with the developer delivery process;

b) Describe all steps necessary to safely install the product and its operating environment.

8.3 Life cycle support

8.3.1 Configuration Management Capability

Developer configuration management capabilities should meet the following requirements.

a) provide unique identification for different versions of the product;

b) use a configuration management system to maintain all configuration items that make up the product and uniquely identify configuration items;

c) Provide configuration management documents, which describe the method used to uniquely identify configuration items;

d) The configuration management system provides an automatic way to support the generation of products, by which it is ensured that only the implementation of the products can be expressed Authorized changes;

e) The configuration management document includes a configuration management plan, which describes how to develop products using a configuration management system. real the implementation of the configuration management is consistent with the configuration management plan;

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

8.3.2 Configuration Management Scope

The developer should provide a list of product configuration items and describe the developer of the configuration item. The configuration item list should include the following.

a) Evaluation evidence of products, safety assurance requirements and components of products;

b) Implementation indication, security defect report and resolution status.

8.3.3 Delivery procedures

Developers should use a certain delivery procedure to deliver the product and document the delivery process. When delivering versions of the product to the user, the delivery documentation should describe all procedures necessary to maintain security.

8.3.4 Development Security

Developers should provide development security documentation. The development security documentation should describe the design and implementation all physical, procedural, personal and other security measures necessary for confidentiality and integrity.

8.3.5 Life Cycle Definition

The developer should establish a life cycle model to control the development and maintenance of the product, and provide a description of the life cycle definition document.

Describe the models used to develop and maintain products.

8.3.6 Tools and techniques

The developer should clearly define the tools used to develop the product and provide development tools. The document unambiguously defines the content of each statement in the implementation.

Meaning and meaning of all implementation-dependent options.

8.4 Test

8.4.1 Cover

The developer should provide a test coverage document, and the test coverage description should meet the following requirements.

a) indicate the correspondence between the tests identified in the test documentation and the safety functions of the product described in the functional specification;

b) Show that the above correspondence is complete and confirm that all safety function interfaces in the functional specification have been tested.

8.4.2 Depth

Developers should provide test depth analysis. The test in-depth analysis description should meet the following requirements.

a) confirm the consistency between the tests in the test documentation and the safety function subsystem and implementation modules in the product design;

b) Verify that all safety function subsystems and implementation modules in the product design have been tested.

8.4.3 Functional test

Developers should test product security features, document results and provide test documentation. The test documentation should include the following.

a) A test plan that identifies the tests to be performed and describes the scenarios for each test, including those for other test results any order dependency;

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

c) Consistency of actual test results and expectations.

8.4.4 Independent testing

Developers should provide a set of resources equivalent to those used for self-testing security features for sample testing of security features.

8.5 Vulnerability assessment

Based on the identified potential vulnerabilities, the product is resistant to the following attacks.

a) attacks by attackers with basic attack potential;

b) Attacks by attackers with enhanced basic attack potential.

9.1 Overview

Divided into basic level and enhanced according to the security function requirements, own security function requirements and security guarantee requirements of database security hardening products level.

9.2 Classification of safety function requirements

Table 1 lists the security function requirements of database security hardening products.

Table 1.Classification of security function requirements for database security hardening products

Security functions require basic level enhanced level Dual system identification 6.1 6.1 Data storage encryption 6.2 a), b) 6.2 Application permission control-6.3 Ciphertext access control 6.4 a), b) 6.4 Ciphertext Index-6.5 Integrity Check-6.6 Separation of permissions 6.7 6.7 Database Condition Monitoring 6.8 6.8 Other functional requirements 6.9 a) 6.9

9.3 Classification of self-safety function requirements

Table 2 shows the classification requirements of the database security hardening products' own security functions.

Table 2 Classification of requirements for database security hardening products' own security functions

Self-safety function requires basic level enhanced level User ID Attribute definition 7.1.1 7.1.1 Property initialization 7.1.2 7.1.2

Table 2 (continued)

Self-safety function requires basic level enhanced level Identity authentication Basic identification 7.2.1 7.2.1 Authentication failure handling-7.2.2 Timeout lock or logout 7.2.3 7.2.3 A...