Automatic penetration testing method and device, computer equipment and storage medium

By formulating personalized penetration testing strategies for the common assets and properties of enterprise application service systems, the problem of lack of targeted existing penetration testing methods is solved, and more accurate and efficient security assessment is achieved.

CN119544375APending Publication Date: 2025-02-28PARK DO CREDIT CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411868910.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-18
Publication Date
2025-02-28

AI Technical Summary

Technical Problem

The existing penetration testing methods lack targeting when evaluating the security status of enterprise application service systems, which may lead to missed tests or false alarms, increasing the security risks of enterprises.

Method used

By obtaining several service systems for application services, determining their common assets and asset properties, and formulating targeted penetration testing strategies based on this information, including using vulnerability library-based testing for open source assets, conducting white and black box testing for non-open source assets, and finally comprehensively analyzing the test results of each service system.

Benefits of technology

It improves the pertinence and accuracy of penetration testing, can more accurately detect security vulnerabilities in the application service system, reduce false alarms and missed tests, and improves the security of the system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119544375A_ABST
    Figure CN119544375A_ABST
Patent Text Reader

Abstract

The invention relates to the field of network security, in particular to an automatic penetration testing method and device, computer equipment and a storage medium, and the method comprises the steps: obtaining a plurality of service systems of application services, and determining common assets of the service systems and asset properties of the common assets; determining a penetration test strategy of each common asset based on the asset property of each common asset; performing penetration testing on the common assets based on the penetration testing strategies of the common assets to obtain testing results of the common assets; and determining a penetration test result of each service system based on the test result of each common asset of each service system. By adopting the scheme, the real safety condition of the application service system is accurately evaluated, and the pertinence and accuracy of penetration testing are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of network security, and in particular to an automated penetration testing method, device, computer equipment and storage medium. Background Art

[0002] With the rapid development of digitalization and networking, the number of enterprise network systems is increasing, and the complexity is constantly improving. Although traditional network security protection methods, such as firewalls and intrusion detection systems, can protect the security of network systems to a certain extent, they are often unable to cope with the increasingly complex and changeable network attack methods. As a proactive security assessment method, penetration testing can discover loopholes and weaknesses in network systems by simulating hacker attack methods, providing strong support for enterprise security protection.

[0003] In the prior art, when conducting penetration tests on enterprise application service systems, a unified testing method is usually used to conduct penetration tests on various subsystems in the application service system. However, it is found in research that since the subsystems of enterprise application service systems often have different functions and many differences in technical architecture, these subsystems have significant differences in security requirements, vulnerability types, and potential threats. If a unified testing method is simply adopted, not only may it be impossible to accurately assess the true security status of each subsystem, but it may also lead to missed tests or false positives due to mismatched testing strategies, thereby bringing potential security risks to the enterprise. Summary of the invention

[0004] In view of this, the purpose of the present invention is to provide an automated penetration testing method, apparatus, computer equipment and storage medium to accurately evaluate the actual security status of the application service system and improve the pertinence and accuracy of the penetration test.

[0005] In a first aspect, an embodiment of the present application provides an automated penetration testing method, the method comprising:

[0006] Obtain several service systems of the application service, determine the common assets of each service system and the asset nature of each common asset;

[0007] Determine the penetration testing strategy for each commonly used asset based on the asset properties of each commonly used asset;

[0008] Based on the penetration test strategy of each commonly used asset, penetration test is performed on each commonly used asset to obtain the test results of each commonly used asset;

[0009] The penetration test results of each service system are determined based on the test results of each common asset of each service system.

[0010] Optionally, the commonly used assets include commonly used ports and commonly used components, and the nature of the assets is open source or non-open source.

[0011] Optionally, the determining of the commonly used assets of each service system and the asset properties of each commonly used asset includes:

[0012] Perform port scanning on each service system to obtain the commonly used ports of each service system and the asset properties of each commonly used port;

[0013] The common components of each service system and the asset properties of each common component are queried from the common component library.

[0014] Optionally, determining the penetration testing strategy for each commonly used asset based on the asset property of each commonly used asset includes:

