Risk prevention method, electronic equipment, storage medium and product

Abstract

The invention discloses a risk prevention method, electronic equipment, a storage medium and a product, relates to the technical field of security prevention, is applied to a business integrated management system, and comprises the following steps: for any client system managed by the business integrated management system, determining an overall security score of the client system under each security index, detecting whether the performance of each key scene in the client system reaches the available base line of the system or not; judging whether the client system reaches a system security base line based on the overall security score; and under the condition that the client system does not reach the system safety bottom line and the system available bottom line, determining that the client system has potential risks, and carrying out switching-out processing on the client system. The technical problem of how to timely discover the potential risk of the system under the condition of ensuring that the system is safe and available is solved.

Description

Technical Field

[0001] The present application relates to the field of security prevention technology, and in particular to a risk prevention method, device, electronic device, storage medium and computer program product. Background Art

[0002] With the development of the Internet, the requirements for informatization within various enterprises are getting higher and higher, and higher requirements are put forward for the normal operation of enterprise systems. Various problems will arise in the daily use of enterprise systems. However, for software suppliers, once the enterprise system providing services generates an alarm or the enterprise customer feedbacks a problem, it is too late to solve the problem, which damages the image in the minds of customers. Therefore, for software suppliers, how to timely discover potential risks of the system while ensuring the security and availability of the system is a problem that needs to be solved. Summary of the invention

[0003] The main purpose of this application is to provide a risk prevention method, device, electronic device, storage medium and computer program product, aiming to solve the technical problem of how to timely discover potential risks of the system while ensuring the safety and availability of the system.

[0004] To achieve the above objectives, the present application proposes a risk prevention method, which is applied to a business integration management system. The risk prevention method includes: For any customer system managed by the business integrated management system, determine the overall security score of the customer system under each security indicator, and detect whether the performance of each key scenario in the customer system reaches the system availability bottom line; Determine whether the customer system has reached the system security bottom line based on the overall security score; In the case that the customer system does not reach the system security bottom line and the system availability bottom line, it is determined that the customer system has potential risks and the customer system is shut down.

[0005] In one embodiment, the step of determining the overall security score of the client system under each security indicator includes: For any one of the safety indicators, detecting a monitoring object corresponding to the safety indicator, and determining an indicator score of the safety indicator according to a characteristic state of the monitoring object; In the case where there is an exemption requirement for the safety indicator, modify the indicator score according to the exemption result corresponding to the exemption requirement; The corresponding indicator scores of the various security indicators are integrated to obtain the overall security score of the customer system.

[0006] In one embodiment, when there is an exemption requirement for the security indicator, before the step of modifying the indicator score according to the exemption requirement corresponding to the exemption result, the step further includes: Determine whether the safety indicators for which exemption requirements exist include the safety indicator according to the preset indicator exemption rule, wherein the preset indicator exemption rule is determined by the exemption document, and the exemption document includes the safety indicators for which exemption requirements exist; In a case where the security indicator is included in the security indicators for which exemption is required, input content of the security indicator is received, and an exemption result corresponding to the security indicator is determined according to the input content.

[0007] In one embodiment, the step of detecting whether the performance of each key scenario in the client system reaches the system availability bottom line includes: Identify key scenarios in the client system and core users using the client system; Determine, based on the user behavior data in the client system, the key scenarios and the core users, the user data when the core users access any page in the client system, and the scenario data when the key scenarios are accessed by any users; When any one of the user data satisfies the first preset rule and any one of the scenario data satisfies the second preset rule, it is determined that the performance of each key scenario in the client system reaches the system availability bottom line.

[0008] In one embodiment, the step of determining each key scenario in the client system and each core user using the client system includes: Detecting personalized scenarios whose page data in the client system meets the scenario recognition rules, and saving them in a preset scenario database, wherein the preset scenario database also includes standardized scenarios, which are imported by an administrator of the business integrated management system, and the standardized scenarios and personalized scenarios constitute key scenarios in the client system; Among the users using the client system, first users whose usage data satisfy the user identification rules are detected and saved in a preset user database. The preset user database also includes second users, and the second users are imported by the administrator of the business integration management system. The first users and the second users constitute the core users in the client system.

[0009] In one embodiment, the step of determining whether the client system has reached the system security bottom line based on the overall security score includes: In the overall security score, if the corresponding score of any security indicator satisfies the corresponding score threshold, and the overall security score satisfies the overall score threshold, it is determined that the customer system has reached the system security bottom line.

[0010] In one embodiment, the step of shutting down the client system includes: After receiving the system shutdown signal, determine the potential risk in the customer system according to the indicator scores under each security indicator; The operation of the client system is suspended, and the potential risk information and system shutdown information are output.

[0011] In addition, to achieve the above purpose, the present application also proposes a risk prevention device, which is applied to the business integrated management system, and the risk prevention device includes: A scoring module, for determining the overall security score of the customer system under each security indicator for any customer system managed by the business integrated management system, and detecting whether the performance of each key scenario in the customer system reaches the system availability bottom line; A judgment module, used to judge whether the client system reaches the system security bottom line based on the overall security score; The processing module is used to determine that the customer system has potential risks and shut down the customer system when the customer system does not reach the system security bottom line and the system availability bottom line.

[0012] In addition, to achieve the above-mentioned purpose, the present application also proposes an electronic device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the risk prevention method described above.

[0013] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the risk prevention method described above are implemented.

[0014] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the risk prevention method described above are implemented.

