Diagnostic request processing method, apparatus, device, storage medium, and program product

Abstract

This embodiment discloses a method, apparatus, device, storage medium, and program product for processing diagnostic requests. The method includes: receiving at least one diagnostic request for digital information; when the security type of a first diagnostic request in the at least one diagnostic request is a security request, identifying the diagnostic intent of the first diagnostic request through an intent recognition big data model, and determining whether the profile of the initiator of the first diagnostic request matches the diagnostic intent to obtain a judgment result; re-determining the security type of the first diagnostic request based on the judgment result; and performing protective processing on the first diagnostic request based on the security type and the diagnostic intent.

Description

Technical Field

[0001] This application belongs to the technical field of Artificial Intelligence (AI), and specifically relates to a method, apparatus, device, storage medium, and program product for processing diagnostic requests. Background Technology

[0002] In related technologies, the diagnosis of digital information (such as digitalization level) of enterprises and other organizations is mainly carried out through paper questionnaires, online form filling, offline needs analysis, and on-site visits. However, when diagnosing digital information, intent recognition is not performed, which can easily expose some sensitive content. In other words, there is a low security problem when diagnosing digital information. Summary of the Invention

[0003] To address the issue of low security when diagnosing digital information in related technologies, embodiments of this application propose a method, apparatus, device, storage medium, and program product for processing diagnostic requests.

[0004] This application provides a method for processing diagnostic requests, the method comprising:

[0005] Receive at least one diagnostic request for digital information;

[0006] When the security type of the first diagnostic request in the at least one diagnostic request is a security request, the diagnostic intent of the diagnostic request is identified by the Large Language Model (LLM), and it is determined whether the profile of the initiator of the first diagnostic request matches the diagnostic intent to obtain a judgment result.

[0007] The security type of the first diagnostic request is re-determined based on the judgment result;

[0008] Based on the security type and the diagnostic intent, the first diagnostic request is protected.

[0009] In some embodiments, the profile of the initiator includes at least a set of diagnostic information tags of the initiator, the diagnostic information tags being determined based on the diagnostic intent of the diagnostic request initiated by the initiator; the step of re-determining the security type of the first diagnostic request based on the determination result includes: if the diagnostic intent belongs to the set of diagnostic information tags of the initiator, determining the security type of the first diagnostic request as a security request; if the diagnostic intent does not belong to the set of diagnostic information tags of the initiator, determining the security type of the first diagnostic request as a dangerous request.

[0010] As can be seen, the embodiments of this application can determine the security type of the first diagnostic request more accurately based on the relationship between the diagnostic intent of the first diagnostic request and the set of diagnostic information tags of the initiator, thereby facilitating the accurate protection processing of the first diagnostic request based on its security type.

[0011] In some embodiments, the step of protecting the first diagnostic request according to the security type and the diagnostic intent includes: when the security type of the first diagnostic request is a dangerous request, sending the first diagnostic request to a diagnostic request garbage resource pool, the diagnostic request garbage resource pool being used to generate notification information for processing the first diagnostic request; when the security type of the first diagnostic request is a safe request, determining a security value representing the security level of the first diagnostic request according to the security type of the first diagnostic request and the diagnostic intent; and protecting the first diagnostic request according to the relationship between the security value and a security threshold value.

[0012] It can be seen that when the security type of the first diagnostic request is a dangerous request, it can be considered that the first diagnostic request is very likely to have a dangerous intent. At this time, by sending the first diagnostic request to the diagnostic request garbage resource pool and generating a notification message for processing the first diagnostic request, the security protection of the first diagnostic request can be effectively achieved. When the security type of the first diagnostic request is a safe request, the security value representing the security level of the first diagnostic request can be determined more accurately according to the security type and diagnostic intent of the first diagnostic request. Based on this, the security protection processing of the first diagnostic request can be effectively carried out according to the relationship between the security value and the security threshold value.

[0013] In some embodiments, the profile of the initiator further includes the reputation value of the initiator; determining the security value representing the security level of the first diagnostic request based on the security type of the first diagnostic request and the diagnostic intent includes: determining the security value based on the security type of the first diagnostic request, the diagnostic intent, and the reputation value of the initiator, wherein the security value is positively correlated with the reputation value of the initiator. It can be seen that the embodiments of this application can reasonably determine the security value representing the security level of the first diagnostic request by comprehensively considering the security type of the first diagnostic request, the diagnostic intent, and the reputation value of the initiator.

[0014] In some embodiments, after determining the reputation value of the initiator, the method further includes: determining a security threshold value, wherein the security threshold value is positively correlated with the reputation value of the initiator of the first diagnostic request and negatively correlated with the sum of the reputation values ​​of the initiators of all received diagnostic requests.

[0015] In some embodiments, determining a security value representing the security level of the first diagnostic request based on the security type of the first diagnostic request and the diagnostic intent includes: determining an intent behavior classification value based on the degree of danger of the diagnostic intent, wherein the intent behavior classification value is positively correlated with the degree of danger; and determining the security value based on the security type of the first diagnostic request and the intent behavior classification value, wherein the security value is negatively correlated with the intent behavior classification value.

[0016] It can be seen that the higher the degree of danger of the diagnostic intent, the larger the classification value of the intended behavior and the smaller the safety value; conversely, the lower the degree of danger of the diagnostic intent, the larger the safety value. Therefore, the safety value can be determined relatively accurately based on the degree of danger of the diagnostic intent.

[0017] In some embodiments, determining the intention behavior classification value based on the degree of danger of the diagnostic intention includes: determining the intention behavior classification value based on the degree of danger of the diagnostic intention and the sensitivity of the data carried in the first diagnostic request, wherein the intention behavior classification value is positively correlated with the sensitivity of the data carried in the first diagnostic request.