[0015] For open source assets, the penetration testing strategy is to conduct penetration testing based on vulnerability libraries.

[0016] For non-open source assets whose nature is non-open source, their penetration testing strategies are determined as white box testing and black box testing.

[0017] Optionally, performing a penetration test on each commonly used asset based on the penetration test strategy of each commonly used asset to obtain a test result of each commonly used asset includes:

[0018] For open source assets, obtain their common vulnerabilities, and build vulnerability libraries for each service system based on their common vulnerabilities; perform penetration testing on the open source assets of each service system based on the vulnerability libraries of each service system to obtain the first test sub-result;

[0019] For non-open source assets, white box testing and black box testing are performed on them to obtain the second test sub-result.

[0020] Optionally, determining the penetration test results of each service system based on the test results of each common asset of each service system includes:

[0021] For each service system, a test result record table of the service system is created, wherein the test result record table records each commonly used asset of the service system;

[0022] The test results of each commonly used asset of the service system are recorded in its test result record table to obtain the penetration test results of the service system.

[0023] Optionally, before obtaining the plurality of service systems of the application service, the method further includes:

[0024] Obtain the application system where the application service is located;

[0025] The application system is classified into scenarios to obtain several service systems, wherein the service system includes a big data system, an operation and maintenance management system, and an operation and maintenance development system.

[0026] In a second aspect, an embodiment of the present application provides an automated penetration testing device, the device comprising:

[0027] A commonly used asset determination module is used to obtain several service systems of application services, determine the commonly used assets of each service system and the asset properties of each commonly used asset;

[0028] A test strategy determination module, used to determine the penetration test strategy of each commonly used asset based on the asset properties of each commonly used asset;

[0029] A test result determination module, used to perform penetration testing on each common asset based on the penetration testing strategy of each common asset to obtain the test results of each common asset;

[0030] The penetration test result determination module is used to determine the penetration test results of each service system based on the test results of each common asset of each service system.

[0031] Optionally, the commonly used assets include commonly used ports and commonly used components, and the nature of the assets is open source or non-open source.

[0032] Optionally, the determining of the commonly used assets of each service system and the asset properties of each commonly used asset includes:

[0033] Perform port scanning on each service system to obtain the commonly used ports of each service system and the asset properties of each commonly used port;

[0034] The common components of each service system and the asset properties of each common component are queried from the common component library.

[0035] Optionally, determining the penetration testing strategy for each commonly used asset based on the asset property of each commonly used asset includes:

[0036] For open source assets, the penetration testing strategy is to conduct penetration testing based on vulnerability libraries.

[0037] For non-open source assets whose nature is non-open source, their penetration testing strategies are determined as white box testing and black box testing.

[0038] Optionally, performing a penetration test on each commonly used asset based on the penetration test strategy of each commonly used asset to obtain a test result of each commonly used asset includes:

[0039] For open source assets, obtain their common vulnerabilities, and build vulnerability libraries for each service system based on their common vulnerabilities; perform penetration testing on the open source assets of each service system based on the vulnerability libraries of each service system to obtain the first test sub-result;

[0040] For non-open source assets, white box testing and black box testing are performed on them to obtain the second test sub-result.

[0041] Optionally, determining the penetration test results of each service system based on the test results of each common asset of each service system includes:

[0042] For each service system, a test result record table of the service system is created, wherein the test result record table records each commonly used asset of the service system;

[0043] The test results of each commonly used asset of the service system are recorded in its test result record table to obtain the penetration test results of the service system.

[0044] Optionally, the device further comprises:

[0045] An application system acquisition module, used to acquire the application system where the application service is located before acquiring several service systems of the application service;

[0046] The service system determination module is used to classify the application system into scenarios to obtain several service systems, wherein the service system includes a big data system, an operation and maintenance management system, and an operation and maintenance development system.

[0047] In a third aspect, an embodiment of the present application provides a computer device, comprising: a processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the computer device is running, the processor communicates with the memory through the bus, and when the machine-readable instructions are executed by the processor, the steps of the automated penetration testing method described in any optional implementation manner of the first aspect are performed.