[0015] The present application provides a risk prevention method, which is applied to a business integration management system. The risk prevention method includes: for any customer system managed under the business integration management system, determining the overall security score of the customer system under each security indicator, and detecting whether the performance of each key scenario in the customer system reaches the system availability bottom line; judging whether the customer system reaches the system security bottom line based on the overall security score; and judging that there is a potential risk in the customer system and shutting down the customer system if the customer system does not reach the system security bottom line and the system availability bottom line.

[0016] This application calculates the overall security score of the customer system under various security indicators and detects the performance status of key scenarios. According to the overall security score and the performance status of the key scenarios of the system, it determines whether the customer system has reached the system security bottom line and the system availability bottom line, thereby evaluating the system security and determining whether the key scenarios in the system are available, thereby identifying customer systems with potential safety hazards or performance problems, and timely discovering and solving security problems before the incident through the power-off mechanism, ensuring the safety of the customer system without affecting the normal use of the customer. Compared with related solutions that often rely on manual inspections or post-analysis, there is a lag in risk handling and it is impossible to isolate risks in a timely manner. This application establishes the system security bottom line and the system availability bottom line through the overall security score and key scenario performance detection, and realizes rapid response and effective isolation of potential risks through the power-off processing mechanism when there are security risks in the system, avoiding further expansion and spread of risks, improving the overall security and stability of the system, and providing a strong guarantee for the stable operation of the enterprise system. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0018] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0019] Figure 1 A schematic diagram of a process flow provided for the first embodiment of the risk prevention method of the present application; Figure 2 A schematic diagram of the scenario of the exemption indicator input interface provided for the risk prevention method of this application; Figure 3 A flow chart of the second embodiment of the risk prevention method of the present application; Figure 4 This is a schematic diagram of the module structure of the risk prevention device according to an embodiment of the present application; Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the risk prevention method in the embodiment of the present application.

[0020] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0021] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0022] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0023] The embodiment of the present application is applied to a business integration management system, and the main solution is: for any customer system managed under the business integration management system, determine the overall security score of the customer system under each security indicator, and detect whether the performance of each key scenario in the customer system reaches the system availability bottom line; based on the overall security score, judge whether the customer system reaches the system security bottom line; when the customer system does not reach the system security bottom line and the system availability bottom line, determine that the customer system has potential risks and shut down the customer system.

[0024] In this embodiment, for the convenience of description, the following description is made with the business integration management system as the execution entity.

[0025] With the continuous advancement of Internet technology, enterprises are increasingly dependent on informatization. For real estate systems, various problems are prone to occur in daily system operations due to the different basic configuration facilities of the systems. The traditional post-monitoring mode, that is, solving problems only after system alarms or customer feedback, is difficult to meet current needs and is likely to damage the image of software suppliers in the minds of customers. Therefore, software suppliers are in urgent need of a proactive risk identification and response mechanism to ensure that potential risks can be discovered and handled in a timely manner when the bottom line of system security and availability is not threatened.

[0026] This application provides a solution that establishes a system security baseline and availability threshold by comprehensively using overall security scores and key scenario performance monitoring methods. When the system faces security risks, it immediately triggers the shutdown processing mechanism to achieve rapid response and effective isolation of potential threats, effectively curb the spread and escalation of risks, and significantly enhance the overall security defense capabilities and stability of the system, building a solid line of defense for the continuous and stable operation of the enterprise system, ensuring the dual protection of business continuity and customer trust.

[0027] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a business integration management system, etc. The following takes the business integration management system as an example to illustrate this embodiment and the following embodiments.

[0028] Based on this, the present application embodiment provides a risk prevention method, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the risk prevention method of the present application.

[0029] In this embodiment, applied to a business integrated management system, the risk prevention method includes steps S01 to S03: Step S01, for any customer system managed by the business integration management system, determine the overall security score of the customer system under each security indicator, and detect whether the performance of each key scenario in the customer system reaches the system availability bottom line; It should be noted that the business integration management system is a platform for centrally managing customer systems, which can realize functions such as security assessment, performance testing, problem diagnosis and repair of customer systems, including at least one customer system. The customer system refers to a single enterprise system or application managed by the business integration management system. The business integration management system predetermines a series of security indicators. Security indicators refer to specific standards or parameters used to measure the security of customer systems, including but not limited to the effectiveness of firewalls, the sensitivity of intrusion detection systems, the strength of data encryption, the strictness of user authority management, etc. For any customer system, the business integration management system calculates an overall security score for each customer system based on various security indicators. The overall security score reflects the comprehensive performance of the customer system in terms of security.

[0030] In addition, it should be noted that the business integration management system performs performance testing on each key scenario in the customer system. Key scenarios refer to operation pages frequently used by key users such as senior enterprise executives or high-frequency users of the system. These operation pages are crucial to business continuity, user experience or data security, such as user login, data query, transaction processing and other pages. By testing each key scenario, it is determined whether these scenarios can meet the established performance standards, such as response time, throughput, number of concurrent users, etc. The test results are recorded as compliance results. When the compliance results are that the performance of each key scenario does not meet the standards, it means that the customer system has not reached the system availability bottom line. The system availability bottom line refers to the key scenario performance standards set by the business integration management system, which are used to determine whether the customer system is available. Only when the compliance results of all key scenarios are qualified, the system is considered to have reached the availability bottom line. At the same time, the compliance results will serve as an important basis for subsequent judgment of whether the system has failed.