[0018] In some embodiments, determining the security value based on the security type of the first diagnostic request and the intent behavior classification value includes: determining the security value based on the security type of the first diagnostic request, the intent behavior classification value, and the data sensitivity of the initiator of the first diagnostic request, wherein the security value is negatively correlated with the data sensitivity of the initiator of the first diagnostic request.

[0019] In some embodiments, the step of protecting the first diagnostic request based on the relationship between the security value and the security threshold includes: if the security value is less than the security threshold, protecting the first diagnostic request through a Demilitarized Zone (DMZ); if the security value is greater than or equal to the security threshold, sending the first diagnostic request to a first server, wherein the first server processes the first diagnostic request according to a predetermined processing logic.

[0020] As can be seen, since the security value represents the security level of the first diagnostic request, when the security value is less than the security threshold, the security level of the first diagnostic request can be considered low. In this case, by protecting the first diagnostic request through the DMZ, the risk of processing the diagnostic request can be effectively reduced. When the security value is greater than or equal to the security threshold, the security level of the first diagnostic request can be considered high. In this case, by sending the first diagnostic request to the first server, it is convenient to process the first diagnostic request according to the predetermined processing logic.

[0021] In some embodiments, after the first diagnostic request is protected by the DMZ, the method further includes: forwarding the first diagnostic request to the diagnostic request garbage resource pool or the first server according to the protection processing result of the first diagnostic request in the DMZ.

[0022] It can be seen that when the first diagnostic request is sent to the first server, it means that the security value is greater than or equal to the security threshold value, and the first diagnostic request can be considered a security request. In this case, by adding diagnostic intent to the set of diagnostic information tags of the initiator of the first diagnostic request, the profile of the initiator of the first diagnostic request can be updated in a timely manner.

[0023] In some embodiments, after sending the first diagnostic request to the first server, the method further includes: adding the diagnostic intent to the set of diagnostic information tags of the initiator.

[0024] This application embodiment also provides a diagnostic request processing apparatus, the apparatus comprising:

[0025] A receiving module is used to receive at least one diagnostic request for digitized information;

[0026] The first processing module is configured to, when the security type of the first diagnostic request in the at least one diagnostic request is a security request, identify the diagnostic intent of the diagnostic request through an intent recognition big model, and determine whether the profile of the initiator of the first diagnostic request matches the diagnostic intent, and obtain a judgment result.

[0027] The second processing module is used to redetermine the security type of the first diagnostic request based on the judgment result; and to perform protective processing on the first diagnostic request based on the security type and the diagnostic intent.

[0028] This application also provides an electronic device, which includes a processor and a memory for storing a computer program that can run on the processor; wherein the processor is used to run the computer program to perform any of the above-described diagnostic request processing methods.

[0029] This application also provides a computer storage medium storing a computer program that, when executed by a processor, implements any of the above-described diagnostic request processing methods.

[0030] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the above-described diagnostic request processing methods.

[0031] As can be seen, when the security type of the first diagnostic request is a security request, the profile of the initiator of the first diagnostic request and the diagnostic intent of the first diagnostic request can be introduced. By judging whether the profile of the initiator of the first diagnostic request matches the diagnostic intent, the security type of the first diagnostic request can be re-determined. That is, the embodiments of this application can more accurately determine the security type of the first diagnostic request based on the profile of the initiator of the first diagnostic request. Furthermore, based on the security type and diagnostic intent of the first diagnostic request, the first diagnostic request can be protected more effectively, which is conducive to improving the security of diagnosing digital information. Attached Figure Description

[0032] Figure 1 This is a flowchart illustrating a method for processing diagnostic requests according to an embodiment of this application.

[0033] Figure 2 This is a schematic diagram of the structure of the diagnostic request system according to an embodiment of this application;

[0034] Figure 3 This is an internal structure diagram of the intent recognition module in the embodiments of this application;

[0035] Figure 4 This is a schematic diagram of the structure of a diagnostic request processing device according to an embodiment of this application;

[0036] Figure 5 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0037] The need for diagnostics of digital information (i.e., digital transformation status) among enterprises and other organizations is increasing. Diagnosing digital information is a complex process involving assessing the organization's current digitalization level, analyzing needs, identifying challenges, and developing transformation strategies. Related technologies primarily diagnose an organization's digital information through paper questionnaires, online forms, offline needs analysis, and on-site visits. These diagnostic methods largely rely on the experience accumulated by relevant service providers.

[0038] The technical solutions of the relevant technologies have at least the following problems: 1) They are inconvenient for customers to use. Since the diagnostic methods mainly rely on relevant service providers, institutions lack independent diagnostic technical means, and the diagnostic process is time-consuming and laborious; 2) When diagnosing digital information, intent recognition is not performed, which results in low security.

[0039] In view of the technical problems existing in related technologies, this application proposes technical solutions based on its embodiments.

[0040] The embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the embodiments provided herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application. Furthermore, the embodiments provided below are some embodiments for implementing this application, and not all embodiments for implementing this application. Unless otherwise specified, the technical solutions described in the embodiments of this application can be implemented in any combination.

[0041] It should be noted that, in the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a method or apparatus that includes a list of elements includes not only the elements expressly described, but also other elements not expressly listed, or elements inherent to implementing the method or apparatus. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other related elements (e.g., steps in the method or units in the apparatus, such as portions of circuitry, processors, programs, or software, etc.) in the method or apparatus that includes that element.

[0042] The diagnostic request processing method provided in this application includes a series of steps, but the diagnostic request processing method provided in this application is not limited to the steps described. Similarly, the diagnostic request processing apparatus provided in this application includes a series of modules, but the apparatus provided in this application is not limited to the modules explicitly described, and may also include modules that need to be set up for obtaining relevant information or processing based on information.

[0043] Figure 1 This is a flowchart of a diagnostic request processing method according to an embodiment of this application, such as... Figure 1 As shown, the process includes:

[0044] Step 101: Receive at least one diagnostic request for digitized information.