[0048] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, executes the steps of the automated penetration testing method described in any optional implementation manner of the first aspect above.

[0049] The technical solution provided by this application includes but is not limited to the following beneficial effects:

[0050] This application first obtains several service systems of application services, determines the common assets of each service system and the asset properties of each common asset, and by combing the various service systems and their common assets in the application service system in detail, it can clearly define the scope and objectives of the penetration test, ensuring the pertinence and effectiveness of the test. Then, based on the asset properties of each common asset, the penetration test strategy of each common asset is determined. By formulating targeted penetration test strategies for different types of assets, it is possible to more accurately simulate attack scenarios, discover potential security vulnerabilities, reasonably allocate test resources, ensure that key assets are fully tested, and avoid wasting resources on unimportant assets. Then, based on the penetration test strategy of each common asset, each common asset is subjected to penetration testing to obtain the test results of each common asset. By actually performing the penetration test, the security vulnerabilities in each common asset can be discovered and recorded, providing a basis for subsequent security repairs. Finally, based on the test results of each common asset of each service system, the penetration test results of each service system are determined. By comprehensively analyzing the test results of all common assets in each service system, the overall security status of each service system can be obtained, providing decision support for the management.

[0051] The above solution can not only accurately evaluate the real security status of the application service system, timely discover and repair security vulnerabilities, and improve the security of the system, but also optimize the allocation of test resources and improve the pertinence and accuracy of penetration testing.

[0052] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0054] Figure 1 A flow chart of an automated penetration testing method provided by Embodiment 1 of the present invention is shown;

[0055] Figure 2 A flow chart of a method for determining a penetration test result provided by the first embodiment of the present invention is shown;

[0056] Figure 3 A flow chart of a service system determination method provided by Embodiment 1 of the present invention is shown;

[0057] Figure 4A schematic diagram of the structure of an automated penetration testing device provided by Embodiment 2 of the present invention is shown;

[0058] Figure 5 A schematic diagram of the structure of a second automated penetration testing device provided in the second embodiment of the present invention is shown;

[0059] Figure 6 A schematic diagram of the structure of a computer device provided in Embodiment 3 of the present invention is shown. DETAILED DESCRIPTION

[0060] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present invention.

[0061] Embodiment 1

[0062] To facilitate understanding of this application, Figure 1 The flowchart of an automated penetration testing method provided in the first embodiment of the present invention is shown to describe the contents of the first embodiment of the present application in detail.

[0063] See also Figure 1 As shown, Figure 1 The flowchart of an automated penetration testing method provided in the first embodiment of the present invention is shown, wherein the method comprises steps S101 to S104:

[0064] S101: Acquire several service systems of application services, determine common assets of each service system and the asset properties of each common asset.

[0065] Specifically, identify and classify all service systems involved in application services and common assets in these systems. Common assets include but are not limited to databases, servers, application programming interfaces (APIs), network devices, user accounts, etc. At the same time, it is necessary to determine the nature of these assets, such as whether they store sensitive data, whether they provide external services, whether they interact with other systems, etc. This step provides basic data for subsequent security assessments.

[0066] S102: Determine a penetration testing strategy for each commonly used asset based on the asset properties of each commonly used asset.

[0067] Specifically, develop a suitable penetration testing strategy for each asset, including determining the scope, methods, tools, and expected goals of the test. For example, for databases that store sensitive data, adopt a more stringent testing strategy, including trying various attack methods to verify its security. For user accounts, it is necessary to test the effectiveness of the password policy.

[0068] S103: Performing penetration testing on each commonly used asset based on the penetration testing strategy of each commonly used asset to obtain a test result of each commonly used asset.

[0069] Specifically, according to the previously formulated strategy, use the corresponding tools and methods to test each asset. During the test, record all discovered security vulnerabilities, weaknesses, and potential attack paths. The test results will directly reflect the security status of each commonly used asset.

[0070] S104: Determine the penetration test results of each service system based on the test results of each common asset of each service system.