[0031] It can be understood that, through step S01, comprehensive consideration is given to multiple security indicators and key scenario performance, and comprehensive monitoring and evaluation of the customer system status is achieved, thereby improving the accuracy and reliability of risk detection and accurately reflecting the true status of the system. It is an important basis for preventing security risks in advance. At the same time, the detection of core pages can determine whether it affects the use of senior corporate executives or high-frequency system users, thereby enhancing the image and reputation in the minds of customers, which not only helps to maintain good customer relationships, but also can bring more business opportunities and market share to software suppliers.

[0032] Step S02, judging whether the customer system has reached the system security bottom line based on the overall security score; It should be noted that the business integration management system determines whether the customer system has reached the system security bottom line based on the overall security score obtained in step S01. The system security bottom line refers to the minimum security standard set by the business integration management system, which is used to determine whether the customer system is safe. Only when the overall security score of the customer system is higher than or equal to this standard, the system is considered to have reached the security bottom line.

[0033] It can be understood that, through step S02, a clear system safety bottom line is set, which achieves early warning of potential risks, so that intervention can be made before the risks cause substantial damage, solving the problem of post-monitoring in existing solutions, ensuring that the system operates under the premise of safety and availability, and avoiding losses caused by failure to discover risks in a timely manner.

[0034] Step S03: When the customer system does not reach the system security bottom line and the system availability bottom line, it is determined that the customer system has potential risks and the customer system is shut down.

[0035] It should be noted that, according to the judgment result of step S02, if the business integration management system determines that a certain customer system does not meet the system security bottom line and the system availability bottom line at the same time, then the business integration management system determines that the customer system has potential risks or performance problems and needs to be immediately shut down. The shutdown process is an emergency measure aimed at isolating the problem system from the business integration management system to prevent potential security risks or performance problems from having a greater impact on other customer systems or the entire business integration management system. After the shutdown process, the business integration management system will send the shutdown information and push it to the operation and maintenance engineers so that they can promptly repair the existing problems and ensure the safety and availability of the customer system.

[0036] It can be understood that through step S03, a power-off processing mechanism is introduced. When the customer system is judged to have reached the system security bottom line and the system availability bottom line, the business integration management system can quickly start the power-off processing mechanism, isolate the problem system, and prevent the risk from further spreading, thereby achieving a rapid response to the risk, improving processing efficiency, and ensuring the stability and reliability of the system.

[0037] In a feasible implementation, in step S01, the step of determining the overall security score of the client system under each security indicator includes steps A01 to A03: Step A01, for any one of the security indicators, detecting a monitoring object corresponding to the security indicator, and determining an indicator score of the security indicator according to a characteristic state of the monitoring object; It should be noted that according to the definition of each security indicator, its corresponding monitoring object is clearly defined. The monitoring object refers to the specific entity associated with the security indicator, such as servers, databases, sites, etc. The status of these objects directly affects the evaluation of the security indicator. The characteristic status of the monitoring object is collected through technical means (such as scanning, log analysis, etc.). The characteristic status refers to the current security status or configuration of the monitoring object. For example, for the firewall activation indicator, it is necessary to collect the activation status of the server firewall. According to the preset scoring criteria and the characteristic status of the monitoring object, the security indicator is scored. If the characteristic status meets the security standards, it is given a corresponding score. If it does not meet the standards, it is given a corresponding low score or deduction based on the degree of non-compliance.

[0038] In addition, it should be noted that the steps for determining each security indicator include: collecting historical security issues of the customer system, and the collection channels include but are not limited to the customer system's system logs, security incident reports, vulnerability scan results, and user historical feedback. The collected historical security issues are counted according to the type of problem (such as network attacks, system vulnerabilities, data leaks, etc.), and the occurrence trend of historical security issues is determined, such as time distribution, frequency changes, etc., and through correlation analysis, the correlation between different security issues is found. For example, certain vulnerabilities may lead to specific attack methods, and corresponding security indicators are obtained, such as firewall attack defense rate, vulnerability repair timeliness rate, data leakage protection rate, etc.

[0039] In addition, it should be noted that the collected historical security issues can also be counted according to the scope of impact (such as a single user, the entire system), and different levels of security indicators can be set, such as local security indicators (for a single user or component) and global security indicators (for the entire system); the collected historical security issues can also be counted according to the severity (such as minor, serious, extremely serious), and different weights or thresholds can be set for security indicators to reflect their different impacts on system security.

[0040] For example, through the analysis of customer historical data, combined with historical security issues that customers have encountered and the recommendations of security experts, the security issues currently faced by customers mainly include: host security, network security, application security, data security, code security and disaster recovery. These six aspects correspond to the first-level indicators in Table 1. Each first-level indicator has a corresponding first-level indicator description, and each security issue contains different security indicators. These second-level indicators correspond to the second-level indicators in Table 1. Each second-level indicator has a monitoring object (the objects mainly include servers, databases, and sites). Each indicator sets a specific indicator score based on its impact. Each security indicator will be tested every hour every day. When the monitored object meets the indicator requirements, it indicates the score of the security indicator. The corresponding indicator score needs to be recorded. For example, the indicator of firewall on is mainly used to detect whether the server has the firewall on, while the database / site does not need to be detected. If the firewall is on, 5 points will be added.

[0041] Table 1