[0045] Here, when there is at least one diagnostic request and there are multiple diagnostic requests, the initiators of the multiple diagnostic requests can be multiple different initiators or the same initiator.

[0046] Step 102: When the security type of the first diagnostic request in at least one diagnostic request is a security request, the diagnostic intent of the first diagnostic request is identified by the intent recognition big model, and it is determined whether the profile of the initiator of the first diagnostic request matches the diagnostic intent to obtain the judgment result.

[0047] When at least one diagnostic request is multiple diagnostic requests, the first diagnostic request is any one of the multiple diagnostic requests. In some embodiments, after receiving at least one diagnostic request, a security tool can be used to perform a security scan on the Uniform Resource Locator (URL) and attachments of the first diagnostic request to determine the security type of the first diagnostic request, which can be a secure request or a dangerous request.

[0048] The training data for the large-scale intent recognition model can be obtained from a pre-built knowledge base. For example, the knowledge base can store multiple diagnostic requests and the corresponding true intents of the diagnostic requests. The diagnostic intent identified by the large-scale intent recognition model can be denoted as C(m).

[0049] In some embodiments, the profile of the initiator of the first diagnostic request includes at least a set of diagnostic information tags of the initiator, which are determined based on the diagnostic intent of the diagnostic request initiated by the initiator. When the diagnostic intent of the first diagnostic request belongs to the set of diagnostic information tags of the initiator of the first diagnostic request, it is determined that the profile of the initiator of the first diagnostic request matches the diagnostic intent; when the diagnostic intent of the diagnostic request does not belong to the set of diagnostic information tags of the initiator of the first diagnostic request, it is determined that the profile of the initiator of the first diagnostic request does not match the diagnostic intent.

[0050] Step 103: Determine the security type of the first diagnostic request based on the judgment result.

[0051] In some embodiments, the process of re-determining the security type of the first diagnostic request based on the judgment result includes: determining the security type of the first diagnostic request as a security request when the diagnostic intent belongs to the set of diagnostic information tags of the initiator; and determining the security type of the first diagnostic request as a dangerous request when the diagnostic intent does not belong to the set of diagnostic information tags of the initiator.

[0052] The set of diagnostic information tags of the initiator of the first diagnostic request can be denoted as C(p). When the diagnostic intent C(m) of the first diagnostic request belongs to C(p), the security level S(p) of the first diagnostic request can be set to 1. When the security level S(p) of the first diagnostic request is 1, the security type of the first diagnostic request is a security request.

[0053] When the diagnostic intent C(m) of the first diagnostic request does not belong to C(p), the security level S(p) of the first diagnostic request can be set to 1. When the security level S(p) of the first diagnostic request is 1, the security type of the first diagnostic request is a dangerous request.

[0054] For example, if the set C(p) of diagnostic information tags of the initiator of the first diagnostic request contains intent A, and the diagnostic intent C(m) of the first diagnostic request is intent A, then since C(p) contains C(m), the security level S(p) of the first diagnostic request can be set to 1. If the diagnostic intent C(m) of the first diagnostic request is intent B, then since C(p) does not contain C(m), the security level S(p) of the first diagnostic request can be set to 0.

[0055] As can be seen, the embodiments of this application can determine the security type of the first diagnostic request more accurately based on the relationship between the diagnostic intent of the first diagnostic request and the set of diagnostic information tags of the initiator, thereby facilitating the accurate protection processing of the first diagnostic request based on its security type.

[0056] Step 104: Protect the first diagnostic request according to the security type and diagnostic intent.

[0057] In some embodiments of this application, when the security type of the first diagnostic request is a dangerous request, the first diagnostic request can be protected according to a preset protection handling method for dangerous requests. When the security type of the first diagnostic request is a safe request, the protection handling method for the first diagnostic request can be determined according to the diagnostic intent.

[0058] In some embodiments, the process of protecting the first diagnostic request according to the security type and the diagnostic intent includes: when the security type of the first diagnostic request is a dangerous request, sending the first diagnostic request to a diagnostic request garbage resource pool, the diagnostic request garbage resource pool being used to generate notification information for processing the first diagnostic request; when the security type of the first diagnostic request is a safe request, determining a security value representing the security level of the first diagnostic request according to the security type and diagnostic intent of the first diagnostic request; and protecting the first diagnostic request according to the relationship between the security value and the security threshold value.

[0059] Here, the diagnostic request garbage resource pool includes a resource pool and a notification module. The resource pool stores diagnostic requests, and the notification module generates notification information for processing the first diagnostic request. This prompts the diagnostic request handler to perform subsequent processing on the first diagnostic request that enters the diagnostic request garbage resource pool. The security threshold can be set based on experience or based on pre-collected sample data about diagnostic requests.

[0060] It can be seen that when the security type of the first diagnostic request is a dangerous request, it can be considered that the first diagnostic request is very likely to have a dangerous intent. At this time, by sending the first diagnostic request to the diagnostic request garbage resource pool and generating a notification message for processing the first diagnostic request, the security protection of the first diagnostic request can be effectively achieved. When the security type of the first diagnostic request is a safe request, the security value representing the security level of the first diagnostic request can be determined more accurately according to the security type and diagnostic intent of the first diagnostic request. Based on this, the security protection processing of the first diagnostic request can be effectively carried out according to the relationship between the security value and the security threshold value.

[0061] In practical applications, steps 101 to 104 can be implemented based on a processor, which can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor.

[0062] As can be seen, when the security type of the first diagnostic request is a security request, the profile of the initiator of the first diagnostic request and the diagnostic intent of the first diagnostic request can be introduced. By judging whether the profile of the initiator of the first diagnostic request matches the diagnostic intent, the security type of the first diagnostic request can be re-determined. That is, the embodiments of this application can more accurately determine the security type of the first diagnostic request based on the profile of the initiator of the first diagnostic request. Furthermore, based on the security type and diagnostic intent of the first diagnostic request, the first diagnostic request can be protected more effectively, which is conducive to improving the security of diagnosing digital information.

