|
US$919.00 · In stock
Delivery: <= 7 days. True-PDF full-copy in English will be manually translated and delivered via email.
GB/T 37931-2019: Information security technology - Security technology requirements and testing and evaluation approaches for Web application security detection system
Status: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GB/T 37931-2019 | English | 919 |
Add to Cart
|
7 days [Need to translate]
|
Information security technology - Security technology requirements and testing and evaluation approaches for Web application security detection system
| Valid |
GB/T 37931-2019
|
PDF similar to GB/T 37931-2019
Basic data | Standard ID | GB/T 37931-2019 (GB/T37931-2019) | | Description (Translated English) | Information security technology - Security technology requirements and testing and evaluation approaches for Web application security detection system | | Sector / Industry | National Standard (Recommended) | | Classification of Chinese Standard | L80 | | Classification of International Standard | 35.040 | | Word Count Estimation | 46,474 | | Date of Issue | 2019-08-30 | | Date of Implementation | 2020-03-01 | | Issuing agency(ies) | State Administration for Market Regulation, China National Standardization Administration | GB/T 37931-2019: Information security technology - Security technology requirements and testing and evaluation approaches for Web application security detection system
---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 and testing and evaluation approaches for Web application security detection system
ICS 35.040
L80
National Standards of People's Republic of China
Information Security Technology Web Application Security Detection
System safety technical requirements and test evaluation methods
2019-08-30 released
2020-03-01 Implementation
State Administration for Market Regulation
Issued by China National Standardization Administration
Table of contents
Preface Ⅲ
1 Scope 1
2 Normative references 1
3 Terms and definitions 1
4 Abbreviations 1
5 Product description 2
6 Safety technical requirements 2
6.1 Basic level safety technical requirements 2
6.1.1 Safety function requirements 2
6.1.2 Self-safety requirements 4
6.1.3 Safety assurance requirements 5
6.2 Enhanced safety technical requirements 7
6.2.1 Safety function requirements 7
6.2.2 Own safety requirements 10
6.2.3 Safety assurance requirements 12
7 Evaluation method 14
7.1 Evaluation of basic safety technical requirements 14
7.1.1 Safety function evaluation 14
7.1.2 Self-safety assessment 19
7.1.3 Safety assurance requirements evaluation 22
7.2 Evaluation of enhanced safety technical requirements 25
7.2.1 Safety function evaluation 25
7.2.2 Self-safety assessment 32
7.2.3 Safety assurance requirements evaluation 35
Foreword
This standard was drafted in accordance with the rules given in GB/T 1.1-2009.
This standard was proposed and managed by the National Information Security Standardization Technical Committee (SAC/TC260).
Drafting organizations of this standard. The Third Research Institute of the Ministry of Public Security (Computer Information System Security Product Quality Supervision and Inspection Center of the Ministry of Public Security), National Trust
Information Technology Security Research Center, Hangzhou Anheng Information Technology Co., Ltd., Wangshen Information Technology (Beijing) Co., Ltd., Beijing Shenzhou
NSFOCUS Technology Co., Ltd., Shanghai Tiantai Network Technology Co., Ltd., Beijing Tianrongxin Network Security Technology Co., Ltd., Zhejiang Electronic Information
Product Inspection Institute, Shanghai Jiaweisi Information Technology Co., Ltd., State Grid Corporation of China.
The main drafters of this standard. Yu You, Jia Huihui, Yang Yuanyuan, Lu Zhen, Zou Chunming, Gu Jian, Wan Renzhong, Li Bing, Fang Jinshe, Ji Chonglian, Li Meng,
Liu Nan, Zhang Jun, Shen Liang, Fan Yuan, Wu Yunkun, Ye Xiaohu, Cheng Shengnian, Lei Xiaofeng, Sun Xiaoping, Wang Zhijia, Jin Haijun, Wang Wei, Xiang Zhi, Zhao Jianfei,
Deng Qi, Qu Xiaodong, Tang Di, Meng Yahao, Ma Haiyan, Yang Zhuoqi, Cai Lijun, Li Jing, Shu Shouheng, Wu Shun, Liu Yongqing, Lian Jiwen.
Information Security Technology Web Application Security Detection
System safety technical requirements and test evaluation methods
1 Scope
This standard specifies the safety technical requirements, evaluation methods and classification of Web application safety inspection systems.
This standard applies to the design, development and evaluation of Web application security detection systems.
2 Normative references
The following documents are indispensable for the application of this document. For dated reference documents, only the dated version applies to this article
Pieces. 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 Criteria Part 3.Security Assurance Components
GB/T 25069-2010 Information Security Technical Terms
3 Terms and definitions
The following terms and definitions defined in GB/T 18336.3-2015 and GB/T 25069-2010 apply to this document.
3.1
Web application security detection system
Products that detect the security of web applications can discover URLs of web applications based on policies
Vulnerabilities are detected.
3.2
URL discovery
Starting from a URL, discover other URLs that can be linked to through that URL, including the complete URL that appears in the web page,
URLs obtained through various calculations, URLs for various redirects, etc.
3.3
Deformation detection
A detection mechanism that bypasses the protection filtering through methods such as encoding and request packet changes.
4 Abbreviations
The following abbreviations apply to this document.
5 Product description
The web application security detection system uses URL discovery, web vulnerability detection and other technologies to analyze the security of web applications.
The whole purpose is to help application developers and managers understand the vulnerabilities of web applications, and to improve and enhance application systems to resist all kinds of
Web application attacks (such as injection attacks, cross-site scripting, file inclusion and information disclosure, etc.) capabilities to help users build secure Web application services.
This standard divides the security technical requirements of Web application security detection systems into security functional requirements, own security requirements and security assurance requirements
Three major categories. Among them, the security function requirements put forward specific requirements for the security functions that the web application security detection system should have.
Including detection capabilities, detection task management, and detection result analysis and processing, etc.; its own security requirements are for the identification of Web application security detection systems
Put forward specific requirements for authentication, security management and audit logs; security assurance requirements are for the life cycle of Web application security detection systems
The process puts forward specific requirements, including development, guidance documents, life cycle support and testing.
This standard divides the security levels of Web application security detection systems (hereinafter referred to as "products") into basic and enhanced levels. security function
The strength of its own security and the level of security requirements are the specific basis for classification, and the security level highlights the safety characteristics. And basic
Compared with the content of the enhanced level, the content that has been increased or changed in the enhanced level is indicated by "in bold" in the text.
6 Safety technical requirements
6.1 Basic level safety technical requirements
6.1.1 Safety function requirements
6.1.1.1 Detection capability
6.1.1.1.1 Resource Discovery
Products should be able to find various URLs in web applications, and the proportion of URLs found should be higher than 90%. URL discovery includes but is not limited to.
a) URL obtained by parsing and executing scripts such as JavaScript;
b) The URL contained in the page file;
c) URL embedded in Flash.
6.1.1.1.2 Web application vulnerability detection
The product should be able to detect web application vulnerabilities, and the false negative rate and false positive rate of the same type of vulnerabilities should be less than 20%. Types of vulnerabilities include but are not limited to.
a) SQL injection vulnerabilities, including injection vulnerabilities submitted based on Get and Post methods that should include characters, numbers, and searches;
b) Cookie injection vulnerabilities, including injection vulnerabilities submitted based on cookies that should include characters, numbers, and searches;
c) XSS vulnerabilities, including cross-site attack vulnerabilities based on Get and Post methods;
d) CSRF vulnerability;
e) Directory traversal vulnerability;
f) Information disclosure vulnerabilities, including path disclosure, backup files, source code disclosure, directory browsing and phpinfo and other information disclosure vulnerabilities;
g) The authentication method is weak, such as weak passwords, etc.;
h) Files contain vulnerabilities, including remote and local files contain vulnerabilities.
6.1.1.1.3 Upgrade
The product should have the ability to update the vulnerability signature database.
6.1.1.1.4 Support HTTPS
The product should be able to detect web applications based on the HTTPS protocol.
6.1.1.1.5 Does not affect the target object
The product should avoid affecting the normal operation of the target Web application during the detection process.
6.1.1.2 Inspection task management
6.1.1.2.1 Wizard function
The product should provide a wizard function to guide users to the correct configuration.
6.1.1.2.2 Detection range
The product should be able to configure the detection range according to the following conditions.
a) Specify the domain name and URL;
b) the depth of inspection;
c) URLs that are not checked, such as logout, delete and other related pages.
6.1.1.2.3 Login detection
The product should be able to detect web applications based on login information. Such as based on recording information, Cookie, Session, Token, etc.
Or multiple ways to authorize login and perform detection.
6.1.1.2.4 Strategy selection
The product should be able to select the detection strategy in the following ways.
a) Type of vulnerability;
b) The vulnerability hazard level.
6.1.1.2.5 Detection speed adjustment
The product should be able to adjust the detection speed by configuring the HTTP request speed, the number of detection threads or processes, etc.
6.1.1.2.6 Task customization
Products should be able to realize batch start-up detection according to planned tasks, and automatically generate corresponding results according to the settings.
6.1.1.2.7 Progress control
The product should be able to control the progress of the test as follows.
a) Stop at any time;
b) Resume scanning after a breakpoint.
6.1.1.3 Analysis and processing of test results
6.1.1.3.1 Result verification
The product should have the function of web application vulnerability verification, and be able to provide parameters to further detect XSS vulnerabilities, SQL injection points, directory traversal,
Vulnerabilities such as information leakage and command execution are verified.
6.1.1.3.2 Results save
The test results should be stored in non-clear text in a non-volatile storage medium after power failure.
6.1.1.3.3 Statistical analysis
The product should be able to perform statistical analysis on the number of vulnerabilities, vulnerability types and hazard levels based on the detection results.
6.1.1.3.4 Report generation
The product should be able to analyze the test results and form a report, the report should include.
a) Vulnerability information such as vulnerability location, vulnerability name, vulnerability description and hazard level;
b) Suggestions for bug fixes.
6.1.1.3.5 Report output
The product test report should be output according to the following requirements.
a) Common document formats, such as DOC, PDF and HTML;
b) Display in a way that is easy for users to understand.
6.1.2 Own safety requirements
6.1.2.1 Identification and identification
6.1.2.1.1 User ID
6.1.2.1.1.1 Security attribute definition
The product should specify the security attributes related to each user, such as user identification, membership group, authority, etc.
6.1.2.1.1.2 Property initialization
The product should be able to initialize the attributes of each user created with default values.
6.1.2.1.1.3 Unique identification
The product should provide a unique identifier for the user, and at the same time associate the user's identity with all auditable events of the user.
6.1.2.1.2 Identity authentication
6.1.2.1.2.1 User authentication
The product should authenticate the user's identity before performing any security function operations.
6.1.2.1.2.2 Authentication information protection
The product shall take technical measures to ensure that user authentication information is not read or modified without authorization.
6.1.2.2 Security Management
6.1.2.2.1 Management capabilities
The product should allow authorized users to manage the following.
a) View security attributes;
b) Modify security attributes;
c) Turn on or turn off all or part of the safety functions;
d) Formulate and modify various security strategies.
6.1.2.2.2 Security role management
The product should have at least two user roles with different permissions, such as operator, auditor, etc.
6.1.2.2.3 Remote secure transmission
If product components communicate through the network, measures should be taken to ensure the security of the transmitted data.
6.1.2.3 Audit log
6.1.2.3.1 Audit log generation
The product should generate an audit log of the following events.
a) The user's login success and failure;
b) The operation of configuring the security policy;
c) Add, delete, and modify security roles.
The product shall record the date, time, user identification, event description and result of the event in each audit log record. If adopted
The remote login method should also record the IP address of the management host.
6.1.2.3.2 Audit log preservation
The audit log should be stored in a non-volatile storage medium after power failure.
6.1.2.3.3 Audit log management
The product should provide the following audit log management functions.
a) Only authorized users are allowed to access audit logs;
b) Query and retrieval functions based on conditions such as operating users, date and time, and operation types;
c) Authorized users should be able to archive and export audit logs.
6.1.3 Safety assurance requirements
6.1.3.1 Development
6.1.3.1.1 Security Architecture
The developer should provide a description of the security architecture of the product's security functions, and the description of the security architecture should meet the following requirements.
a) Consistent with the description scope of the safety function in the product design document;
b) Fully describe the self-protection and non-bypassable safety mechanism adopted by the product.
6.1.3.1.2 Functional specification
The developer shall provide a complete functional specification, which shall meet the following requirements.
a) Fully describe the functions defined in 6.1.1 and 6.1.2;
b) Identify and describe the purpose, usage and related parameters of all safety function interfaces of the product;
c) Describe the safety function implementation behavior related to the safety function interface;
d) Describe the direct error messages caused by the behavioral processing of the security function.
6.1.3.1.3 Product design
Developers should provide product design documents, and product design documents should meet the following requirements.
a) Describe the product structure through the subsystem, identify and describe all the subsystems of the product safety function, and describe the interaction between the subsystems;
b) Provide the correspondence between the subsystem and the safety function interface.
6.1.3.2 Guiding documents
6.1.3.2.1 Operation User Guide
The developer should provide a clear and reasonable operation user guide, and the description of each user role should meet the following requirements.
a) Describe the functions and privileges that the user can access, including appropriate warning information;
b) Describe the user operation methods of product safety functions and interfaces, including the safety values of configuration parameters, etc.;
c) Identify and describe all possible states of product operation, including failures or operational errors caused by operations;
d) Describe the security policies that must be implemented to achieve product security goals.
6.1.3.2.2 Preparation procedures
The developer should provide the product and its preparation procedure, and the preparation procedure description should meet the following requirements.
a) Describe all the steps necessary to safely receive the delivered product consistent with the developer's delivery procedure;
b) Describe all the steps necessary to safely install the product and its operating environment.
6.1.3.3 Life cycle support
6.1.3.3.1 Configuration management capabilities
The developer's configuration management capabilities should meet the following requirements.
a) Provide unique identification for different versions of the product;
b) Use the configuration management system to maintain all the configuration items that make up the product and uniquely identify it;
c) Provide configuration management documents, which describe the methods used to uniquely identify configuration items.
6.1.3.3.2 Configuration management scope
The developer should provide a list of product configuration items and indicate the developer of the configuration items. The list of configuration items includes at least product and security requirements
The evaluation evidence and product components.
6.1.3.3.3 Delivery procedures
Developers should use prescribed delivery procedures to deliver products and document the delivery process. When delivering each version of the product to the user,
The paid documentation should describe all procedures necessary to maintain safety.
6.1.3.4 Test
6.1.3.4.1 Test coverage
The developer should provide a test coverage document, and the test coverage description should indicate the test items identified in the test document and the function specifications.
Describe the compatibility of product safety features.
6.1.3.4.2 Function test
Developers should test product safety features and provide test documentation. The test document should include the following.
a) Test plan, which identifies the tests to be executed and describes the plan for executing each test;
b) The expected test results, indicating the expected output after the test is successful;
c) Comparison of actual evaluation results and expected evaluation results.
6.1.3.4.3 Independent testing
Developers should provide a set of resources equivalent to those used in self-testing safety functions for sampling tests of safety functions.
6.1.3.5 Vulnerability assessment
Based on the identified potential vulnerabilities, the product can resist basic attacks.
6.2 Enhanced safety technical requirements
6.2.1 Safety function requirements
6.2.1.1 Detection capability
6.2.1.1.1 Resource Discovery
Products should be able to find various URLs in web applications, and the proportion of URLs found should be higher than 90%. URL discovery includes but is not limited to.
a) URL obtained by parsing and executing scripts such as JavaScript;
b) URL included in the page file;
c) URL embedded in Flash and Flex.
6.2.1.1.2 Web application vulnerability detection
The product should be able to detect web application vulnerabilities, and the false negative rate and false positive rate of the same type of vulnerabilities should be less than 20%. Types of vulnerabilities include but are not limited to.
a) SQL injection vulnerabilities, including injection vulnerabilities submitted based on Get and Post methods that should include characters, numbers, and searches;
b) Cookie injection vulnerabilities, including injection vulnerabilities submitted based on cookies that should include characters, numbers, and searches;
c) XSS vulnerabilities, including cross-site attack vulnerabilities based on Get, Post, Referrer and Cookie methods;
d) CSRF vulnerability;
e) Directory traversal vulnerability;
f) Information disclosure vulnerabilities, including path disclosure, backup files, source code disclosure, directory browsing and phpinfo and other information disclosure vulnerabilities;
g) Weak authentication methods, such as various login bypasses, weak passwords, etc.;
h) Files contain vulnerabilities, including remote and local files contain vulnerabilities;
i) Command execution vulnerability;
j) Vulnerabilities in third-party components, such as Struts2, FCKeditor editor, etc.;
k) LDAP injection vulnerability;
l) XPath injection vulnerability.
6.2.1.1.3 Deformation detection
The product should support deformation detection of Web application vulnerabilities, such as random conversion of upper and lower case, multiple bypassing of space restrictions, space replacement and URL encoding mechanisms.
6.2.1.1.4 Content detection
The product should be able to detect the following content of the target web application.
a) Does not belong to the external chain of the target system;
b) Bad links in the target system;
c) The dark link in the target system;
d) Sensitive keywords.
6.2.1.1.5 Upgrade
The product should have the following upgrades.
a) Update of vulnerability signature database;
b) At least one security mechanism shall be adopted to ensure the timeliness of the upgrade, such as automatic upgrade, update notification and other means.
6.2.1.1.6 Support HTTPS
The product should be able to detect web applications based on the HTTPS protocol.
6.2.1.1.7 Does not affect the target object
The product should avoid affecting the normal operation of the target Web application during the detection process.
6.2.1.2 Inspection task management
6.2.1.2.1 Wizard function
The product should provide a wizard function to guide users to the correct configuration.
6.2.1.2.2 Detection range
The product should be able to configure the detection range according to the following conditions.
a) Specify the domain name and URL;
b) the depth of inspection;
c) URLs that are not checked, such as logout, delete and other related pages;
d) Route mode reloading;
e) The path mode is case sensitive.
6.2.1.2.3 Login detection
The product should be able to detect web applications based on login information. Such as based on recording information, Cookie, Session, Token, etc.
Or multiple ways to authorize login and perform detection.
6.2.1.2.4 Detection strategy
6.2.1.2.4.1 Strategy selection
The product should be able to select the detection strategy in the following ways.
a) Type of vulnerability;
b) The vulnerability hazard level;
c) Web system fingerprint information.
6.2.1.2.4.2 Strategy Extension
Products should be able to customize detection strategies and expand existing strategies.
6.2.1.2.5 Detection speed adjustment
The product should be able to adjust the detection speed according to the following methods.
a) Configure the HTTP request speed, the number of detection threads or processes, etc.;
b) Distributed deployment detection engine;
c) Multi-engine load balancing.
6.2.1.2.6 Task customization
The product should be able to realize batch, timing, specified time period and periodic start detection according to the planned tasks, and automatically generate corresponding results according to the settings.
6.2.1.2.7 Progress control
The product should be able to control the progress of the test as follows.
a) Stop at any time;
b) Resume scanning at breakpoints;
c) If the test is not over, the tested part can be displayed and a report can be exported.
6.2.1.3 Analysis and processing of test results
6.2.1.3.1 Result verification
The product should have the function of web application vulnerability verification, including.
a) Provide parameters to further verify vulnerabilities such as XSS vulnerabilities, SQL injection points, directory traversal, information disclosure and command execution;
b) Provide automated tools to verify vulnerabilities.
6.2.1.3.2 Results save
The test results should be stored in non-clear text in a non-volatile storage medium after power failure.
6.2.1.3.3 Statistical analysis
The product should be able to perform statistical analysis on the number of vulnerabilities, vulnerability types and hazard levels based on the detection results.
6.2.1.3.4 Report generation
The product should be able to analyze the test results and form a report, the report should include.
a) Vulnerability information such as vulnerability location, vulnerability name, vulnerability description and hazard level;
b) Vulnerability repair suggestions;
c) Support exporting industry compliance reports;
d) Edit and customize design reports, support adding custom notes or detailed information;
e) Support batch export of reports;
f) Support trend analysis report based on horizontal and vertical comparison.
6.2.1.3.5 Report output
The product test report should be output according to the following requirements.
a) Common document formats, such as DOC, PDF and HTML;
b) Display in a way that is easy for users to understand.
6.2.1.4 Interactivity requirements
The product should provide or adopt a standard, open interface. Comply with this interface specification, you can write corresponding
The program module achieves the purpose of interacting with the product.
6.2.2 Own safety requirements
6.2.2.1 Identification and identification
6.2.2.1.1 User ID
6.2.2.1.1.1 Security attribut...
Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of GB/T 37931-2019_English be delivered?Answer: Upon your order, we will start to translate GB/T 37931-2019_English as soon as possible, and keep you informed of the progress. The lead time is typically 4 ~ 7 working days. The lengthier the document the longer the lead time. Question 2: Can I share the purchased PDF of GB/T 37931-2019_English with my colleagues?Answer: Yes. The purchased PDF of GB/T 37931-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.
|