[0042] Step A02: if there is an exemption requirement for the security indicator, modify the indicator score according to the exemption result corresponding to the exemption requirement; It should be noted that although the production systems of enterprises are based on basic configurations such as servers, databases, and sites, each enterprise has its own service characteristics: for central state-owned enterprises, any server, site, and database of the enterprise may be sensitive information. For such enterprises, the enterprise may have highly confidential machines that are not allowed to be monitored and tested. The enterprise will conduct additional high-precision tests on these basic configurations, but other things that are not very sensitive but also need to meet security standards need to be tested. Therefore, servers, sites, and databases that do not require attention need to be exempted; for some private enterprises, although the system has detected some potential risks, some of them are considered not to affect the core data of the system and the use of the system. Therefore, these indicators and objects can also be exempted.

[0043] For the above two situations, customers can upload authorized exemption files through the background, specify which security indicators do not need to be tested or evaluated, manually enter the requirements of the exemption files in the system, and check the indicators that need to be exempted as "failed / passed / not applicable". Exemption requirements refer to the requirements put forward by customers for not monitoring or evaluating certain security indicators based on their own business characteristics and security needs. For exempted indicators, their scores are modified according to the exemption results. Exemption requirements refer to the requirements put forward by customers for not monitoring or evaluating certain security indicators based on their own business characteristics and security needs. If the exemption result is "failed", the score of the indicator is directly set to 0 or the lowest score; if the exemption result is "passed", the original score of the indicator is kept unchanged; if the exemption result is "not applicable", the score of the indicator is ignored.

[0044] Step A03, integrating the corresponding indicator scores of each security indicator to obtain the overall security score of the customer system.

[0045] It should be noted that the indicator scores of each security indicator are summarized by category to obtain the total score of each category (such as host security, network security, etc.), and the total scores of each category are added together to obtain the overall security score of the customer system for reference and decision-making.

[0046] In addition, it should be noted that when integrating the total scores of each category, the total scores can also be weighted according to the importance and impact of each category to obtain the overall security score of the customer system. Before weighting, an importance analysis can be performed on each category, an initial weight can be assigned to each category, the customer system can be regularly monitored and evaluated for security, data on the security status of each category can be collected, and the weights of each category can be adjusted according to the monitoring and evaluation results and changes in system security requirements. For example, if security issues in a certain category occur frequently or the scope of impact expands, its weight can be appropriately increased.

[0047] In addition, it should be noted that when obtaining the indicator score of each safety indicator, the safety indicators that do not score or score below the passing line, as well as the monitoring objects corresponding to the safety indicators, are recorded for subsequent tracing of potential risks.

[0048] In this implementation, by real-time monitoring and evaluation of security indicators, the system can promptly discover and report potential security risks, providing timely and accurate information support to the security team, which not only improves the overall security of the system, but also reduces the risks of business interruption and data leakage caused by security risks. By introducing an exemption mechanism, the system can flexibly handle customer-specific exemption requirements, avoiding false alarms or unnecessary interference caused by overly strict security policies, making security assessments closer to the actual needs of customers and improving the accuracy and practicality of the assessments.

[0049] In a feasible implementation, in step A02, when there is an exemption requirement for the security indicator, before the step of modifying the indicator score according to the exemption requirement corresponding to the exemption result, steps A11-A12 are also included: Step A11, determining whether the safety indicators for which exemption requirements exist include safety indicators according to the preset indicator exemption rules, wherein the preset indicator exemption rules are determined by the exemption document, and the exemption document includes the safety indicators for which exemption requirements exist; It should be noted that corporate customers upload internally reviewed and authorized exemption documents through the exclusive backend system provided for each customer. The exemption documents are in electronic format and include the exemption requirements defined by the enterprise based on its own business characteristics and security policies. They list in detail which security indicators do not need to be monitored and tested due to special reasons (such as high confidentiality, non-core impacts, etc.). For example, central state-owned enterprises may be exempted from monitoring certain highly confidential machines, while private enterprises may be exempted from testing for some security vulnerabilities that do not affect core data and system use. The preset indicator exemption rules are determined by the exemption document and are used to automatically identify and match security indicators with exemption requirements in the system. The implementation of the rules depends on the parsing and matching algorithms of the exemption document content.

[0050] In addition, it should be noted that after the exemption file is uploaded, the administrator can analyze the content in the exemption file and mark the security indicators with exemption requirements. The uploaded exemption file can also be automatically parsed through the file reading method, and the data structure therein can be parsed according to the format of the exemption file. In the parsed data structure, information related to the exemption indicators is searched, and all security indicators with exemption requirements are extracted according to preset rules or field names. They are verified to ensure that they comply with the enterprise security policy. If exemption indicators that do not comply with the enterprise security policy are found, they are marked as invalid, and the extracted security indicators with exemption requirements are updated to the preset indicator exemption rules.

[0051] Step A12: When the security indicators for which exemption is required include the security indicator, receiving input content of the security indicator, and determining the exemption result corresponding to the security indicator according to the input content.

[0052] It should be noted that after uploading the exemption file, the system will automatically check which security indicators need to be exempted according to preset rules. For security indicators that need to be exempted, the system will provide a manual entry interface, allowing administrators to enter the exemption results for the security indicators that need to be exempted based on the actual status of the security indicators. On the manual entry interface, according to the specific requirements of the exemption file, check each security indicator that needs to be exempted as "failed", "passed" or "not applicable". The system will automatically update the exemption results of these security indicators based on the user's input.