[0063] In some embodiments of this application, the profile of the initiator of the first diagnostic request also includes the reputation value of the initiator of the first diagnostic request, which represents the proportion of security requests among the diagnostic requests initiated by the initiator of the first diagnostic request.

[0064] The reputation value of the initiator of the first diagnostic request can be denoted as C(r), with an initial value of 0. After the first diagnostic request is initiated, the ratio of the number of security requests to the total number of diagnostic requests initiated by the initiator can be determined, and this ratio is used as the reputation value C(r) of the initiator. For example, upon receiving the first diagnostic request, the type of the diagnostic request can be determined first. If the security type of the first diagnostic request is a dangerous request, the reputation value of the initiator can be reduced according to the calculation method of the reputation value C(r). If the security type of the first diagnostic request is a security request, step 102 is executed. After determining whether the profile of the initiator of the first diagnostic request matches the diagnostic intent, the reputation value of the initiator of the first diagnostic request can be calculated based on the redefined security type of the first diagnostic request and the calculation method of the reputation value C(r).

[0065] Accordingly, the process of determining a security value representing the security level of the first diagnostic request based on the security type and diagnostic intent of the first diagnostic request may include: determining a security value based on the security type, diagnostic intent, and reputation value of the initiator of the first diagnostic request, wherein the security value is positively correlated with the reputation value of the initiator.

[0066] The security value can be denoted as C(s). For example, the security value C(s) is proportional to the reputation value C(r) of the initiator. In some embodiments, the security level S(p) of the first diagnostic request can be determined based on the security type of the first diagnostic request. When the security type of the first diagnostic request is a secure request, the security level S(p) can be set to 1; when the security type of the first diagnostic request is a dangerous request, the security level S(p) can be set to 0. For example, the security value is proportional to the security level S(p) of the first diagnostic request; therefore, when the security type of the first diagnostic request is a dangerous request, the security value C(s) equals 0.

[0067] As can be seen, the embodiments of this application can reasonably determine the security value used to represent the security level of the first diagnostic request based on a comprehensive consideration of the security type of the first diagnostic request, the diagnostic intent, and the reputation value of the initiator.

[0068] In some embodiments of this application, after determining the reputation value of the initiator, the method further includes: determining a security threshold value, wherein the security threshold value is positively correlated with the reputation value of the initiator of the first diagnostic request and negatively correlated with the sum of the reputation values ​​of the received diagnostic requests.

[0069] For example, the security threshold is directly proportional to the reputation value of the initiator of the first diagnostic request and inversely proportional to the sum of the reputation values ​​of the received diagnostic requests. The security threshold can be denoted as S(z), and the reputation value of the i-th initiator among all the initiators of the received diagnostic requests can be denoted as C(ri). The security threshold S(z) can then be calculated according to formula (1).

[0070] S(z)=C(r) / ∑(C(ri) / M) (1)

[0071] Where M is the number of initiators of all received diagnostic requests.

[0072] In some embodiments of this application, the process of determining a security value representing the security level of the first diagnostic request based on the security type and diagnostic intent of the first diagnostic request includes: determining an intent behavior classification value based on the degree of danger of the diagnostic intent, wherein the intent behavior classification value is positively correlated with the degree of danger; and determining a security value based on the security type and intent behavior classification value of the first diagnostic request, wherein the security value is negatively correlated with the intent behavior classification value.

[0073] The degree of danger of a diagnostic intent can be denoted as S(b), which can be determined based on a pre-constructed list of intent danger levels, including the degree of danger corresponding to various intents. The intent behavior classification value can be denoted as A(s), and for example, the safety value C(s) is inversely proportional to the intent behavior classification value A(s).

[0074] It can be seen that the higher the degree of danger of the diagnostic intent, the larger the classification value of the intended behavior and the smaller the safety value; conversely, the lower the degree of danger of the diagnostic intent, the larger the safety value. Therefore, the safety value can be determined relatively accurately based on the degree of danger of the diagnostic intent.

[0075] In some embodiments of this application, the process of determining the intention behavior classification value based on the degree of danger of the diagnostic intention includes: determining the intention behavior classification value based on the degree of danger of the diagnostic intention and the sensitivity of the data carried in the first diagnostic request, wherein the intention behavior classification value is positively correlated with the sensitivity of the data carried in the first diagnostic request.

[0076] The sensitivity of the data carried in the first diagnostic request can be denoted as S(a). For example, S(a) can be determined based on a pre-constructed sensitive data classification and grading list, which includes the sensitivity of various types of data.

[0077] In this embodiment of the application, the identified diagnostic intent can be classified and assigned a value by aggregation analysis to obtain the intent behavior classification value A(s). For example, the intent behavior classification value A(s) can be calculated according to formula (2).

[0078] A(s)=log(S(a)*S(b)) (2)

[0079] For example, when the diagnostic intent of the first diagnostic request includes multiple intents, the intent behavior classification value A(s) of the diagnostic intent of the first diagnostic request can be determined according to the intent behavior classification value corresponding to each of the multiple intents of the first diagnostic request; for example, the intent behavior classification value A(s) of the diagnostic intent of the first diagnostic request can be calculated according to formula (3).

[0080]

[0081] Where A(si) represents the intent behavior classification value corresponding to the i-th intent of the first diagnostic request, and N is the number of intents in the diagnostic intent of the first diagnostic request.

[0082] It can be seen that since the intention behavior classification value is positively correlated with the sensitivity of the data carried in the first diagnostic request, and the security value is negatively correlated with the intention behavior classification value, the security value is negatively correlated with the sensitivity of the data carried in the first diagnostic request. Therefore, the security value can be reasonably determined based on the sensitivity of the data carried in the first diagnostic request.

