|
US$329.00 · In stock
Delivery: <= 3 days. True-PDF full-copy in English will be manually translated and delivered via email.
GA/T 913-2019: Information security technology - Security technology requirements for database security audit products
Status: Valid GA/T 913: Evolution and historical versions
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GA/T 913-2019 | English | 329 |
Add to Cart
|
3 days [Need to translate]
|
Information security technology - Security technology requirements for database security audit products
| Valid |
GA/T 913-2019
|
| GA/T 913-2010 | English | 559 |
Add to Cart
|
3 days [Need to translate]
|
Information security technology. Security technology requirements for database s
| Obsolete |
GA/T 913-2010
|
PDF similar to GA/T 913-2019
Basic data | Standard ID | GA/T 913-2019 (GA/T913-2019) | | Description (Translated English) | Information security technology - Security technology requirements for database security audit products | | Sector / Industry | Public Security (Police) Industry Standard (Recommended) | | Classification of Chinese Standard | A90 | | Classification of International Standard | 35.240 | | Word Count Estimation | 14,164 | | Date of Issue | 2019 | | Date of Implementation | 2019-01-13 | | Issuing agency(ies) | Ministry of Public Security | GA/T 913-2019: Information security technology - Security technology requirements for database security audit products
---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Information security technology-Security technology requirements for database security audit products
ICS 35.240
A 90
GA
People's Republic of China Public Safety Industry Standard
Replaces GA/T 913-2010
Information Security Technology Database Security Audit Product Security Technology
Technical requirements
Information security technology Security technology requirements for database
security audit products
Published by the Ministry of Public Security of the People's Republic of China
Contents
Foreword ... II
1 Scope ... 1
2 Normative references ... 1
3 Terms and definitions ... 1
4 General description ... 2
4.1 Classification of safety technical requirements ... 2
4.2 Classification of Security Levels. 2
5 Safety function requirements ... 2
5.1 Audit Generation Unit Component Requirements ... 2
5.2 Audit response unit component requirements ... 3
5.3 Audit processing unit component requirements ... 3
5.4 Identification and authentication ... 4
5.5 Security Management ... 5
5.6 Audit logs ... 5
6 Security requirements ... 6
6.1 Development ... 6
6.2 Guidance documents ... 7
6.3 Life cycle support ... 7
6.4 Testing ... 8
6.5 Vulnerability assessment ... 8
7 Classification requirements ... 8
7.1 Safety function requirements ... 9
7.2 Security requirements ... 10
Foreword
This standard was drafted in accordance with the rules of GB/T 1.1-2009.
This standard replaces GA/T 913-2010 "Security Technical Requirements for Information Security Technology Database Security Audit Products" and GA/T 913-2010
The main technical changes are as follows.
-Added the contents of "Classification of Security Technical Requirements" and "Classification of Security Levels" (see 4.1, 4.2);
--Modified the contents of "Data Collection", "Collection Strategy", and "Security Alert" (see 5.1.1, 5.1.2, 5.2.1,.2010)
4.1.1, 4.1.4, 4.2.1 of the annual version);
-Deleted the contents of "Remote Confidential Transmission" and "Trusted Management Host" (see 5.2.3 and 5.2.4 of the.2010 version);
-Added the content of "Remote Security Management" (see 5.5.3);
-Unified "safety function requirements" and "own safety function requirements" into "safety function requirements" (see Chapter 5,.2010
Chapters 4 and 5 of the annual edition);
-Modify the "security assurance requirements" to "security assurance requirements" and adjust the corresponding content (see Chapter 6, Chapter 6 of the.2010 edition);
-The levels are uniformly divided into basic and enhanced levels (see Chapter 7, Chapter 7 of the.2010 edition).
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.
This standard was drafted. Computer Information System Security Product Quality Supervision and Inspection Center of the Ministry of Public Security (Third Research Institute of the Ministry of Public Security), Hangzhou
Anheng Information Technology Co., Ltd.
The main drafters of this standard. Yu You, Deng Qi, Shen Liang, Zhao Ting, Li Yi, Gu Jian, Chen Yucheng, Gu Wei, Fan Yuan, and Sun Xiaoping.
Publication of previous versions of this standard.
--GA/T 913-2010.
Information security technology database security audit product security technical requirements
1 Scope
This standard specifies the security function requirements, security guarantee requirements, and classification requirements for database security audit products.
This standard applies to the design, development, and testing of database security audit products.
2 Normative references
The following documents are essential for the application of this document. For dated references, only the dated version applies to this document.
For undated references, the latest version (including all amendments) applies to this document.
GB/T 18336.3-2015 Information technology security technology Information technology security assessment guidelines Part 3. Security assurance components
GB/T 25069-2010 Information Security Technology Terminology
3 terms and definitions
GB/T 18336.3-2015 and GB/T 25069-2010 and the following terms and definitions apply to this document.
3.1
Database security audit product
A product that records, analyzes, and responds to user actions when accessing the database.
3.2
Audit record
Data generated by auditing the user's access to the database.
3.3
Audit log
Data generated by the audit of the database security audit product itself.
3.4
Audit producing unit
A functional unit that collects and generates audit records.
3.5
Audit responding unit
A functional unit that responds to a specified event.
3.6
Audit processing unit
Functional unit for statistics and management of audit records.
4 General description
4.1 Classification of safety technical requirements
This standard divides the database security audit product security technical requirements into two categories. security function requirements and security assurance requirements. Among them, safety
Functional requirements are specific requirements for the security functions that database security audit products should have; security assurance requirements are for database security audits
The product's life cycle process puts forward specific requirements, including development, guidance documents, life cycle support and testing.
4.2 Classification of security levels
The security level of the database security audit product is divided into basic level and enhanced according to the strength of its security function requirements and security assurance requirements.
Level, in which the security requirements refer to GB/T 18336.3-2015.
5 Safety function requirements
5.1 Audit Generation Unit Component Requirements
5.1.1 Data Collection
The product should be able to gather at least the following information about database operation behavior from the target environment.
a) Event subject. source IP address, source MAC address, source port, and operating user;
b) Event object. destination IP address, destination MAC address, destination port and operation object. The operation object includes database, data
Data tables, data table fields, etc .;
c) the date and time of the event;
d) Event type. such as data operation class, structure operation class, transaction operation class, user management class and other auxiliary operation classes;
e) Event description. specific content of the operation, such as operation statements;
f) Event result. success or failure, number of affected rows, response time, number of returned rows, etc.
5.1.2 Collection Strategy
The product should be able to set a collection strategy based on a combination of the following conditions.
a) the subject of the event;
b) the object of the event;
c) the date and time of the event;
d) event type;
e) keywords for event descriptions;
f) Event results.
5.1.3 Audit record generation
When an audit event occurs, the product should generate audit records in a timely manner in accordance with the collection strategy.
5.1.4 Impact on the system
The data collection method and process should not have a significant impact on the performance of the database.
5.1.5 Communication encryption support
When users access the database using the encryption method supported by the product, the product should have the ability to collect the information in 5.1.1.
5.2 Audit response unit component requirements
5.2.1 Security alarm
The product should be able to alert the following abnormal events.
a) Custom violation events, such as deleting important data, affecting rows and returning rows exceeding thresholds;
b) injection attacks;
c) Database vulnerability attacks.
5.2.2 Alarm content
The alarm information should include at least the following.
a) the subject of the alarm event;
b) the object of the alarm event;
c) description of alarm events;
d) the date and time when the alarm event occurred;
e) Alarm event danger level.
5.2.3 Alarm mode
The product should use one or more methods such as real-time screen prompts, email alerts, and SMS alerts.
5.2.4 Response measures
The product shall adopt such methods as direct blocking or linkage with other network security products to process and record abnormal events.
5.3 Audit processing unit component requirements
5.3.1 Audit record query
5.3.1.1 Limited audit inspection
The product should only allow authorized administrators to access audit records.
5.3.1.2 Optional query
Authorized administrators should be able to perform combined queries and sorts based on the following criteria.
a) the subject of the event;
b) the object of the event;
c) event type;
d) the date and time of the event.
5.3.2 Audit record statistics
5.3.2.1 Report generation
Products should be able to generate reports based on the following requirements.
a) Have a default report template for statistics and analysis of audit records, abnormal events, etc .;
b) Customize the report according to conditions such as event subject, event object, and event type.
5.3.2.2 Report export
Statistical reports should support the export of commonly used document formats.
5.3.3 Audit record storage
5.3.3.1 Audit record protection
Products shall have security measures to prevent audit records from being deleted, leaked or tampered with without authorization.
5.3.3.2 Prevention of loss of audit records
The product shall provide the following measures to prevent the loss of audit records.
a) The audit records should be stored in a non-volatile storage medium after power failure, and the default storage period should be more than 6 months;
b) be able to notify authorized administrators when the storage capacity of audit records reaches a threshold;
c) Before the storage space of the audit records is exhausted, back up the audit records to other storage spaces by using automatic dumping or other methods.
5.3.3.3 Audit record backup
The product shall provide the following audit record backup measures.
a) Customizable automated backup strategy;
b) Support backup to other storage devices.
5.3.4 Session analysis
The product should be able to analyze all operation information of the same session based on a single audit record association.
5.4 Identification and identification
5.4.1 User Identification
5.4.1.1 Attribute Definition
The product shall specify security attributes associated with each user, such as identification, authentication information, and permissions.
5.4.1.2 Property initialization
The product should provide the ability to initialize the attributes of each user created with default values.
5.4.1.3 Unique identification
The product should provide the user with a unique identity and associate the user's identity with all auditable events for that user.
5.4.2 Identity authentication
5.4.2.1 Basic authentication
The product shall authenticate the user before performing any operations related to the security function.
5.4.2.2 Authentication data protection
The product shall ensure that the authentication data is not unauthorized access or modification.
5.4.2.3 Handling of authentication failure
When the number of failed user authentications reaches the specified number, the product shall be able to terminate the user's access.
5.4.2.4 Timeout lock or logout
The product should have login timeout lockout or logout capabilities. In the case of no operation for a set period of time, terminating the session requires
Re-authentication can be performed again. The maximum timeout period is set only by an authorized administrator.
5.5 Safety Management
5.5.1 Security Function Management
Authorized administrators should be able to manage the product.
a) View and modify related security attributes;
b) enable or disable all or part of the audit function;
c) Develop and modify various security policies.
5.5.2 Security Role Management
The product should be able to distinguish between administrator roles.
a) Administrator role with different permissions;
b) Define different authority roles according to different function modules.
5.5.3 Remote Security Management
If the product supports communication over the network, the following technical requirements should be met.
a) prevent remote session information from being leaked and tampered with;
b) Limit the address of the remote management host.
5.6 Audit logs
5.6.1 Audit log generation
The product should generate audit logs for the following events.
a) Administrator login success and failure;
b) changes to security policies;
c) Add, delete and modify attributes to the administrator;
d) Back up audit records.
Each audit log should include at least the date, time, user ID, event description, and result of the event. If using remote login
The way to manage the product should also record the address of the management host.
5.6.2 Audit log storage
The audit log should be able to be stored in a non-volatile storage medium at power failure.
5.6.3 Audit log management
The product shall provide the following audit log management functions.
a) Only authorized administrators are allowed to access the audit log;
b) query function for audit logs;
c) Save and export audit logs.
6 Security requirements
6.1 Development
6.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.
6.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.
6.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.
6.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.
6.2 Guidance Documents
6.2.1 Operation User Guide
Developers should provide clear and reasonable operating user guides, which are kept in line with all other documents provided for evaluation
Sincerely, 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 implemented to fully achieve security purposes.
6.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.
6.3 Life cycle support
6.3.1 Configuration management capabilities
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.
6.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.
6.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.
6.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.
6.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.
6.3.6 Tools and techniques
Developers should clearly define the tools used to develop the product, and provide development tool documentation to unambiguously define the meaning of each statement in the implementation
And the meaning of all implementation-dependent options.
6.4 Test
6.4.1 Test coverage
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.
6.4.2 Test 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.
6.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 between actual test results and expected test results.
6.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.
6.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.
7 Requirements for different security levels
7.1 Safety function requirements
The security function requirements of database security audit products of different security levels are shown in Table 1.
Table 1 Security function requirements of database security audit products with different security levels
Security functions require basic level enhanced level
Audit order
Meta component requirements
Data collection 5.1.1 5.1.1
Acquisition strategy
5.1.2
a) ～ c)
5.1.2
Audit record generation 5.1.3 5.1.3
Impact on the system 5.1.4 5.1.4
Communication encryption support-5.1.5
Audit Response Form
Meta component requirements
Security alert 5.2.1 a) 5.2.1
Alarm content 5.2.2 5.2.2
Alarm mode 5.2.3 5.2.3
Response-5.2.4
Audit Processing Order
Meta component requirements
Audit record query
Limited audit review 5.3.1.1 5.3.1.1
Optional query 5.3.1.2 5.3.1.2
Audit record statistics
Report generation 5.3.2.1 a) 5.3.2.1
Report export 5.3.2.2 5.3.2.2
Audit record storage
Audit record protection 5.3.3.1 5.3.3.1
Audit record loss prevention
5.3.3.2
a), b)
5.3.3.2
Audit record backup-5.3.3.3
Session analysis-5.3.4
Identification and authentication
User ID
Attribute definition 5.4.1.1 5.4.1.1
Attribute initialization 5.4.1.2 5.4.1.2
Unique identification 5.4.1.3 5.4.1.3
Identity authentication
Basic authentication 5.4.2.1 5.4.2.1
Discrimination data protection 5.4.2.2 5.4.2.2
Authentication Failure Handling-5.4.2.3
Lockout or logout over time-5.4.2.4
Safety management
Security Function Management 5.5.1 5.5.1
Security role management 5.5.2 a) 5.5.2
Remote secure transmission 5.5.3 a) 5.5.3
Table 1 (continued)
Security functions require basic level enhanced level
Audit log
Audit log generation
5.6.1
a) ～ c)
5.6.1
Audit log storage 5.6.2 5.6.2
Audit log management 5.6.3 5.6.3
7.2 Security requirements
Table 2 shows the security assurance requirements for database security audit products with different security levels.
Table 2 Security assurance requirements for database security audit products with different security levels
Security Assurance Requirements Basic Level Enhanced Level
Develop
Security architecture 6.1.1 6.1.1
Functional specifications
6.1.2
a) ~ f)
6.1.2
Implementation representation-6.1.3
product design
6.1.4
a) ～ d)
6.1.4
Guidance Document
Operatio...
Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of GA/T 913-2019_English be delivered?Answer: Upon your order, we will start to translate GA/T 913-2019_English as soon as possible, and keep you informed of the progress. The lead time is typically 1 ~ 3 working days. The lengthier the document the longer the lead time. Question 2: Can I share the purchased PDF of GA/T 913-2019_English with my colleagues?Answer: Yes. The purchased PDF of GA/T 913-2019_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet. Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay. Question 5: Should I purchase the latest version GA/T 913-2019?Answer: Yes. Unless special scenarios such as technical constraints or academic study, you should always prioritize to purchase the latest version GA/T 913-2019 even if the enforcement date is in future. Complying with the latest version means that, by default, it also complies with all the earlier versions, technically.
|