[0053] For example, to help understand the technical concept or technical principle of this application, please refer to Figure 2 , Figure 2 A scenario diagram of the exemption indicator entry interface is provided. For the security indicator "SYN flood attack", the system's inspection result for this security indicator in the customer system is failure. When the administrator manually marks this security indicator as "passed", it means that this security indicator is exempted and its status is considered to meet the security standards.

[0054] In addition, it should be noted that for each security indicator that needs to be exempted, "failed" means that although the security indicator is exempted, it may fail if tested in theory. It is usually used for indicators that cannot be tested due to high confidentiality, but the company believes that its status may not meet security standards. "Passed" means that the security indicator is exempted, and the company believes that its status meets security standards. It is usually used for security vulnerabilities or configurations that do not affect the core data and use of the system. "Not applicable": It means that the security indicator is not applicable in the current environment, and whether it is tested or not will not affect the overall security assessment of the system.

[0055] In addition, it should be noted that for security indicators without exemption requirements, the system continues to obtain the test results of these indicators in real time or regularly according to the established monitoring and detection strategies, and these results will serve as an important basis for security assessment; for security indicators with exemption requirements, the system uses manually entered results (i.e. exemption results) as the final results of these indicators, which means that these indicators will no longer be subject to automatic monitoring and detection by the system, and their status will be directly confirmed by enterprise users based on the requirements of the exemption documents.

[0056] In this implementation, by setting up an exemption mechanism, the system can be adjusted and optimized according to the customer's specific exemption requirements, which not only avoids the responsibility when a safety accident occurs (safety accidents caused by failure to monitor exemption indicators), but also automatically stops obtaining deductions for these indicators during safety assessments, ensuring that the system safety status can be reflected more accurately, improving the flexibility and accuracy of safety assessments, making safety assessments closer to the actual needs of customers, and improving the practicality and effectiveness of the assessments.

[0057] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 3 In step S01, the step of detecting whether the performance of each key scenario in the customer system reaches the system availability bottom line includes steps S11 to S13: Step S11, determining key scenarios in the client system and core users using the client system; It should be noted that key scenarios and core users of the system are extracted from the customer system. Key scenarios refer to pages in the customer system that are critical to business operations. Core users refer to users who have high requirements for system performance and whose business activities are sensitive to system stability, such as senior corporate executives and high-frequency system users.

[0058] Step S12, determining, based on the user behavior data, key scenarios and core users in the client system, user data when each core user accesses any page in the client system, and scenario data when a key scenario is accessed by any user; It should be noted that since software suppliers have various data on customer system access, such as the number of visits and duration of each person's visits to each page at each time point, they can obtain access data such as users and pages of all systems, core pages and core people maintained by all operation and maintenance engineers, standard thresholds of all core pages (if the threshold is exceeded, the page access is considered to have timed out), and various functional points and page information in the system. Among them, the focus is on information related to users, pages, etc., that is, user behavior data. User behavior data refers to the behavior records of users accessing the system, such as the number of visits, duration, request response time, etc. User data and scenario data are determined through user behavior data. User data refers to the performance data of key users accessing any page, and scenario data refers to the performance data of key scenarios accessed by any user.

[0059] Step S13, when any one of the user data satisfies the first preset rule and any one of the scene data satisfies the second preset rule, it is determined that the performance of each key scene in the client system reaches the system availability bottom line.

[0060] It should be noted that by utilizing the big data platform and analyzing historical data on user behavior in the data warehouse, the compliance status of the first preset rule and the second preset rule in each customer system is calculated every day. The first preset rule refers to the judgment rule for core users accessing any page in the customer system, and the second preset rule refers to the judgment rule for key scenarios accessed by any user. When both the first preset rule and the second preset rule are met, it is determined that the customer system has reached the bottom line of system availability.

[0061] For example, for each user data when each core user accesses any page in the client system, the first preset rule may be: Condition ①: The number of times the core user visits any page and opens it for more than 3 seconds per day / the total number of times the core user visits any page per day >= 10%; Condition ②: The total number of times the core user visits any page every day is greater than or equal to 5 times; Condition ③: 4 out of 7 consecutive days meet both conditions ① and ②.

[0062] For each scene data when each key scene is accessed by any user, the second preset rule may be: Condition ①: For any key scenario, the number of requests with a request time exceeding 3 seconds / the total number of visits to the key scenario>=10%; Condition ②: The total number of visits to the key scene per day is greater than or equal to 25 times; Condition ③: The same key scene meets both conditions ① and ② for 5 out of 7 consecutive days.

[0063] If any dimension (user data or scenario data) does not meet the standard, the core page performance of the customer's system is judged to have failed, indicating that the system availability bottom line has not been reached.

[0064] In this implementation, performance monitoring of important parts of the system is achieved by identifying key scenarios and core users. The accuracy and efficiency of monitoring are improved by obtaining data related to core page performance and quantifying qualitative problems. By formulating reasonable judgment rules, potential performance risks of the system can be discovered in a timely manner, so that corresponding measures can be taken in a timely manner for optimization, thereby ensuring the security, availability and stability of the system.

[0065] In a feasible implementation, in step S11, the step of determining each key scenario in the client system and each core user using the client system includes steps B01 to B02: Step B01, detecting personalized scenarios whose page data in the customer system meets the scenario recognition rules, and saving them in a preset scenario database, which also includes standardized scenarios, which are imported by an administrator of the business integration management system. The standardized scenarios and personalized scenarios constitute key scenarios in the customer system; It should be noted that each customer system generally deploys multiple subsystems (such as cost system, sales system), and each subsystem has multiple pages. In the early stage of purchasing a customer system, each customer basically ships it in the form of a standardized system. For standardized systems, administrators will use common and general standardized scenarios involving amounts and customer project information as key scenarios, and import them into the preset scenario database. The administrator refers to the maintainer of the business integration management system, who is responsible for importing standardized scenarios, managing databases, etc.