[0071] Specifically, the test results of each commonly used asset are summarized and analyzed to derive the security status of the entire service system, including identifying which service systems have serious security issues, which assets are most vulnerable to attacks, and which security measures are effective or need improvement. This information is crucial for formulating subsequent security reinforcement plans and improving the overall security level.

[0072] Through steps S101 to S104, the application system of the application service is subjected to penetration testing. By identifying, classifying, testing and evaluating common assets in the service system, potential security risks can be discovered and corresponding measures can be taken to reduce these risks.

[0073] In an optional implementation manner, the commonly used assets include commonly used ports and commonly used components, and the nature of the assets is open source or non-open source.

[0074] Specifically, common ports include but are not limited to standard service ports such as HTTP, HTTPS, FTP, SSH, and also include custom ports required by specific applications. Common components include but are not limited to database management systems, web servers, application frameworks, middleware, etc. At the same time, it is necessary to determine whether these ports and components are open source or non-open source, because open source components are usually more susceptible to known vulnerabilities, while non-open source components may contain unknown or unique security issues.

[0075] In an optional implementation scheme, the determining of the commonly used assets of each service system and the asset properties of each commonly used asset includes:

[0076] Perform port scans on each service system to obtain the commonly used ports of each service system and the asset properties of each commonly used port.

[0077] Specifically, select appropriate port scanning tools, such as Nmap, Masscan, Metasploit, etc., and use the selected tools to perform a comprehensive port scan on the service system. The scanning range includes all commonly used ports (such as 1-1024) or scans a specific port range based on specific needs. Record the scan results, including the open port number, the corresponding service, and the service version, and determine the asset nature of each open port based on the scan results, including whether there are known vulnerabilities, whether the service configuration is secure, whether it is an open source service port, etc. Classify the ports according to the nature of the assets, such as high-risk ports, medium-risk ports, low-risk ports, etc., or open source service ports or non-open source service ports, etc.

[0078] The common components of each service system and the asset properties of each common component are queried from the common component library.

[0079] Specifically, select the component library related to the service system for query, search the component library for common components used in the service system, and record the name, version, and related description information of each component. Evaluate the security of each component based on the component description information and known security vulnerability databases (such as CVE, OWASP, etc.). Determine the asset nature of the component, including whether it is open source, whether there are known vulnerabilities, whether it is outdated, etc. Classify the components according to the asset nature, such as key components, important components, non-key components, etc.

[0080] In an optional implementation scheme, determining the penetration testing strategy for each commonly used asset based on the asset property of each commonly used asset includes:

[0081] For open source assets whose nature is open source, the penetration testing strategy is determined to be penetration testing based on the vulnerability library.

[0082] Specifically, for open source assets, since their source code is public, they are more susceptible to known vulnerabilities. For such assets, a penetration testing strategy based on vulnerability libraries is usually adopted. That is, existing vulnerability databases such as CVE (Common Vulnerabilities and Exposures) or Exploit-DB are used to find known vulnerabilities related to these assets. Then, automated tools such as Metasploit or Nessus are used to scan the target assets and check whether these known vulnerabilities exist. If a vulnerability is found, manual verification will be performed immediately to ensure its authenticity and assess its potential impact. Finally, corresponding repair suggestions will be made based on the evaluation results to ensure the security of these assets.

[0083] For non-open source assets whose nature is non-open source, their penetration testing strategies are determined as white box testing and black box testing.

[0084] Specifically, for non-open source assets, since their source code is not public, it is impossible to directly use known vulnerability libraries for testing. Therefore, a more comprehensive testing method is needed, including white box testing and black box testing. White box testing requires an in-depth understanding of the target asset, including its source code, architecture, and configuration. By reviewing the source code and conducting code audits, potential logical errors and security vulnerabilities can be discovered. At the same time, path analysis is also required to determine potential attack paths. Black box testing is conducted from the perspective of an attacker, who does not know the internal details of the target asset and can only discover vulnerabilities by observing its external behavior and response. This includes sending various inputs to the target asset and analyzing its output to discover potential weaknesses. In addition, you can also try to use brute force cracking and social engineering to test the security of the authentication system.