[0083] In some embodiments of this application, the process of determining a security value based on the security type and intent behavior classification value of the first diagnostic request includes: determining a security value based on the security type, intent behavior classification value, and data sensitivity of the initiator of the first diagnostic request, wherein the security value is negatively correlated with the data sensitivity of the initiator of the first diagnostic request.

[0084] The data sensitivity of the initiator of the first diagnostic request can be denoted as S(d). The data sensitivity S(d) of the initiator's query and use of data can be preset in the knowledge base. For example, the security value is inversely proportional to the data sensitivity of the initiator of the first diagnostic request.

[0085] For example, the safety value C(s) can be calculated according to formula (4).

[0086] C(s)=S(p)*C(r) / (A(s)*S(d)) (4)

[0087] In some embodiments of this application, the process of protecting the first diagnostic request based on the relationship between the security value and the security threshold includes: when the security value is less than the security threshold, the first diagnostic request is protected through the DMZ; when the security value is greater than or equal to the security threshold, the first diagnostic request is sent to a first server, and the first server is used to process the first diagnostic request according to a predetermined processing logic.

[0088] A DMZ (Dedicated Domain Name System) is a buffer zone between a secure and insecure system, established to address the issue of external network users being unable to access internal network servers after a firewall is installed. This buffer zone is located within a small network area between the enterprise's internal and external networks. Server facilities that must be publicly accessible, such as corporate web servers, file transfer protocol (FTP) servers, and forums, can be placed within this small network area. Furthermore, setting up a DMZ more effectively protects the internal network. This network deployment adds an extra layer of protection against attackers from the external network compared to a typical firewall solution.

[0089] The DMZ is responsible for processing diagnostic requests with unclear intent or those that cannot be categorized. For example, the DMZ consists of a security sandbox and a notification module. The notification module in the DMZ notifies the diagnostic request handler to process the diagnostic requests entering the DMZ. Specifically, the security sandbox, as a virtualized execution environment that does not interact with the outside world, combined with honeypot technology, can form a diagnostic request execution environment. When a user opens a pending diagnostic request and its attachments in the DMZ, the address returned by the link in the diagnostic request is not the user's actual Internet Protocol (IP) address, but rather a honeypot address proxied through the network.

[0090] For example, the received diagnostic request is a diagnostic request sent in the form of an email. Accordingly, the first server is a mail server, which can process the first diagnostic request according to a predetermined email processing logic.

[0091] As can be seen, since the security value represents the security level of the first diagnostic request, when the security value is less than the security threshold, the security level of the first diagnostic request can be considered low. In this case, by protecting the first diagnostic request through the DMZ, the risk of processing the diagnostic request can be effectively reduced. When the security value is greater than or equal to the security threshold, the security level of the first diagnostic request can be considered high. In this case, by sending the first diagnostic request to the first server, it is convenient to process the first diagnostic request according to the predetermined processing logic.

[0092] In some embodiments of this application, after the first diagnostic request is protected by the DMZ, the method further includes: forwarding the first diagnostic request to the diagnostic request garbage resource pool or the first server according to the protection processing result of the first diagnostic request in the DMZ.

[0093] Here, the result of the protection processing of the first diagnostic request in the DMZ can be either that an attack occurred or no attack occurred. If the protection processing result is that an attack occurred, the first diagnostic request can be reclassified as a dangerous request, and in this case, the first diagnostic request can be forwarded to the diagnostic request garbage resource pool. If the protection processing result is that no attack occurred, the first diagnostic request can be forwarded to the first server.

[0094] In some embodiments of this application, after sending the first diagnostic request to the first server, the method further includes: adding a diagnostic intent to the set of diagnostic information tags of the initiator.

[0095] Before the initiator of the first diagnostic request initiates any diagnostic request, the set C(p) of diagnostic information tags of the initiator of the first diagnostic request is an empty set. After the first diagnostic request is sent to the first server, the diagnostic intent C(m) of the first diagnostic request can be added to C(p).

[0096] It can be seen that when the first diagnostic request is sent to the first server, it means that the security value is greater than or equal to the security threshold value, and the first diagnostic request can be considered a security request. In this case, by adding diagnostic intent to the set of diagnostic information tags of the initiator of the first diagnostic request, the profile of the initiator of the first diagnostic request can be updated in a timely manner.

[0097] The diagnostic request processing method in this application embodiment can be implemented through a diagnostic request system, as described above. Figure 2 The diagnostic request system includes an intent recognition module 201, a diagnostic filtering module 202, a DMZ 203, a knowledge base 204, a mail server 205, and a diagnostic request garbage resource pool 206.

[0098] Reference Figure 3 The intent recognition module 201 consists of a security diagnostic scanning module 2011 and an intent recognition large model 2012. The intent recognition module 201 is responsible for analyzing and recognizing the intent of diagnostic requests, which can be achieved using an enhanced LLM algorithm. The enhanced LLM algorithm, by introducing SME profile parameters on top of the original LLM algorithm, performs a security scan on the enterprise's diagnostic requests. It provides security protection for the enterprise's diagnostic requests from the perspectives of diagnostic intent, diagnostic initiator information tags, initiator reputation value, risk level, and data sensitivity.

[0099] The security diagnostic scanning module 2011 can use security tools to perform security scans on diagnostic requests. When the security type of a diagnostic request is a dangerous request, it can send the diagnostic request to the diagnostic filtering module 202 and lower the reputation value of the initiator of the diagnostic request. When the security type of a diagnostic request is a safe request, the intent recognition big model 2012 can identify the diagnostic intent, annotate the diagnostic intent on the diagnostic request, and then send it to the diagnostic filtering module 202 for processing.