[0066] In addition, it should be noted that with the development of customer enterprises, each customer system will have more or less secondary customization needs, and some functions will be added or modified according to the development of its own business. For customized personalized systems, additional key scenarios that are not recorded in the customer system are maintained, and the scenarios in the customer system are detected through scene recognition rules, and the page data of the scenes are determined to meet the personalized scenarios of the scene recognition rules. Among them, page data refers to the specific information of each page in the customer system, such as page content, visits, response time, etc. Scene recognition rules refer to rules for identifying which page data constitute specific scenarios (such as high-visit scenarios, high-latency scenarios, etc.). Personalized scenarios refer to unique scenes in specific customer systems that are automatically detected based on page data and scene recognition rules. Each standardized scene and each personalized scene are imported into the preset scene database.

[0067] Exemplarily, for any scene in the client system, the scene recognition rule may be: ① The number of users who visit this scenario each month accounts for 20% of the total number of active users this month; ②The scene is visited more than 18 days per month; ③This scene is dedicated to high-rise buildings; The scenario in which conditions ① and ② are met at the same time and condition ③ is met alone is regarded as a personalized scenario.

[0068] Step B02, detects each first user whose usage data meets the user identification rules among the users using the customer system, and saves them into a preset user database. The preset user database also includes each second user. Each second user is imported by the administrator of the business integration management system. Each first user and each second user constitutes each core user in the customer system.

[0069] It should be noted that each customer system is visited by many users every day. However, since the company's senior staff and high-frequency users of the system have a lot of daily business, if the work efficiency of these personnel is hindered due to the performance of the system pages, it will affect the image in the minds of customers. Therefore, it is necessary to pay special attention to these key users and the pages they visit. Generally speaking, administrators will have some understanding of the application personnel of the customer systems they are responsible for, and can directly include these second users who have been identified as core users into the preset user database.

[0070] In addition, it should be noted that although the administrator may be able to identify some core users due to familiarity with the business, there is a high probability that there are potential core users that have not been identified. For the core users that have not been identified, the core members are screened out through user identification rules, and the user usage data is analyzed to identify the first user who meets the user identification rules and save it together with the second user in the preset user database.

[0071] Exemplarily, for each user using the client system, the user identification rule may be: ①Access the system for more than 18 days per month; ②The number of monthly access functions accounts for more than 20% of the overall function data; The user who meets both conditions ① and ② is regarded as the second user.

[0072] In this implementation, by accurately identifying key scenarios and users, obtaining data related to core page performance, and applying specific algorithms to calculate performance indicators, real-time monitoring and early warning of system performance are achieved. This not only ensures the security and availability of the system, but also enables timely discovery and resolution of potential risks, thereby avoiding the impact on the business caused by system performance issues.

[0073] In a feasible implementation manner, in step S02, the step of judging whether the client system has reached the system security bottom line based on the overall security score includes step B11: Step B11: In the overall security score, if the corresponding score of any security indicator satisfies the corresponding score threshold, and the overall security score satisfies the overall score threshold, it is determined that the customer system has reached the system security bottom line.

[0074] It should be noted that in the overall security score, if the score of any security indicator meets its corresponding score threshold, and the overall security score also meets the preset overall score threshold, then the system can determine that the customer system has reached the system security bottom line.

[0075] For example, the system has six major security indicators: host security, network security, application security, data security, and code security. If the host security score is selected as the judgment condition, as shown in Table 2, when the overall security score is <80 and the host security score is <35, the customer system is considered to have reached the system security bottom line. Among them, the host security score can be replaced by any one of the network security score, application security score, data security score, and code security score. When the performance of each key scenario does not meet the standard, the customer system is considered to have reached the system availability bottom line.

[0076] Table 2

[0077] In this implementation, by calculating the overall safety score and setting thresholds for various safety indicators and the overall score, the system can evaluate the current safety status, not only considering the overall safety situation, but also paying attention to the details of each safety indicator, so as to more comprehensively discover potential risks, enabling the system to monitor and evaluate the overall safety score and key scenario performance in real time, and issue early warnings before risks occur.

[0078] In a feasible implementation, in step S03, the step of performing power off processing on the customer system includes steps B21-B22: Step B21, after receiving the system shutdown signal, determine the potential risks in the customer system according to the indicator scores under each security indicator; It should be noted that the system shutdown signal refers to the signal that the system proactively takes to stop running or limit some functions in order to prevent further security risks. After receiving the shutdown signal, the system evaluates the indicator scores under each security indicator, determines the security indicators that are recorded as no score or score below the passing line, and the corresponding monitoring objects of the security indicators, so as to determine the system problems that cause the unqualified score and determine the specific potential risks in the customer system. These potential risk information includes detailed information such as the type, location, and severity of the vulnerability.

[0079] For example, if the score corresponding to the indicator "High-risk patch installation" under the host security indicators is 0, it is considered that the system problem that caused the unqualified score may be due to the installation of high-risk patches in the system. If there are multiple indicators that have no score or the score is below the passing line, the corresponding monitoring objects of these security indicators are comprehensively considered to determine whether the unqualified score is caused by these monitoring objects.