[0085] In an optional implementation scheme, the penetration test strategy based on each commonly used asset is used to perform a penetration test on each commonly used asset to obtain a test result of each commonly used asset, including:

[0086] For open source assets, common vulnerabilities are obtained, and vulnerability libraries of various service systems are constructed based on the common vulnerabilities; based on the vulnerability libraries of various service systems, penetration tests are performed on the open source assets of various service systems to obtain the first test sub-result.

[0087] Specifically, for open source assets, we usually rely on continuous attention to the open source community, review of security announcements, and use of vulnerability databases (such as CVE, OWASP Top Ten, etc.) to identify and collect common security vulnerabilities. After collecting enough common vulnerabilities of open source assets, we build a vulnerability library for each service system. This database not only contains detailed information about the vulnerabilities, but also associates the service systems and assets that may be affected, thus providing strong support for subsequent penetration testing.

[0088] Using the built vulnerability library, we conducted targeted penetration tests on the open source assets in each service system. In this process, we used known vulnerabilities to attack these assets to assess their true security. After testing, we were able to obtain the first test sub-results on the security of open source assets. These results detailed information such as the vulnerabilities of each asset, the severity of the vulnerabilities, and possible attack paths.

[0089] For non-open source assets, white box testing and black box testing are performed on them to obtain the second test sub-result.

[0090] Specifically, for non-open source assets, white box testing was first performed to deeply analyze the internal information of the asset, such as the source code, architecture, and configuration, to discover potential logical errors and security vulnerabilities. After completing the white box test, black box testing was performed to simulate the attacker's perspective and discover its potential security issues only by observing the external behavior and response of the asset. Combining the results of white box testing and black box testing, the second test sub-results on the security of non-open source assets were obtained. These results also record in detail the security issues that exist for each asset, the nature of the problem, and possible repair suggestions.

[0091] In an alternative embodiment, see Figure 2 As shown, Figure 2 A flowchart of a method for determining a penetration test result provided by the first embodiment of the present invention is shown, wherein the method for determining the penetration test result of each service system based on the test result of each common asset of each service system includes steps S201 to S202:

[0092] S201: For each service system, create a test result record table of the service system, wherein the test result record table records various commonly used assets of the service system.

[0093] Specifically, in order to clearly track and record the penetration test results of each service system, a dedicated test result record sheet is first created for each service system. In this record sheet, all common assets of the service system are listed. These assets may be hardware devices, software applications, databases, or any other important IT resources. A unique identifier is assigned to each asset so that they can be easily referenced and tracked in subsequent steps.

[0094] S202: Record the test results of the common assets of the service system in its test result record table to obtain the penetration test results of the service system.

[0095] Specifically, after completing the penetration test of each service system's commonly used assets, accurately record the test results in the previously created test result record sheet. For each commonly used asset, fill in the corresponding information in the record sheet based on the results of its penetration test, including the vulnerabilities found, the severity of the vulnerabilities, the potential impact, and the recommended repair measures.

[0096] In an alternative embodiment, see Figure 3 As shown, Figure 3 A flow chart of a service system determination method provided by the first embodiment of the present invention is shown, wherein before obtaining several service systems of application services, the method further includes steps S301 to S302:

[0097] S301: Acquire the application system where the application service is located.

[0098] Specifically, in order to identify and obtain the application systems to which the application services that need to be penetrated are affiliated, first communicate with the business team or IT department to obtain the currently running application systems and the functions and services provided by these systems. By collecting relevant system documents, architecture diagrams, user manuals and other materials, further understand the specific details of the application systems, including their components, data flows, user interaction methods, etc. On this basis, determine which application systems need to be penetrated and obtain the corresponding access rights to facilitate subsequent testing.

[0099] S302: Classify the application systems by scenarios to obtain a number of service systems, wherein the service systems include a big data system, an operation and maintenance management system, and an operation and maintenance development system.

[0100] Specifically, after obtaining the application system, the scenario classification is carried out to divide the complex application system into several relatively independent and easy-to-manage service systems. According to the function, business process, data flow and other factors of the application system, it is divided into different service systems. These service systems include but are not limited to the entire system that provides basic application services, big data systems, operation and maintenance management systems, operation and maintenance development systems, etc.