[0100] The diagnostic filtering module 202 can sort diagnostic requests according to an intent sorting algorithm and send them to the mail server 205, DMZ 203, or diagnostic request garbage pool 206 based on the security value of the diagnostic request. Here, the intent sorting algorithm calculates the security value of the diagnostic request based on the aforementioned information and sends the request accordingly. For example, when the security value is 0, the diagnostic request is sent to the diagnostic request garbage pool 206; when the security value is greater than or equal to a security threshold, the diagnostic request is sent to the mail server; and when the security value is greater than 0 and less than the security threshold, the diagnostic request is sent to the DMZ. After the diagnostic request is processed in the DMZ, the user can manually forward the diagnostic request to the mail server 205 or the diagnostic request garbage pool 206 via the diagnostic filtering module 202. If no user action is received within a set time after the diagnostic request is processed in the DMZ, the diagnostic request is automatically forwarded to the diagnostic request garbage pool 206 via the diagnostic filtering module 202.

[0101] The diagnostic request garbage resource pool 206 consists of two parts: a resource pool and a notification module. The resource pool stores diagnostic requests identified as having dangerous intent or garbage diagnostic requests identified by the diagnostic request handler, forming a diagnostic request list. The notification module notifies the diagnostic request handler that a diagnostic request has entered the garbage resource pool and synchronously records garbage diagnostic requests identified by the handler and diagnostic requests misjudged as having dangerous intent in the knowledge base. When diagnostic requests in the diagnostic request garbage resource pool 206 meet certain time conditions or resource pool storage conditions, an automatic cleanup mechanism is triggered; for example, if the storage duration of a diagnostic request in the diagnostic request garbage resource pool 206 exceeds one month, or if the amount of diagnostic request data stored in the resource pool exceeds two-thirds of the total capacity of the resource pool, the automatic cleanup mechanism for diagnostic requests in the resource pool is triggered.

[0102] Knowledge Base 204 stores data such as spam diagnostic request records identified by the diagnostic request handler, diagnostic request records misjudged as malicious intent, and information on malicious intent diagnostic requests. The knowledge base serves as the training dataset for the large-scale intent recognition model and is periodically trained. Simultaneously, through external data import, it is updated in a timely manner to reflect the profiles of diagnostic request initiators and to learn about new attack methods, ensuring the accuracy of intent recognition.

[0103] The diagnostic request system is a crucial component of industrial digital transformation. It is responsible for diagnosing an enterprise's current level of IT infrastructure and whether it meets the requirements for digital transformation. The system then pushes the basic diagnostic results to enterprise users. The security of the diagnostic request system also needs to be considered holistically, hence its high relevance. The diagnostic request system can be applied to products related to light manufacturing to enhance product security.

[0104] The following example of an application scenario will further illustrate the solution of this application.

[0105] In this application scenario embodiment, firstly, an intent recognition large model 2012 is trained based on existing large models using methods such as knowledge distillation, and then connected to a knowledge base. The intent recognition large model 2012 uses the initial data from the knowledge base as its training dataset and, according to the decision tree model algorithm, forms an initial intent recognition module (containing a list of intent risk levels). It is then connected to the diagnostic filtering module 202, forming a one-way transmission. A security sandbox is deployed to form a DMZ 203, and connected to the diagnostic filtering module 202. A diagnostic request garbage resource pool is deployed, setting cleanup conditions such as periodic time intervals or memory usage percentages, and connected to the diagnostic filtering module 206. Finally, the diagnostic filtering module 202 connects to the mail server 206, forming the overall system.

[0106] The system obtains information on the sensitive job level and sensitive data classification and grading list input by the system administrator. The diagnostic screening module 202 generates an intentional risk level list based on the existing knowledge base data and diagnoses the initial information such as the sensitivity level of the request handler.

[0107] When the intent recognition module 201 receives a diagnostic request, it first performs a security scan on the attachments, links, and other content of the diagnostic request. If a security risk is found, it directly marks the request with a dangerous intent label and sends it to the diagnostic screening module 202. If no security risk is found, it performs intent recognition on the text, images, videos, and other content of the diagnostic request using an enhanced LLM algorithm, and marks the diagnostic request with intent labels such as dangerous intent or data collection intent, and then sends it along with the diagnostic request to the diagnostic screening module 202.

[0108] After receiving the diagnostic request and diagnostic intent identifier sent by the intent recognition module 201, the diagnostic screening module 202 sends the diagnostic request to the mail server 205, DMZ 203 or diagnostic request garbage resource pool 206 according to the intent sorting algorithm.

[0109] If a diagnostic request is sent to DMZ 203 or the diagnostic request garbage resource pool 206, the notification module of DMZ 203 or the diagnostic request garbage resource pool 206 generates a notification message to inform the original diagnostic request handler. If processing is required, the diagnostic request handler will proceed to the corresponding module for processing. If a diagnostic request is recovered from a garbage diagnostic request, the record will be synchronized to the knowledge base via the notification module. A random forest algorithm is used to form a random seed based on the hash value of the knowledge base and the remaining space percentage of the deployed host. The intent recognition module randomly selects samples for training, thereby improving the accuracy of intent judgment.

[0110] As can be seen in the above application scenario embodiments, security scanning can be performed on the initiated digital transformation diagnostic requests, and security protection can be achieved for the diagnostic requests from the perspectives of diagnostic intent, diagnostic initiator information tags, initiator reputation value, degree of danger, and data sensitivity.

[0111] This application's embodiments achieve efficient diagnostic sorting through an enhanced LLM algorithm and an intent sorting algorithm. Specifically, based on the LLM algorithm proposed in related technologies, an initiator profile parameter is introduced. When a diagnostic request is received and sent to the mail server, a security tool is used to perform a security scan on the diagnostic request, calculate the initiator's reputation value, identify the diagnostic intent through an intent recognition model, and match the initiator profile parameter with the diagnostic intent to redetermine the security type of the diagnostic request. Furthermore, the security value C(s) of the diagnostic request can be determined based on the security level of the diagnostic request, the sensitivity of the data carried in the diagnostic request, the danger level of the diagnostic intent, and the data sensitivity of the initiator of the diagnostic request, using an intent sorting algorithm, thereby achieving automatic sorting of diagnostic requests based on diagnostic intent.