[0080] Step B22, suspend the operation of the client system, and output various potential risk information and system shutdown information.

[0081] It should be noted that in order to prevent potential risks from being exploited and causing greater losses, the system will immediately suspend the operation of the customer's system and generate a detailed report containing information on various potential risks and system shutdown information. The system shutdown information includes the specific reasons, time, and safety indicators involved in triggering the shutdown signal. The system will push the above report to the corresponding operation and maintenance engineer. After receiving the pushed information, the operation and maintenance engineer will immediately review and analyze the report to determine the severity of the problem and the repair plan. During the repair process, the operation and maintenance engineer may communicate with the customer to understand the specific background and scope of the problem in order to better formulate a repair plan. After the repair is completed, the operation and maintenance engineer will conduct verification and testing to ensure that the problem is thoroughly resolved. After confirming that all potential risks have been repaired, the customer system will be restarted. The business integration management system will conduct a security assessment again to ensure that the overall security score of the customer system reaches the preset threshold, and verify whether the performance of each key scenario is up to standard to ensure the availability and stability of the customer system.

[0082] In addition, it should be noted that after judging the system safety bottom line and the system availability bottom line, the customer system can also perform the following steps: if the customer system does not reach the system safety bottom line, the system potential risks will be fed back to the operation and maintenance engineer; if the customer system does not reach the system availability bottom line, the key scenarios that cause the performance of each key scenario in the customer system to fail to meet the standards will be determined, and these key scenarios will be fed back to the operation and maintenance engineer, so that the operation and maintenance engineer can determine the problems in the key scenarios and repair them to provide users with a better user experience.

[0083] In this embodiment, by real-time monitoring of safety indicators and automatically determining potential risks after triggering a power-off signal, real-time discovery of potential system risks is achieved. By pausing the operation of the customer system and outputting potential risk information, it is ensured that the problem will not spread further before being repaired, thereby protecting the security and integrity of the system.

[0084] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the risk prevention method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0085] This application also provides a risk prevention device, please refer to Figure 4 , applied to the business integrated management system, which is used to manage each customer system. The risk prevention device includes: The scoring module 10 is used to determine the overall security score of the customer system under each security indicator for any customer system managed by the business integration management system, and to detect whether the performance of each key scenario in the customer system reaches the system availability bottom line; A judgment module 20 is used to judge whether the customer system has reached the system security bottom line based on the overall security score; The processing module 30 is used to determine that there is a potential risk in the customer system and shut down the customer system when the customer system does not reach the system security bottom line and the system availability bottom line.

[0086] Optionally, the scoring module 10 is further used for: For any one of the safety indicators, detect the monitoring object corresponding to the safety indicator, and determine the indicator score of the safety indicator according to the characteristic state of the monitoring object; In the case of exemption requirements for safety indicators, the indicator score shall be modified according to the exemption results corresponding to the exemption requirements; Integrate the corresponding indicator scores of each security indicator to obtain the overall security score of the customer system.

[0087] Optionally, the scoring module 10 is further used for: Determine whether the safety indicators for which exemption requirements exist include safety indicators according to the preset indicator exemption rules. The preset indicator exemption rules are determined by the exemption document, which contains the safety indicators for which exemption requirements exist; In the case where the various security indicators for which exemption requirements exist include a security indicator, input content for the security indicator is received, and an exemption result corresponding to the security indicator is determined according to the input content.

[0088] Optionally, the scoring module 10 is further used for: Identify the key scenarios in the customer system and the core users of the customer system; Based on the user behavior data, key scenarios and core users in the customer system, determine the user data when each core user accesses any page in the customer system, and the scenario data when the key scenario is accessed by any user; When any one of the user data satisfies the first preset rule and any one of the scene data satisfies the second preset rule, it is determined that the performance of each key scene in the client system reaches the system availability bottom line.

[0089] Optionally, the scoring module 10 is further used for: Detecting personalized scenarios whose page data in the customer system meets the scenario recognition rules and saving them in a preset scenario database. The preset scenario database also includes standardized scenarios, which are imported by the administrator of the business integration management system. The standardized scenarios and personalized scenarios constitute key scenarios in the customer system. Among the users who use the customer system, the first users whose usage data meets the user identification rules are detected and saved in a preset user database. The preset user database also includes the second users. The second users are imported by the administrator of the business integration management system. The first users and the second users constitute the core users in the customer system.

[0090] Optionally, the judging module 20 is further configured to: In the overall security score, if the corresponding score of any security indicator meets the corresponding score threshold and the overall security score meets the overall score threshold, the customer system is judged to have reached the system security bottom line.

[0091] Optionally, the processing module 30 is further configured to: After receiving the system shutdown signal, determine the potential risks in the customer system based on the indicator scores under each security indicator; Suspend the operation of the customer's system and output various potential risk information and system shutdown information.

[0092] The risk prevention device provided by the present application adopts the risk prevention method in the above-mentioned embodiment, which can solve the technical problem of how to timely discover potential risks of the system while ensuring the safety and availability of the system. Compared with the prior art, the beneficial effects of the risk prevention device provided by the present application are the same as the beneficial effects of the risk prevention method provided by the above-mentioned embodiment, and the other technical features in the risk prevention device are the same as the features disclosed in the above-mentioned embodiment method, which will not be repeated here.

[0093] The present application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the risk prevention method in the above-mentioned embodiment one.