[0101] Each service system has its own specific business scenarios and data processing processes, so it is necessary to conduct a detailed analysis and understanding of each service system in order to carry out targeted penetration testing in the future. In addition, in the classification process, it is also necessary to consider the interactions and dependencies between service systems to ensure that all security risk points can be fully covered during penetration testing.

[0102] Embodiment 2

[0103] Embodiment 2 of the present invention provides an automated penetration testing device, see Figure 4 As shown, Figure 4 The following is a schematic diagram of the structure of an automated penetration testing device provided by Embodiment 2 of the present invention, wherein the device comprises:

[0104] The commonly used asset determination module 401 is used to obtain a number of service systems of the application service, determine the commonly used assets of each service system and the asset properties of each commonly used asset;

[0105] A test strategy determination module 402, used to determine a penetration test strategy for each commonly used asset based on the asset properties of each commonly used asset;

[0106] A test result determination module 403 is used to perform a penetration test on each common asset based on the penetration test strategy of each common asset to obtain a test result of each common asset;

[0107] The penetration test result determination module 404 is used to determine the penetration test result of each service system based on the test results of each common asset of each service system.

[0108] In an optional implementation manner, the commonly used assets include commonly used ports and commonly used components, and the nature of the assets is open source or non-open source.

[0109] In an optional implementation scheme, the determining of the commonly used assets of each service system and the asset properties of each commonly used asset includes:

[0110] Perform port scanning on each service system to obtain the commonly used ports of each service system and the asset properties of each commonly used port;

[0111] The common components of each service system and the asset properties of each common component are queried from the common component library.

[0112] In an optional implementation scheme, determining the penetration testing strategy for each commonly used asset based on the asset property of each commonly used asset includes:

[0113] For open source assets, the penetration testing strategy is to conduct penetration testing based on vulnerability libraries.

[0114] For non-open source assets whose nature is non-open source, their penetration testing strategies are determined as white box testing and black box testing.

[0115] In an optional implementation scheme, the penetration test strategy based on each commonly used asset is used to perform a penetration test on each commonly used asset to obtain a test result of each commonly used asset, including:

[0116] For open source assets, obtain their common vulnerabilities, and build vulnerability libraries for each service system based on their common vulnerabilities; perform penetration testing on the open source assets of each service system based on the vulnerability libraries of each service system to obtain the first test sub-result;

[0117] For non-open source assets, white box testing and black box testing are performed on them to obtain the second test sub-result.

[0118] In an optional implementation scheme, the step of determining the penetration test results of each service system based on the test results of each common asset of each service system includes:

[0119] For each service system, a test result record table of the service system is created, wherein the test result record table records each commonly used asset of the service system;

[0120] The test results of each commonly used asset of the service system are recorded in its test result record table to obtain the penetration test results of the service system.

[0121] In an alternative embodiment, see Figure 5 As shown, Figure 5 A schematic diagram of the structure of a second automated penetration testing device provided by the second embodiment of the present invention is shown, and the device further includes:

[0122] The application system acquisition module 501 is used to acquire the application system where the application service is located before acquiring several service systems of the application service;

[0123] The service system determination module 502 is used to classify the application system by scenarios to obtain several service systems, wherein the service system includes a big data system, an operation and maintenance management system, and an operation and maintenance development system.

[0124] Embodiment 3

[0125] Based on the same application concept, see Figure 6 As shown, Figure 6 FIG. 4 shows a schematic diagram of the structure of a computer device provided by Embodiment 3 of the present invention, wherein: Figure 6 As shown, a computer device 600 provided in Embodiment 3 of the present application includes:

[0126] A processor 601, a memory 602 and a bus 603, wherein the memory 602 stores machine-readable instructions executable by the processor 601. When the computer device 600 is running, the processor 601 communicates with the memory 602 via the bus 603. When the processor 601 is running, the machine-readable instructions execute the steps of the automated penetration testing method shown in the first embodiment.

[0127] Embodiment 4

[0128] Based on the same application concept, an embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the automated penetration testing method described in any one of the above embodiments are executed.