[0112] Phishing attacks based on diagnostic requests using digital information are gradually becoming a key focus of security protection. This application's embodiments can use a large model to identify the intent of diagnostic requests, thereby addressing phishing attacks based on digital information-based diagnostic requests. Furthermore, based on the LLM algorithm proposed in related technologies, this application's embodiments introduce initiator profile parameters to form an enhanced LLM algorithm and intent sorting algorithm, achieving precise control over diagnostic intent and, to a certain extent, avoiding misjudgments of diagnostic requests based solely on text content in related technologies. In summary, the technical solution adopted in this application's embodiments can, to a certain extent, solve the problem of low security when diagnosing digital information; therefore, the technical solution of this application's embodiments can be widely applied.

[0113] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0114] Figure 4 This is a schematic diagram of the structure of a diagnostic request processing device according to an embodiment of this application, as shown below. Figure 4 As shown, the device includes:

[0115] Receiver module 401 is configured to receive at least one diagnostic request for digitized information;

[0116] The first processing module 402 is configured to, when the security type of the first diagnostic request in the at least one diagnostic request is a security request, identify the diagnostic intent of the diagnostic request through an intent recognition big model, and determine whether the profile of the initiator of the first diagnostic request matches the diagnostic intent, and obtain a judgment result.

[0117] The second processing module 403 is used to redetermine the security type of the first diagnostic request based on the judgment result; and to perform protective processing on the first diagnostic request based on the security type and the diagnostic intent.

[0118] In some embodiments, the profile of the initiator includes at least a set of diagnostic information tags of the initiator, which are determined based on the diagnostic intent of the diagnostic request initiated by the initiator.

[0119] The second processing module 403 is configured to re-determine the security type of the first diagnostic request based on the judgment result, including:

[0120] If the diagnostic intent belongs to the set of diagnostic information tags of the initiator, the security type of the first diagnostic request is determined to be a security request; if the diagnostic intent does not belong to the set of diagnostic information tags of the initiator, the security type of the first diagnostic request is determined to be a dangerous request.

[0121] In some embodiments, the second processing module 403 is configured to perform protection processing on the first diagnostic request according to the security type and the diagnostic intent, including:

[0122] When the security type of the first diagnostic request is a dangerous request, the first diagnostic request is sent to the diagnostic request garbage resource pool, which is used to generate notification information for processing the first diagnostic request.

[0123] When the security type of the first diagnostic request is a security request, a security value representing the security level of the first diagnostic request is determined based on the security type of the first diagnostic request and the diagnostic intent; and the first diagnostic request is protected based on the relationship between the security value and the security threshold value.

[0124] In some embodiments, the profile of the initiator further includes the reputation value of the initiator; the second processing module 403 is configured to determine a security value representing the security level of the first diagnostic request based on the security type of the first diagnostic request and the diagnostic intent, including:

[0125] The security value is determined based on the security type of the first diagnostic request, the diagnostic intent, and the reputation value of the initiator, and the security value is positively correlated with the reputation value of the initiator.

[0126] In some embodiments, the second processing module 403 is further configured to determine the security threshold value after determining the reputation value of the initiator, wherein the security threshold value is positively correlated with the reputation value of the initiator of the first diagnostic request and negatively correlated with the sum of the reputation values ​​of the initiators of all received diagnostic requests.

[0127] In some embodiments, the second processing module 403 is configured to determine a security value representing the security level of the first diagnostic request based on the security type of the first diagnostic request and the diagnostic intent, including:

[0128] Based on the degree of danger of the diagnostic intent, a classification value for the intent behavior is determined, and the classification value for the intent behavior is positively correlated with the degree of danger;

[0129] The security value is determined based on the security type of the first diagnostic request and the intent behavior classification value, wherein the security value is negatively correlated with the intent behavior classification value.

[0130] In some embodiments, the second processing module 403 is configured to determine the intention behavior classification value based on the degree of danger of the diagnostic intention, including:

[0131] The intention behavior classification value is determined based on the degree of danger of the diagnostic intent and the sensitivity of the data carried in the first diagnostic request, and the intention behavior classification value is positively correlated with the sensitivity of the data carried in the first diagnostic request.

[0132] In some embodiments, the second processing module 403 is configured to determine the security value based on the security type of the first diagnostic request and the intent behavior classification value, including:

[0133] The security value is determined based on the security type of the first diagnostic request, the intent behavior classification value, and the data sensitivity of the initiator of the first diagnostic request. The security value is negatively correlated with the data sensitivity of the initiator of the first diagnostic request.

[0134] The second processing module 403 is used to perform protective processing on the first diagnostic request based on the relationship between the security value and the security threshold value, including:

[0135] If the safety value is less than the safety threshold, the first diagnostic request will be protected by the DMZ (Discovery Zone).

[0136] If the security value is greater than or equal to the security threshold, the first diagnostic request is sent to the first server, which processes the first diagnostic request according to a predetermined processing logic.

[0137] In some embodiments, the second processing module 403 is further configured to, after the first diagnostic request is protected by the DMZ, the method further includes: forwarding the first diagnostic request to the diagnostic request garbage resource pool or the first server according to the protection processing result of the first diagnostic request in the DMZ.

[0138] In practical applications, the receiving module 401, the first processing module 401, and the second processing module 403 can be implemented based on a processor.

[0139] It should be noted that the description of the above device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0140] It should be noted that, in the embodiments of this application, if the above methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a terminal, server, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0141] Correspondingly, this application embodiment further provides a computer program product, the computer program product including computer executable instructions, which are used to implement any of the diagnostic request processing methods provided in this application embodiment.

[0142] Accordingly, this application embodiment further provides a computer storage medium storing computer-executable instructions, which are used to implement any of the diagnostic request processing methods provided in the above embodiments.

[0143] This application also provides an electronic device. Figure 5 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application, such as... Figure 5 As shown, the electronic device 50 may include:

[0144] Memory 501 is used to store executable instructions;

[0145] The processor 502 is configured to implement any of the diagnostic request processing methods described above when executing executable instructions stored in the memory 501.

[0146] The processor 502 mentioned above can be at least one of ASIC, DSP, DSPD, PLD, FPGA, CPU, controller, microcontroller, and microprocessor.

[0147] The aforementioned computer-readable storage medium and memory 501 may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; or it may be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0148] In some embodiments, the functions or modules of the apparatus provided in this application can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0149] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0150] The methods disclosed in the various method embodiments provided in this application can be arbitrarily combined to obtain new method embodiments without conflict.

[0151] The features disclosed in the various product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0152] The features disclosed in the various method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0153] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0154] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims. All of these forms are within the protection scope of this application.

Claims

1. A method for processing diagnostic requests, characterized in that, The method includes: Receive at least one diagnostic request for digital information; When the security type of the first diagnostic request in the at least one diagnostic request is a security request, the diagnostic intent of the first diagnostic request is identified by the intent recognition big model, and it is determined whether the profile of the initiator of the first diagnostic request matches the diagnostic intent to obtain a judgment result. The security type of the first diagnostic request is re-determined based on the judgment result; The first diagnostic request is protected according to the security type and the diagnostic intent.

2. The method according to claim 1, characterized in that, The profile of the initiator includes at least a set of diagnostic information tags of the initiator, which are determined based on the diagnostic intent of the diagnostic request initiated by the initiator. The step of re-determining the security type of the first diagnostic request based on the judgment result includes: If the diagnostic intent belongs to the set of diagnostic information tags of the initiator, the security type of the first diagnostic request is determined to be a security request; If the diagnostic intent does not belong to the set of diagnostic information tags of the initiator, the security type of the first diagnostic request is determined to be a dangerous request.

3. The method according to claim 2, characterized in that, The step of protecting the first diagnostic request based on the security type and the diagnostic intent includes: When the security type of the first diagnostic request is a dangerous request, the first diagnostic request is sent to the diagnostic request garbage resource pool, which is used to generate notification information for processing the first diagnostic request. When the security type of the first diagnostic request is a security request, a security value representing the security level of the first diagnostic request is determined based on the security type of the first diagnostic request and the diagnostic intent; and the first diagnostic request is protected based on the relationship between the security value and the security threshold value.

4. The method according to claim 3, characterized in that, The profile of the initiator also includes the initiator's reputation score; Determining a security value representing the security level of the first diagnostic request based on the security type of the first diagnostic request and the diagnostic intent includes: The security value is determined based on the security type of the first diagnostic request, the diagnostic intent, and the reputation value of the initiator, and the security value is positively correlated with the reputation value of the initiator.

5. The method according to claim 4, characterized in that, After determining the reputation value of the initiator, the method further includes: determining the security threshold value, which is positively correlated with the reputation value of the initiator of the first diagnostic request and negatively correlated with the sum of the reputation values ​​of the initiators of all received diagnostic requests.

6. The method according to claim 3, characterized in that, Determining a security value representing the security level of the first diagnostic request based on the security type of the first diagnostic request and the diagnostic intent includes: Based on the degree of danger of the diagnostic intent, the intention behavior classification value is determined, and the intention behavior classification value is positively correlated with the degree of danger; The security value is determined based on the security type of the first diagnostic request and the intent behavior classification value, wherein the security value is negatively correlated with the intent behavior classification value.

7. The method according to claim 6, characterized in that, The process of determining the classification value of the intentional behavior based on the degree of danger of the diagnostic intention includes: The intention behavior classification value is determined based on the degree of danger of the diagnostic intent and the sensitivity of the data carried in the first diagnostic request, and the intention behavior classification value is positively correlated with the sensitivity of the data carried in the first diagnostic request.

8. The method according to claim 6, characterized in that, The step of determining the security value based on the security type of the first diagnostic request and the intent behavior classification value includes: The security value is determined based on the security type of the first diagnostic request, the intent behavior classification value, and the data sensitivity of the initiator of the first diagnostic request. The security value is negatively correlated with the data sensitivity of the initiator of the first diagnostic request.

9. The method according to any one of claims 3 to 8, characterized in that, The step of protecting the first diagnostic request based on the relationship between the security value and the security threshold includes: If the safety value is less than the safety threshold, the first diagnostic request will be protected by the DMZ (Discovery Zone). If the security value is greater than or equal to the security threshold, the first diagnostic request is sent to the first server, which processes the first diagnostic request according to a predetermined processing logic.

10. The method according to claim 9, characterized in that, After the first diagnostic request is protected by the DMZ, the method further includes: forwarding the first diagnostic request to the diagnostic request garbage resource pool or the first server according to the protection processing result of the first diagnostic request in the DMZ.

11. The method according to claim 9, characterized in that, After sending the first diagnostic request to the first server, the method further includes adding the diagnostic intent to the set of diagnostic information tags of the initiator.

12. A diagnostic request processing apparatus, characterized in that, The device includes: A receiving module is used to receive at least one diagnostic request for digitized information; The first processing module is configured to, when the security type of the first diagnostic request in the at least one diagnostic request is a security request, identify the diagnostic intent of the diagnostic request through an intent recognition big model, and determine whether the profile of the initiator of the first diagnostic request matches the diagnostic intent, and obtain a judgment result. The second processing module is used to redetermine the security type of the first diagnostic request based on the judgment result; and to perform protective processing on the first diagnostic request based on the security type and the diagnostic intent.

13. An electronic device, characterized in that, The electronic device includes a processor and a memory for storing computer programs capable of running on the processor; wherein, The processor is used to run the computer program to perform the diagnostic request processing method according to any one of claims 1 to 11.

14. A computer storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the method for processing diagnostic requests as described in any one of claims 1 to 11.

15. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the diagnostic request processing method according to any one of claims 1 to 11.

Images