[0094] Reference below Figure 5 , which shows a schematic diagram of the structure of an electronic device suitable for implementing an embodiment of the present application. The electronic device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, notebook computers, PADs (Portable Application Description: tablet computers), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The electronic device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0095] like Figure 5As shown, the electronic device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the electronic device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows an electronic device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0096] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0097] The electronic device provided by the present application adopts the risk prevention method in the above embodiment, which can solve the technical problem of how to timely discover potential risks of the system while ensuring the safety and availability of the system. Compared with the prior art, the beneficial effects of the electronic device provided by the present application are the same as the beneficial effects of the risk prevention method provided by the above embodiment, and the other technical features in the electronic device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0098] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0099] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0100] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, wherein the computer-readable program instructions are used to execute the risk prevention method in the above-mentioned embodiment.

[0101] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0102] The computer-readable storage medium may be included in the electronic device, or may exist independently without being installed in the electronic device.

[0103] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by an electronic device, the risk prevention device is applied to the business integration management system, and can determine the overall security score of the customer system under each security indicator for any customer system managed under the business integration management system, and detect whether the performance of each key scenario in the customer system reaches the system availability bottom line; judge whether the customer system reaches the system safety bottom line based on the overall security score; if the customer system does not reach the system safety bottom line and the system availability bottom line, it is determined that there is a potential risk in the customer system, and the customer system is shut down.

[0104] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0105] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0106] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0107] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned risk prevention method, and can solve the technical problem of how to timely discover potential risks of the system while ensuring the safety and availability of the system. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the risk prevention method provided by the above-mentioned embodiment, and will not be elaborated here.

[0108] The present application also provides a computer program product, including a computer program, which implements the steps of the risk prevention method as described above when the computer program is executed by a processor.

[0109] The computer program product provided by this application can solve the technical problem of how to timely discover potential risks of the system while ensuring the safety and availability of the system. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the risk prevention method provided by the above embodiment, which will not be repeated here.

[0110] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A risk prevention method, characterized in that: Applied to the business integrated management system, the risk prevention method includes: For any customer system managed by the business integrated management system, determine the overall security score of the customer system under each security indicator, and detect whether the performance of each key scenario in the customer system reaches the system availability bottom line; Determine whether the customer system has reached the system security bottom line based on the overall security score; In the case that the customer system does not reach the system security bottom line and the system availability bottom line, it is determined that the customer system has potential risks and the customer system is shut down.

2. The risk prevention method according to claim 1, characterized in that: The step of determining the overall security score of the client system under each security indicator comprises: For any one of the safety indicators, detecting a monitoring object corresponding to the safety indicator, and determining an indicator score of the safety indicator according to a characteristic state of the monitoring object; In the case where there is an exemption requirement for the safety indicator, modify the indicator score according to the exemption result corresponding to the exemption requirement; The corresponding indicator scores of the various security indicators are integrated to obtain the overall security score of the customer system.

3. The risk prevention method according to claim 2, characterized in that: In the case where there is an exemption requirement for the safety indicator, before the step of modifying the indicator score according to the exemption requirement corresponding to the exemption result, the step further includes: Determining whether the safety indicators for which exemption requirements exist include the safety indicator according to the preset indicator exemption rule, wherein the preset indicator exemption rule is determined by the exemption document, and the exemption document includes the safety indicators for which exemption requirements exist; In a case where the security indicator is included in the security indicators for which exemption is required, input content of the security indicator is received, and an exemption result corresponding to the security indicator is determined according to the input content.

4. The risk prevention method according to claim 1, characterized in that: The step of detecting whether the performance of each key scenario in the client system reaches the system availability bottom line includes: Identify key scenarios in the client system and core users using the client system; Determine, based on the user behavior data in the client system, the key scenarios and the core users, the user data when the core users access any page in the client system, and the scenario data when the key scenarios are accessed by any users; When any one of the user data satisfies the first preset rule and any one of the scenario data satisfies the second preset rule, it is determined that the performance of each key scenario in the client system reaches the system availability bottom line.

5. The risk prevention method according to claim 4, characterized in that: The step of determining each key scenario in the client system and each core user using the client system includes: Detecting personalized scenarios whose page data in the client system meets the scenario recognition rules, and saving them in a preset scenario database, wherein the preset scenario database also includes standardized scenarios, which are imported by an administrator of the business integrated management system, and the standardized scenarios and personalized scenarios constitute key scenarios in the client system; Among the users using the client system, first users whose usage data satisfy the user identification rules are detected and saved in a preset user database. The preset user database also includes second users, and the second users are imported by the administrator of the business integration management system. The first users and the second users constitute the core users in the client system.

6. The risk prevention method according to claim 1, characterized in that: The step of judging whether the client system has reached the system security bottom line based on the overall security score comprises: In the overall security score, if the corresponding score of any security indicator satisfies the corresponding score threshold, and the overall security score satisfies the overall score threshold, it is determined that the customer system has reached the system security bottom line.

7. The risk prevention method according to claim 1, characterized in that: The step of shutting down the client system comprises: After receiving the system shutdown signal, determine the potential risk in the customer system according to the indicator scores under each security indicator; The operation of the client system is suspended, and the potential risk information and system shutdown information are output.

8. An electronic device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the risk prevention method according to any one of claims 1 to 7.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the risk prevention method according to any one of claims 1 to 7 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the risk prevention method according to any one of claims 1 to 7 are implemented.

Images