[0129] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system and device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0130] The computer program product for performing automated penetration testing provided in an embodiment of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the previous method embodiments. The specific implementation can be found in the method embodiments, which will not be repeated here.

[0131] The automated penetration testing device provided in the embodiment of the present invention can be specific hardware on the device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in the embodiment of the present invention are the same as those of the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference can be made to the corresponding contents in the aforementioned method embodiment. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, devices and units described above can all refer to the corresponding processes in the aforementioned method embodiment, and will not be repeated here.

[0132] In the embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

[0133] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0134] In addition, each functional unit in the embodiment provided by the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0135] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., which can store program codes.

[0136] It should be noted that similar numbers and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are only used to distinguish the description and are not to be understood as indicating or implying relative importance.

[0137] Finally, it should be noted that the above-described embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can still modify the technical solutions described in the above-described embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or perform equivalent replacements on some of the technical features thereof; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. They should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. An automated penetration testing method, characterized in that: The method comprises: Obtain several service systems of the application service, determine the common assets of each service system and the asset nature of each common asset; Determine the penetration testing strategy for each commonly used asset based on the asset properties of each commonly used asset; Based on the penetration test strategy of each commonly used asset, penetration test is performed on each commonly used asset to obtain the test results of each commonly used asset; The penetration test results of each service system are determined based on the test results of each common asset of each service system.

2. The method according to claim 1, characterized in that The commonly used assets include commonly used ports and commonly used components, and the nature of the assets is open source or non-open source.

3. The method according to claim 2, characterized in that The determining of the commonly used assets of each service system and the asset nature of each commonly used asset includes: Perform port scanning on each service system to obtain the commonly used ports of each service system and the asset properties of each commonly used port; The common components of each service system and the asset properties of each common component are queried from the common component library.

4. The method according to claim 2, characterized in that: The penetration testing strategy for each commonly used asset is determined based on the asset properties of each commonly used asset, including: For open source assets, the penetration testing strategy is to conduct penetration testing based on vulnerability libraries. For non-open source assets whose nature is non-open source, their penetration testing strategies are determined as white box testing and black box testing.

5. The method according to claim 2, characterized in that: The penetration test strategy based on each commonly used asset performs a penetration test on each commonly used asset to obtain the test results of each commonly used asset, including: For open source assets, obtain their common vulnerabilities, and build vulnerability libraries for each service system based on their common vulnerabilities; perform penetration testing on the open source assets of each service system based on the vulnerability libraries of each service system to obtain the first test sub-result; For non-open source assets, white box testing and black box testing are performed on them to obtain the second test sub-result.

6. The method according to claim 1, characterized in that The penetration test results of each service system are determined based on the test results of each common asset of each service system, including: For each service system, a test result record table of the service system is created, wherein the test result record table records each commonly used asset of the service system; The test results of each commonly used asset of the service system are recorded in its test result record table to obtain the penetration test results of the service system.

7. The method according to claim 1, characterized in that Before obtaining the plurality of service systems of the application service, the method further comprises: Obtain the application system where the application service is located; The application system is classified by scenarios to obtain several service systems, wherein the service system includes a big data system, an operation and maintenance management system, and an operation and maintenance development system.

8. An automated penetration testing device, characterized in that: The device comprises: A commonly used asset determination module is used to obtain several service systems of application services, determine the commonly used assets of each service system and the asset properties of each commonly used asset; A test strategy determination module, used to determine the penetration test strategy of each commonly used asset based on the asset properties of each commonly used asset; A test result determination module, used to perform penetration testing on each common asset based on the penetration testing strategy of each common asset to obtain the test results of each common asset; The penetration test result determination module is used to determine the penetration test results of each service system based on the test results of each common asset of each service system.

9. A computer device, characterized in that: include: A processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the computer device is running, the processor and the memory communicate via the bus, and when the machine-readable instructions are executed by the processor, the steps of the automated penetration testing method as described in any one of claims 1 to 7 are performed.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which, when executed by a processor, executes the steps of the automated penetration testing method as described in any one of claims 1 to 7.