Enterprise-level multi-source abnormal behavior monitoring method and system

Abstract

The invention discloses an enterprise-level multi-source abnormal behavior monitoring method and system, and particularly relates to the field of enterprise-level multi-source abnormal behavior monitoring, and the method comprises the steps: an end-side device executes a process structure analysis operation, and executes an expected behavior set construction operation according to a function module, an interface calling relation and a process rule deployed by the end-side device; generating an end-side expected behavior set; and the end-side equipment executes matching calculation operation on the actual behavior events collected in the operation cycle, and executes item-by-item comparison operation on the actual behavior events and the end-side expected behavior set. An expected behavior sequence composed of a process node, a function module and interface calling is constructed on an end side, double-layer comparison of node coverage and interface coverage is performed on an actual behavior event in an operation cycle, and cross-end-side missing alignment, path expansion and link judgment calculation of a cloud end are combined, so that a real behavior event is obtained. And computable recognition of key behaviors which should appear but are actually missing in the business process is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of enterprise-level multi-source abnormal behavior monitoring, and more particularly, to an enterprise-level multi-source abnormal behavior monitoring method and system. BACKGROUND

[0002] In the current enterprise-level multi-source monitoring system, the end-side device is usually responsible for collecting local logs, interface calls, operation records and various system behaviors, and continuously reporting these already-occurred events to the cloud in an end-cloud collaborative manner; the cloud then builds a behavior chain, judges the business process state, and performs risk analysis according to the reported events; but in many core business scenarios, the process itself is not composed of isolated events, but a group of key links with a certain sequence and fixed logical relationship, for example, after permission confirmation, audit records should usually appear, after cross-system operation, reconciliation actions should be triggered, and after sensitive operation, corresponding review processes are often generated; these process links form the basis of business integrity; The problem is that the existing end-cloud collaborative monitoring system strictly revolves around the actual behaviors: the end-side only reports the events that actually occur, and does not mark the steps that should normally appear in the process but do not appear in the running process; the cloud can only model and judge according to the received event set, and completely lacks the identification mechanism for missing links; when an attacker or an insider closes, bypasses or skips the key steps, so that these necessary business links no longer generate any data, the entire monitoring system cannot detect the existence of the anomaly, because the end-side does not record the missing, and the cloud does not have the ability to infer the missing; Under the architecture of end-cloud collaboration, this complete neglect of missing links forms a highly concealed risk area; the monitoring system can always see the behaviors that have occurred, while the parts of the process that are actually destroyed are in the links that have not occurred; this type of anomaly does not manifest as behavior surge, behavior deviation or behavior conflict, but as the disappearance of certain key actions in the process; therefore, it does not trigger the reporting logic of the end-side, nor does it leave a trace in the analysis model of the cloud; The core problem that can be finally derived is that the end-cloud collaborative monitoring system highly depends on the actual events in the technical design, but cannot identify the key behaviors in the business process that should have appeared but actually missed, resulting in the fact that the missing-type anomaly is naturally covered up in the entire monitoring link and is long-term invisible. SUMMARY

[0003] In order to overcome the above-mentioned defects of the prior art, embodiments of the present application provide an enterprise-level multi-source abnormal behavior monitoring method and system, which constructs an expected behavior sequence composed of process nodes, function modules and interface calls on the terminal side, and performs double-layer comparison of node coverage and interface coverage on actual behavior events in a running period, and further combines cross-terminal side missing alignment, path expansion and link determination calculation of the cloud end to achieve computable identification of key behaviors that should appear in the business process but are actually missing, so as to solve the problems raised in the above background art.

[0004] To achieve the above object, the present application provides the following technical scheme: an enterprise-level multi-source abnormal behavior monitoring method, comprising: S1, performing a process structure analysis operation by the terminal side device, and performing an expected behavior set construction operation according to the function modules, interface call relationships and process rules deployed by the terminal side device, to generate a terminal side expected behavior set; S2, performing a matching calculation operation by the terminal side device on actual behavior events collected in a running period, and performing a one-by-one comparison operation between the actual behavior events and the terminal side expected behavior set to identify target behaviors not covered by the actual behavior events, thereby generating a terminal side missing behavior set; S3, performing an end-cloud collaborative uploading operation by the terminal side device on the terminal side missing behavior set and the actual behavior events to form a terminal side expected behavior state input submitted to the cloud end; S4, performing a cross-node alignment calculation operation by the monitoring platform of the cloud end on a plurality of terminal side missing behavior sets, and performing a missing behavior mapping operation according to the dependent links existing in the process structure to generate a cross-node process missing link; S5, performing a process integrity judgment operation by the monitoring platform of the cloud end according to the cross-node process missing link, and outputting a missing type abnormal behavior judgment result when any process is in a missing state in the associated nodes in the cloud end.

[0005] In a preferred embodiment, in S1, comprising: S1-1, performing a reading operation by the terminal side device on process structure definition data for describing process nodes and their associated relationships, and performing a process node analysis operation on each process node read, and sequentially writing the analyzed process node identifier, function module identifier, and predecessor process node identifier and successor process node identifier into a process node set and a process transfer relationship set; S1-2, performing an interface relationship calculation operation by the terminal side device on each process node in the process node set according to the process node identifier and the function module identifier in the process node set, and the interface call relationship configured by the terminal side device, determining the interface call list corresponding to the process node, and writing the process node identifier, function module identifier and interface call list into a first behavior element set according to a unified structure; S1-3, performing, by the end-side device, a sequential computation operation on the set of flow transition relations according to the flow rules, performing a sorting operation on the predecessor flow node identifiers and the successor flow node identifiers according to the flow rules, and generating a flow step sequence; S1-4, performing, by the end-side device, an element sequence mapping computation operation on the first set of behavior elements according to the flow step sequence, sequentially matching the corresponding behavior elements according to the flow node identifiers in the flow step sequence, and writing the matched behavior elements in order into the end-side expected behavior set.

[0006] In a preferred embodiment, S2 includes: S2-1, performing, by the end-side device, an event analysis operation on each actual behavior event collected in the running period: sequentially resolving the flow node identifier, the event interface identifier and the event timestamp in each actual behavior event, and writing the resolved flow node identifier into the event node identifier set, and writing the resolved flow node identifier and the corresponding event interface identifier into the event interface mapping set according to the corresponding relationship; S2-2, performing, by the end-side device, a matching computation operation on the event node identifier set and the end-side expected behavior set: performing a first matching determination operation on each expected behavior record in the end-side expected behavior set with the flow node identifier as the first matching key, marking the expected behavior record as a node uncovered state when there is no flow node identifier consistent with the flow node identifier in the event node identifier set, otherwise marking the expected behavior record as a node covered state; at the same time, for the expected behavior record marked as a node covered state, performing an interface relationship comparison operation by the end-side device with the interface call list in the expected behavior record as the second matching key and the event interface identifier set corresponding to the flow node identifier in the event interface mapping set as the second matching object, marking the expected behavior record as an interface uncovered state when the intersection result of the interface relationship comparison operation is empty, otherwise marking the expected behavior record as an interface covered state; S2-3, performing, by the end-side device, a missing behavior record writing operation on the expected behavior records in the end-side expected behavior set marked as a node uncovered state or an interface uncovered state, writing the corresponding flow node identifier, function module identifier and interface call list into the end-side missing behavior set according to a unified structure; at the same time, for the expected behavior record marked as a node covered state and marked as an interface covered state, keeping its covered state by the end-side device to form an end-side covered behavior set, so that the end-side missing behavior set only records the target behavior that is not covered by any actual behavior event in the running period.

[0007] In a preferred embodiment, S3 includes: S3-1, the end-side device performs a missing behavior traversal operation on the end-side missing behavior set, reads the flow node identifier, function module identifier and interface call list in each missing behavior record, and performs an event correlation retrieval operation on the actual behavior events collected in the running period, so that the event interface identifier and event timestamp of the actual behavior events that can be consistent with the flow node identifier in the event node identifier set are written into the expected behavior state record in a corresponding relationship; S3-2, the end-side device performs a structure integration operation on all expected behavior state records, writes the flow node identifier, function module identifier, interface call list, event interface identifier and event timestamp in each expected behavior state record into the end-side expected behavior state input set in a unified structure; S3-3, the end-side device performs an end-cloud collaborative uploading operation on the end-side expected behavior state input set, transmits the end-side expected behavior state input set to the cloud monitoring platform in the form of a data packet, so that the cloud monitoring platform obtains the input for subsequent calculation.

[0008] In a preferred embodiment, S4 includes: S4-1, the monitoring platform of the cloud performs a sequential reading operation on the end-side missing behavior set from multiple end-side devices, reads the flow node identifier, function module identifier and interface call list in each missing behavior record, and records the end-side device identifier to which the missing behavior record belongs, writes the missing situation of the same flow node identifier under different end-side device identifiers into the cloud missing behavior reference table in a corresponding relationship, so that the cloud missing behavior reference table records the missing situation of each end-side device according to the flow node identifier; S4-2, the monitoring platform of the cloud performs a cross-node alignment calculation operation on the cloud missing behavior reference table according to the flow node identifier, performs consistency judgment on the missing records of each flow node identifier under different end-side device identifiers; when a flow node identifier has missing records under two or more end-side device identifiers, the flow node identifier is marked as a consistent missing node; when any flow node identifier has a missing record only under one end-side device identifier, the monitoring platform of the cloud performs interface consistency determination on the interface call list of the flow node identifier under different end-side device identifiers, when the interface call in the interface call list does not appear under two or more end-side device identifiers, the flow node identifier is marked as an interface missing node; when the node consistency and the interface consistency are not met, the monitoring platform of the cloud keeps the inconsistent missing state of the flow node identifier as a termination condition for subsequent path calculation; S4-3, performing path expansion operation on the flow node identifier marked as consistent missing node or interface missing node according to the dependency relationship between the predecessor flow node identifier and the successor flow node identifier in the process structure, taking any marked flow node identifier as the expansion starting point, and performing progressive expansion to the predecessor flow node identifier and the successor flow node identifier thereof; when the flow node identifier obtained by the progressive expansion belongs to the consistent missing node or the interface missing node, continue to expand, and when the flow node identifier obtained by the progressive expansion belongs to the non-consistent missing state, stop expanding, thereby forming a plurality of missing path sequences composed of adjacent missing nodes.

[0009] In a preferred embodiment, in S4, further comprising: S4-4, performing path integration operation on the missing path sequence by the monitoring platform in the cloud, performing merging calculation on the missing path sequence in the process structure according to the arrangement order of the flow node identifier, and performing repeated record elimination operation and sequence verification operation on the sequence of the merged flow node identifier, to generate a cross-node process missing link composed of a plurality of continuous missing nodes, and write the cross-node process missing link into the cross-node process missing link set.

[0010] In a preferred embodiment, in S5, comprising: S5-1, performing process integrity judgment operation on the cross-node process missing link by the monitoring platform in the cloud: taking each flow node identifier in the cross-node process missing link as the judgment object, performing missing state reading operation on the missing state of the flow node identifier in the cross-node process missing link, and performing continuous missing comparison operation on the missing state and the missing state corresponding to the predecessor flow node identifier and the successor flow node identifier of the flow node identifier in the process structure, when the result of the continuous missing comparison operation shows that any flow node identifier presents continuous missing state in the predecessor direction or the successor direction, marking the flow node identifier as process missing node; S5-2, performing process missing node recording operation on the flow node identifier marked as process missing node by the monitoring platform in the cloud, writing the flow node identifier into the process missing node set, and performing condition determination operation on the record number of the process missing node set and the preset missing trigger condition, when the result of the condition determination operation meets the preset missing trigger condition, performing abnormal behavior output operation by the monitoring platform in the cloud, outputting the missing type abnormal behavior judgment result.

[0011] An enterprise-level multi-source abnormal behavior monitoring system, comprising a structure generation module, a missing identification module, a state uploading module, a link extraction module and an abnormal judgment module; The structure generation module is configured to perform a flow structure analysis operation by the end-side device, and perform a set of expected behavior construction operation according to a function module, an interface call relationship and a flow rule deployed by the end-side device, so as to generate a set of end-side expected behaviors; The missing recognition module is configured to perform a matching calculation operation on actual behavior events collected in a running period by the end-side device, and perform a one-by-one comparison operation between the actual behavior events and the set of end-side expected behaviors, so as to identify target behaviors not covered by the actual behavior events, thereby generating a set of end-side missing behaviors; The state uploading module is configured to perform an end-cloud collaborative uploading operation on the set of end-side missing behaviors and the actual behavior events by the end-side device, so as to form an end-side expected behavior state input submitted to the cloud; The link extraction module is configured to perform a cross-node alignment calculation operation on a plurality of sets of end-side missing behaviors by a monitoring platform of the cloud, and perform a missing behavior mapping operation according to a dependent link existing in the flow structure, so as to generate a cross-node flow missing link; The abnormality judgment module is configured to perform a flow integrity judgment operation according to the cross-node flow missing link by the monitoring platform of the cloud, and output a missing-type abnormal behavior judgment result when any flow is in a missing state in the associated node.

[0012] Technical effects and advantages of the present application: 1. The present application constructs a set of expected behaviors including flow nodes, function modules and interface calls on the end side, and performs a double-layer comparison of node coverage and interface coverage on actual behavior events in a running period, so that the monitoring system first obtains explicit recognition ability for key flow links that should appear but do not appear, thereby solving the problem that the end-cloud collaborative system cannot find missing-type abnormalities; 2. The present application integrates the missing behaviors recognized by the end side and the associated actual event information into a structured expected behavior state input and uploads it to the cloud, so that the cloud obtains a computable evidence chain about whether each flow node is covered, the reason for coverage and the interface triggering condition, realizes the penetration of missing behaviors from the end to the cloud, and avoids missing abnormalities due to the local perspective of the end side; 3. The present application constructs a cloud missing behavior reference table indexed by flow node identification in the cloud, and identifies flow nodes repeatedly missing across the end side through two-level judgment of node consistency and interface consistency, so that the system can extract stable missing features from multiple source inputs, filter single-end occasional abnormalities, and improve the reliability and confirmability of missing detection; 4. The present application performs missing path expansion and path integration according to the predecessor and successor dependency relationship in the flow structure, deduces scattered missing nodes into continuous cross-node flow missing links, so that the missing behaviors can be presented in the form of flow links, and realizes the cross-node abnormality tracking ability from “missing point perception” to “missing chain positioning”; 5、The application performs process integrity judgment based on continuous missing comparison and preset trigger condition in the cloud, forms an abnormality recognition mechanism by counting the length of continuous missing, identifying missing of key nodes and analyzing missing distribution position. BRIEF DESCRIPTION OF DRAWINGS

[0013] Fig. 1 A method step flowchart of the application.

[0014] Fig. 2 A system module schematic diagram of the application. DETAILED DESCRIPTION

[0015] The technical solutions in the embodiments of the application will be apparently and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the application.

[0016] With reference to the drawings in the description, Figs. 1-2 An enterprise-level multi-source abnormal behavior monitoring method according to an embodiment of the application comprises: S1, a process structure analysis operation is performed by an end-side device, and a set of expected behaviors is constructed according to a function module, an interface call relationship and a process rule deployed by the end-side device to generate a set of expected behaviors of the end-side; S2, a matching calculation operation is performed by the end-side device on actual behavior events collected in a running period, and the actual behavior events are compared with the set of expected behaviors of the end-side to identify target behaviors not covered by the actual behavior events, thereby generating a set of missing behaviors of the end-side; S3, the set of missing behaviors of the end-side is uploaded to the cloud in cooperation with the end cloud by the end-side device to form an expected behavior state input submitted to the cloud; S4, a cross-node alignment calculation operation is performed by a monitoring platform in the cloud on a plurality of sets of missing behaviors of the end-side, and a missing behavior mapping operation is performed according to a dependent link existing in the process structure to generate a cross-node process missing link; S5, a process integrity judgment operation is performed by the monitoring platform in the cloud according to the cross-node process missing link, and a missing-type abnormal behavior judgment result is output when any process is in a missing state in the associated node in the cloud.

[0017] In S1, it comprises: S1-1, the end-side device performs a read operation on the process structure definition data for describing the process nodes and their association relationship, and performs a process node analysis operation on each read process node, and writes the parsed process node identifier, function module identifier, and predecessor process node identifier and successor process node identifier into the process node set and the process transition relationship set in turn; S1-2, the end-side device performs an interface relationship calculation operation on each process node in the process node set according to the process node identifier and the function module identifier in the process node set, and the interface call relationship configured by the end-side device, determines the interface call list corresponding to the process node, and writes the process node identifier, function module identifier and interface call list into the first behavior element set according to a unified structure; S1-3, the end-side device performs a sequence calculation operation on the process transition relationship set according to the process rule, and performs a sorting operation on the predecessor process node identifier and the successor process node identifier according to the process rule, to generate a process step sequence; S1-4, the end-side device performs an element sequence mapping calculation operation on the first behavior element set according to the process step sequence, matches the corresponding behavior element according to the process node identifier in the process step sequence in turn, and writes the matched behavior element into the end-side expected behavior set in order; In S1-1, the end-side device is deployed as a computing node in the business field or the edge side, and performs a read operation on the process structure definition data stored in the local configuration file, database or remote configuration service. The read operation means that the end-side device loads the complete process structure definition data from the storage medium into the memory of the end-side device; The process structure definition data is used to describe each process node in the business process and the association relationship between the process nodes, including giving the unique process node identifier of each process node, the function module identifier of the corresponding software or hardware function unit, and the predecessor process node identifier and successor process node identifier connected with the process node in a structured record manner. After the reading is completed, the end-side device performs a flow node parsing operation on each flow node record in the flow structure definition data, in which the flow node identifier carried in each record is parsed into an identifier value for uniquely identifying the flow node, the function module identifier is parsed into an identifier value for indicating which function module executes the flow node, the predecessor flow node identifier and the successor flow node identifier are parsed into identifier values for indicating the flow execution sequence relationship, and the parsed flow node identifier and function module identifier are written into the flow node set as node attribute values, for recording the entire flow nodes included in the business flow and the function module corresponding relationship thereof, and the parsed predecessor flow node identifier and successor flow node identifier are written into the flow transition relationship set as a pair of directed relationship values, for recording the front and back transition relationship between the flow nodes in the business flow, so as to continue the behavior calculation and expected behavior set construction operation based on the flow node set and the flow transition relationship set in the subsequent steps; It needs to be explained in S1-2 that the end-side device performs an item-by-item processing operation on the flow node set generated in S1-1, in which the flow node set records the flow node identifier and the function module identifier of each flow node; the flow node identifier is used to uniquely identify the flow node, and the function module identifier is used to indicate which function module executes the flow node in the business processing; the end-side device needs to synchronously load the interface call relationship configured internally in the end-side device before performing this step, which records the correspondence between the function module and the interface identifier in a structured form, for describing the interface call items that can be triggered by each function module when executing the flow node; After the loading of the flow node set and the interface call relationship is completed, the end-side device performs an interface relationship calculation operation on each flow node in the flow node set; the interface relationship calculation operation includes the following consecutive operations: first, the end-side device retrieves the corresponding function module identifier with the flow node identifier, and takes the function module identifier as an interface retrieval key; second, the end-side device performs an interface screening calculation operation in the interface call relationship according to the interface retrieval key, and screens out all interface records consistent with the function module identifier; third, the end-side device performs a structure arrangement operation on the screened interface records, combines the interface identifier, the interface call mode and the interface parameter structure in the interface records according to the preset structure order, and forms an interface call list for describing the triggerable interfaces of the flow node; finally, the end-side device writes the flow node identifier, the function module identifier and the interface call list into the first behavior element set in a unified data structure format, wherein the first behavior element set is used to record the function attributes and interface behavior attributes of each flow node, and provides continuous, complete and parsable data input for the subsequent behavior combination calculation operation; It needs to be explained in S1-3: the end-side device performs a sequence calculation operation on the flow transition relationship set written by S1-1, wherein the flow transition relationship set is used to record the execution relationship between each flow node in the business process, and each transition relationship is composed of a predecessor flow node identifier and a successor flow node identifier. The predecessor flow node identifier is used to indicate the previous position of a node in the execution sequence, and the successor flow node identifier is used to indicate the next position of a node in the execution sequence. When the end-side device performs the sequence calculation operation, it will perform a piece-by-piece parsing operation on all the predecessor flow node identifiers and successor flow node identifiers in the flow transition relationship set, and use the parsed predecessor flow node identifiers and successor flow node identifiers as the input of the sorting operation. Specifically, first, the end-side device performs a starting point determination operation on all the predecessor flow node identifiers in the flow transition relationship set. By searching whether each predecessor flow node identifier appears in the successor flow node identifier of other transition relationships, it determines the flow node identifier that is not used as a successor flow node identifier by any transition relationship, and uses it as the starting node identifier of the flow step sequence. Secondly, the end-side device performs a step-by-step expansion operation on the flow transition relationship set based on the starting node identifier. According to the arrangement relationship of the successor flow node identifier corresponding to each predecessor flow node identifier, it determines the subsequent flow node identifier in turn and performs a sorting operation on these flow node identifiers according to the sequence requirements specified in the flow rules. The flow rules are used to describe the fixed execution sequence requirements of the flow nodes in the business process, including the preceding and succeeding dependency relationship, the prohibited jump relationship or the relationship that must be executed continuously. The end-side device performs a sequence check and sorting adjustment operation on each pair of predecessor flow node identifier and successor flow node identifier according to these flow rules, and ensures that the sorting result meets all the constraints of the flow rules. Finally, the end-side device writes the result of the sorting operation into the flow step sequence in the form of a sequence of flow node identifiers, so that the flow step sequence completely records the execution sequence of the business process and provides a continuous and available execution sequence input for the execution element sequence mapping calculation operation in S1-4. It needs to be explained in S1-4: the end-side device performs a piece-by-piece processing operation on the flow step sequence generated in S1-3. The flow step sequence is used to record the execution sequence of each flow node in the business process, and each sequence element is a flow node identifier parsed in S1-1, which is used to uniquely indicate a specific flow node in the process. At the same time, the first behavior element set is generated by S1-2, and each record in the first behavior element set is composed of a flow node identifier, a function module identifier and an interface call list, which is used to describe the function attributes and interface call attributes corresponding to the flow node. The end-side device, when performing the element sequence mapping calculation operation, takes the process step order sequence as traversal input and performs matching operation on each process node in the sequence; specifically: the end-side device takes the process node identifier as the retrieval key and performs behavior element retrieval operation in the first behavior element set; by comparing the process node identifier field of each record in the first behavior element set, the behavior element record consistent with the current process node identifier is located, and the retrieved behavior element record is taken as the target behavior element of the process node; the end-side device performs the above retrieval operation on each process node identifier in the process step order sequence in turn to ensure that the order of the retrieval result is strictly consistent with the arrangement order of the process step order sequence; Subsequently, the end-side device performs sequential writing operation on the retrieved target behavior element, and sequentially writes each target behavior element according to the order position of the process step order sequence into the end-side expected behavior set; the end-side expected behavior set is used to record the complete expected execution order of the business process in the end-side device, and each writing record contains the process node identifier, the function module identifier and the interface call list, thereby maintaining the one-to-one corresponding logical structure with the process step order sequence.

[0018] In S2, it includes: S2-1, performing event analysis operation on each actual behavior event collected in the running period by the end-side device: sequentially resolving the process node identifier, event interface identifier and event timestamp in each actual behavior event, and writing the resolved process node identifier into the event node identifier set, and writing the resolved process node identifier and the corresponding event interface identifier into the event interface mapping set according to the corresponding relationship; S2-2, performing matching calculation operation on the event node identifier set and the end-side expected behavior set by the end-side device: taking the process node identifier as the first matching key, performing first matching judgment operation on each expected behavior record in the end-side expected behavior set, when there is no process node identifier consistent with the process node identifier in the event node identifier set, marking the expected behavior record as node uncovered state, otherwise marking the expected behavior record as node covered state; at the same time, for the expected behavior record marked as node covered state, taking the interface call list in the expected behavior record as the second matching key and the event interface identifier set corresponding to the process node identifier in the event interface mapping set as the second matching object, performing interface relationship comparison operation, when the intersection result of the interface relationship comparison operation is empty, marking the expected behavior record as interface uncovered state, otherwise marking the expected behavior record as interface covered state; S2-3, the end-side device performs a missing behavior record writing operation on the expected behavior records marked as node uncovered state or interface uncovered state in the end-side expected behavior set, and writes the corresponding flow node identifier, function module identifier and interface call list in a unified structure into the end-side missing behavior set; at the same time, for the expected behavior records marked as node covered state and marked as interface covered state, the end-side device keeps their coverage state to form an end-side covered behavior set, so that the end-side missing behavior set only records the target behaviors not covered by any actual behavior event in the running period; It needs to be explained in S2-1 that the actual behavior event is a business execution record collected by the end-side device in real time in the running period, used to represent the real execution of the business process on the end-side device; each actual behavior event stores the corresponding flow node identifier, event interface identifier and event timestamp in a structured form, wherein the flow node identifier is an identifier value used to uniquely indicate the specific flow node in the business process corresponding to the actual behavior event, the event interface identifier is an interface identifier value used to indicate the interface call item triggered by the actual behavior event, and the event timestamp is a time value used to represent the time sequence of the occurrence of the actual behavior event in the business process; In addition, when the end-side device performs the event analysis operation on the actual behavior event, it performs a field analysis operation on the structured record of each actual behavior event, and sequentially analyzes the flow node identifier field, event interface identifier field and event timestamp field from the record structure, and writes the analyzed flow node identifier into the event node identifier set, and at the same time, writes the flow node identifier and the corresponding event interface identifier into the event interface mapping set in a one-to-one correspondence, so that the event node identifier set records the flow node identifiers involved in all actual behavior events in the running period, and the event interface mapping set records the correspondence between the flow node identifier and the event interface identifier in the event, providing complete event input data for subsequent matching calculation operation and missing behavior identification; It needs to be explained in S2-2 that the end-side device performs the matching calculation operation by taking the event node identifier set and the end-side expected behavior set as parallel inputs, wherein the event node identifier set is obtained by analyzing the actual behavior event in S2-1, and is used to record all the flow node identifiers actually occurred in the running period; the end-side expected behavior set is generated by flow structure analysis, behavior combination calculation and sequence mapping calculation in S1, and is used to record all the expected behavior records expected to appear in the business process in a specific order by the end-side device, each expected behavior record at least contains a flow node identifier, a function module identifier and an interface call list; In the first stage of the matching calculation, the end-side device sequentially performs a matching determination operation of the node dimension for each expected behavior record in the end-side expected behavior set; for each expected behavior record, the end-side device first reads the flow node identifier from the expected behavior record and takes the flow node identifier as a first matching key; then, the end-side device performs an item-by-item comparison operation in the event node identifier set with the first matching key, and determines whether there is a node record consistent with the first matching key by performing a strict consistency comparison on each flow node identifier in the event node identifier set; when there is no flow node identifier consistent with the first matching key in the event node identifier set, the end-side device marks the expected behavior record as a node non-covered state; when there is at least one flow node identifier consistent with the first matching key in the event node identifier set, the end-side device marks the expected behavior record as a node covered state; at this point, the end-side device completes the first stage of the matching calculation of whether the expected behavior record appears in the running cycle in the node dimension; In the second stage of the matching calculation, the end-side device only continues to perform a matching determination operation of the interface dimension for the expected behavior record marked as the node covered state in the first stage; for each expected behavior record in the node covered state, the end-side device first reads the interface call list from the expected behavior record and takes the interface call list as a second matching key; then, the end-side device retrieves the event interface identifier set corresponding to the flow node identifier in the event interface mapping set according to the flow node identifier in the expected behavior record, and takes the event interface identifier set as a second matching object; the event interface mapping set is formed after the end-side device writes the flow node identifier and the corresponding event interface identifier in the association relationship in S2-1, and is used to record the triggering situation of the actual behavior event in the interface layer; In the interface dimension comparison calculation, the end-side device takes the interface call list in the second matching key and the event interface identifier set in the second matching object as inputs and performs an interface relationship comparison operation; the operation determines whether there is consistency between the expected interface call and the actual interface call by calculating the intersection of the interface call list and the event interface identifier set; when the intersection result is an empty set, it means that the interface call listed in the end-side expected behavior record is not triggered in any actual behavior event in the running cycle, and the end-side device marks the expected behavior record as an interface non-covered state; when the intersection result is a non-empty set, it means that at least one expected interface call is triggered in the actual behavior event, and the end-side device marks the expected behavior record as an interface covered state; It is necessary to explain in S2-3: after the end-side device completes the two-level matching determination of the node dimension and the interface dimension, it will take the coverage state of each expected behavior record in the end-side expected behavior set as input to perform the missing behavior record writing operation; wherein each expected behavior record in the end-side expected behavior set has been marked as node non-coverage state, interface non-coverage state, node coverage state or interface coverage state in S2-2, and the node non-coverage state means that the expected behavior record has no actual behavior event falling within its corresponding flow node in the running period, and the interface non-coverage state means that the expected behavior record is covered by the actual behavior event in the flow node dimension, but the interface call item in its interface call list does not appear in any actual behavior event; When the end-side device performs the missing behavior record writing operation, it will sequentially traverse the end-side expected behavior set, and read the coverage state of each expected behavior record. When the expected behavior record is marked as node non-coverage state or interface non-coverage state, the end-side device will write the flow node identifier, function module identifier and interface call list in the expected behavior record into the end-side missing behavior set according to the unified structure, so that the end-side missing behavior set records all target behaviors that are not covered by any actual behavior event in the running period. On the contrary, when the expected behavior record is marked as node coverage state and interface coverage state at the same time, the end-side device keeps its coverage state and writes the expected behavior record into the end-side covered behavior set according to the original structure, so that the end-side covered behavior set records all expected behaviors that have been completely covered by the actual behavior event in the running period. Through the above writing operation, the end-side device generates the end-side missing behavior set and the end-side covered behavior set in the same running period, so as to clearly distinguish between the uncovered behaviors and the covered behaviors, and provide complete and calculable behavior classification results for subsequent steps of performing abnormal detection or generating collaborative input.

[0019] In S3, it includes: S3-1, performing missing behavior traversal operation on the end-side missing behavior set by the end-side device, and reading the flow node identifier, function module identifier and interface call list in each missing behavior record, while performing event association retrieval operation on the actual behavior events collected in the running period, and writing the event interface identifier and event timestamp of the actual behavior event that can be consistent with the flow node identifier in the event node identifier set into the expected behavior state record according to the corresponding relationship; S3-2, performing structure integration operation on all expected behavior state records by the end-side device, and writing the flow node identifier, function module identifier, interface call list, event interface identifier and event timestamp in each expected behavior state record into the end-side expected behavior state input set according to the unified structure; S3-3, the end-side device performs an end-cloud cooperative uploading operation on the end-side expected behavior state input set, and transmits the end-side expected behavior state input set to the cloud monitoring platform in the form of a data packet, so that the cloud monitoring platform obtains the end-side expected behavior state input for subsequent calculation; It needs to be explained in S3-1 that: the end-side device first performs a missing behavior traversal operation on the end-side missing behavior set. The missing behavior traversal operation refers to that the end-side device reads each missing behavior record in the end-side missing behavior set in a preset order, reads the flow node identifier, the function module identifier and the interface call list in each missing behavior record which have been generated in the previous step, and takes the three fields as the basic identification information of the missing behavior record. Then, the end-side device performs an event association retrieval operation on all actual behavior events collected in the running period according to the flow node identifier in the current missing behavior record. The event association retrieval operation refers to that the end-side device reads the data record of each actual behavior event, parses the corresponding flow node identifier from each actual behavior event, and compares the flow node identifier with the flow node identifier in the current missing behavior record. When the comparison result is consistent, the end-side device regards the actual behavior event as an actual behavior event associated with the current missing behavior record in the flow node dimension, and parses the event interface identifier and the event timestamp from the actual behavior event. For each actual behavior event satisfying the flow node identifier consistency condition, the end-side device constructs an expected behavior state record, writes the flow node identifier, the function module identifier and the interface call list corresponding to the current missing behavior record in the expected behavior state record, and writes the event interface identifier and the event timestamp of the actual behavior event associated with the flow node identifier, so that the expected behavior state record carries the expected behavior information and the associated actual behavior event information in the same structure. Through the sequential traversal of the end-side missing behavior set and the association retrieval of the actual behavior event, the end-side device generates a set of expected behavior state records with associated event information for each missing behavior record, and provides the end-side expected behavior state data with complete structure for subsequent uploading of the end-side expected behavior state input set to the cloud monitoring platform; It is necessary to explain in S3-2 that: after the end-side device completes the association processing of the end-side missing behavior set and the actual behavior event, it has generated an expected behavior state record set composed of multiple expected behavior state records. When the end-side device performs the structure integration operation on the expected behavior state record set, it reads each expected behavior state record in the set one by one, reorganizes the flow node identifier, the function module identifier, the interface call list, the event interface identifier and the event timestamp in each expected behavior state record according to the preset field order and field format, and uniformly encapsulates the above fields as a structure-consistent data record entry. After the end-side device completes the field reorganization of a single expected behavior state record, it writes the reorganized data record entry into the end-side expected behavior state input set, so that each record in the end-side expected behavior state input set is completely consistent in field composition, field order and field type, thereby forming an end-side expected behavior state input set that can be processed by subsequent end-cloud collaborative uploading operations as a whole; It is necessary to explain in S3-3 that: after the end-side device completes the structure integration of the end-side expected behavior state input set, it performs an end-cloud collaborative uploading operation on the end-side expected behavior state input set. When the end-side device performs the end-cloud collaborative uploading operation, it takes the end-side expected behavior state input set as the transmission payload, first serializes each record in the set according to the predetermined encoding rule, converts the structured expected behavior state record into a data format suitable for transmission, and adds an information header field outside the data format for identifying the data type, data length and running period identifier, thereby forming a complete data packet. Subsequently, the end-side device sends the data packet containing the end-side expected behavior state input set to the cloud monitoring platform through the communication channel established between the end-side device and the cloud monitoring platform, so that the cloud monitoring platform obtains the end-side expected behavior state input composed of the flow node identifier, the function module identifier, the interface call list, the event interface identifier and the event timestamp after receiving the data packet and completing the deserialization processing, thereby providing the cloud monitoring platform with end-side expected behavior state basic data for performing cross-node alignment calculation and missing behavior mapping calculation in subsequent steps.

[0020] In S4, it includes: S4-1, the monitoring platform in the cloud performs a sequential reading operation on the end-side missing behavior sets from multiple end-side devices, and reads the flow node identifier, the function module identifier and the interface call list in each missing behavior record, while recording the end-side device identifier to which the missing behavior record belongs. The missing situation of the same flow node identifier under different end-side device identifiers is written into the cloud missing behavior reference table in a corresponding relationship, so that the cloud missing behavior reference table records the missing situation of each end-side device according to the flow node identifier; S4-2, the cloud monitoring platform performs cross-node alignment calculation operation on the cloud missing behavior table according to the process node identifier, and performs consistency judgment on the missing records of each process node identifier under different end-side device identifiers; when there are missing records under two or more end-side device identifiers for a certain process node identifier, the process node identifier is marked as a consistent missing node; when there is only one missing record under an end-side device identifier for any process node identifier, the cloud monitoring platform performs interface consistency judgment on the interface call list of the process node identifier under different end-side device identifiers; when the interface call in the interface call list does not appear under two or more end-side device identifiers, the process node identifier is marked as an interface missing node; when the node consistency and the interface consistency are not satisfied, the cloud monitoring platform keeps the inconsistent missing state of the process node identifier as the termination condition of subsequent path calculation; S4-3, the cloud monitoring platform performs path expansion operation on the process node identifier marked as a consistent missing node or an interface missing node according to the dependency relationship between the predecessor process node identifier and the successor process node identifier in the process structure, taking any marked process node identifier as the expansion starting point, and performing progressive expansion to its predecessor process node identifier and successor process node identifier; when the process node identifier obtained by progressive expansion belongs to a consistent missing node or an interface missing node, continue to expand, when the process node identifier obtained by progressive expansion belongs to a non-consistent missing state, stop expanding, thereby forming a number of missing path sequences composed of adjacent missing nodes; It needs to be explained in S4-1 that the cloud monitoring platform first performs sequential reading operation on the end-side missing behavior set reported from multiple end-side devices, the sequential reading operation means that the cloud monitoring platform takes out each missing behavior record in sequence according to the record order in the end-side missing behavior set for processing, without skipping or rearranging, to ensure that the subsequent processing process can completely cover all missing behavior records; for each missing behavior record taken out, the cloud monitoring platform reads the process node identifier, function module identifier and interface call list generated by the end-side device in the missing behavior record in sequence, wherein the process node identifier is used to uniquely indicate the business process node corresponding to the missing behavior record, the function module identifier is used to indicate which business function module the missing behavior record belongs to, and the interface call list is used to indicate the interface set expected to be called at the process node, and the cloud monitoring platform also reads the end-side device identifier to which the missing behavior record belongs from the outer layer or additional field of the missing behavior record, for distinguishing the missing source of the same process node identifier on different end-side devices; After the above field reading is completed, the cloud monitoring platform writes the missing condition corresponding to the missing behavior record into the cloud missing behavior table with the process node identifier as the index key and the end-side device identifier as the distinguishing field. The cloud monitoring platform establishes a row or a group of records for each process node identifier in the cloud missing behavior table and fills in the missing state of each end-side device and the associated functional module identifier and interface call list in the row or the group of records according to the end-side device identifier, so that the cloud missing behavior table can reflect the missing conditions from different end-side devices in the same data structure according to the process node identifier, thereby providing a clear and retrievable missing behavior reference for subsequent cross-node alignment calculation; It is necessary to explain in S4-2 that the cloud monitoring platform takes the cloud missing behavior table as input and performs cross-node alignment calculation on the missing conditions of each process node identifier under different end-side device identifiers. The cloud missing behavior table is a data structure constructed in S4-1, in which the missing behavior record information corresponding to each end-side device identifier is listed in the same row or the same group of records, so that the cloud monitoring platform can simultaneously see the missing conditions of “the same process node on different end-side devices” in the same position. The cross-node alignment calculation operation means that the cloud monitoring platform takes the record set corresponding to each process node identifier in the cloud missing behavior table in turn and compares the missing records of the process node identifier under each end-side device identifier, rather than separately and fragmentedly looking at the missing conditions of a certain end-side device. When performing node consistency judgment, the cloud monitoring platform first counts the number of end-side device identifiers under which the process node identifier has missing behavior records in the cloud missing behavior table. If the same process node identifier has missing behavior records under two or more end-side device identifiers, it is considered that the process node presents the same “node-level missing” phenomenon on multiple end-sides, and the cloud monitoring platform marks the process node identifier as a consistent missing node. The consistency here means that the same process node is in a missing state on multiple end-side devices, rather than a certain ambiguous similarity. If the same process node identifier has missing behavior records only under one end-side device identifier and has no missing behavior records under other end-side device identifiers, it is considered that the process node does not have the consistent missing feature across end-sides at the node level, and the node consistency condition is not established. The cloud monitoring platform does not mark it as a consistent missing node, but enters the next interface consistency judgment. In the interface consistency determination, the monitoring platform in the cloud still operates in the same process node identification unit; for the process node identification that the node consistency is not established, the monitoring platform in the cloud reads the interface call list information corresponding to the process node identification under each end-side device identification from the cloud missing behavior comparison table; the interface call list is the expected interface set reserved in the missing behavior record, used to represent the interface call items that should be triggered by the process node under normal circumstances; at the same time, the monitoring platform in the cloud determines the interface calls actually occurred by each end-side device in the actual behavior event according to the event interface identification corresponding to the process node identification and the end-side device identification in the end-side expected behavior state input set uploaded to S3; the calculation process of the interface consistency determination is: for each interface call in the interface call list of the process node identification, it is checked whether the interface call does not appear in the actual behavior event corresponding to two or more end-side device identifications (i.e. the interface call item cannot be found in the event interface identification of these end-side devices); when the interface call in the interface call list is not triggered by the actual behavior event on at least two end-side devices, the monitoring platform in the cloud considers that the process node presents the consistent missing feature across the end-side at the interface level, and thus marks the process node identification as an interface missing node; here, the interface consistency refers to the common missing of the same group of interface calls of the same process node in the actual behavior event of multiple end-side devices, rather than the simple missing of a single end-side; When a certain process node identification neither meets the node consistency condition (i.e. the condition that there is a node missing record under two and more end-side device identifications) nor meets the interface consistency condition (i.e. the condition that the interface call in the interface call list does not appear under two or more end-side device identifications), the monitoring platform in the cloud keeps the process node identification as a non-consistent missing state; the non-consistent missing state indicates that the process node only has local missing at a single end-side or at a partial interface level in the current running period, and does not have the consistent missing feature across the end-side; in the subsequent missing path expansion in S4-3, once a process node identification marked as a non-consistent missing state is encountered in the path expansion direction, the monitoring platform in the cloud will take the process node identification as the termination condition of the path expansion, and stop continuing to add the successor or predecessor node in this direction, so as to ensure that the cross-node process missing link is only composed of consistent missing nodes and interface missing nodes, and will not be pulled into the path chain by local and occasional non-consistent missing nodes; It is necessary to explain in S4-3: the monitoring platform in the cloud takes the dependency relationship between the predecessor process node identifier and the successor process node identifier established in the process structure as the logical basis for path expansion; the predecessor process node identifier and the successor process node identifier recorded in the process structure are a clear, directed process connection relationship, which is used to represent the execution order of each process node in the business process: the predecessor process node identifier represents the node that must be executed first in the process structure, and the successor process node identifier represents the node that follows it, so this kind of dependency relationship can be used to find the adjacent process node identifier that has a sequential relationship with it from any process node forward or backward; When formally entering the path expansion operation, the monitoring platform in the cloud first selects any one of the process node identifiers that have been marked as consistent missing nodes or interface missing nodes in S4-2 as the expansion starting point; the expansion starting point must come from a consistent missing node or an interface missing node because these nodes have been confirmed to have missing characteristics across the end side in the calculation phase, and are the establishable starting point of the missing path; after selecting the expansion starting point, the monitoring platform in the cloud will execute two progressive expansion paths in the predecessor direction and the successor direction respectively according to the predecessor process node identifier and the successor process node identifier corresponding to the process node identifier in the process structure; When expanding in the predecessor direction, the monitoring platform in the cloud starts from the predecessor process node identifier of the expansion starting point and takes this predecessor process node identifier as the next node of progressive expansion; then, the monitoring platform in the cloud judges whether the predecessor process node identifier belongs to a consistent missing node or an interface missing node; if it belongs to a consistent missing node or an interface missing node, it means that this node also presents a consistent missing feature across the end side as the expansion starting point, and therefore still belongs to the expandable missing path; the monitoring platform in the cloud will continue to expand in the predecessor direction of this predecessor process node identifier and repeatedly execute the above judgment process; if the predecessor process node identifier is marked as a non-consistent missing state, it means that the node does not have a stable missing feature across the end side and cannot be used as an effective node in the missing path, so the monitoring platform in the cloud will immediately stop the progressive expansion in the predecessor direction, making the direction terminate directly; When expanding in the successor direction, the monitoring platform in the cloud uses the same logic; the monitoring platform in the cloud starts from the successor process node identifier of the expansion starting point and takes this successor process node identifier as the next node of progressive expansion, and then judges whether the successor process node identifier belongs to a consistent missing node or an interface missing node; if it belongs to the above two types of missing nodes, the monitoring platform in the cloud will continue to expand in the successor direction of this successor process node identifier; if the successor process node identifier belongs to a non-consistent missing state, it will stop the expansion operation in the successor direction, which is consistent with the termination logic of the predecessor direction; By performing progressive expansion in the predecessor direction and the successor direction respectively, the monitoring platform in the cloud can obtain a sequence of missing nodes for each expansion starting point, which is continuously expanded forward and backward, and the sequence is composed of adjacent process node identifiers marked as consistent missing nodes or interface missing nodes; when multiple expansion starting points perform path expansion respectively, the monitoring platform in the cloud can obtain several missing path sequences, each of which is composed of a group of process node identifiers that are continuously adjacent in the process structure and exhibit stable missing characteristics across the end side, thereby providing a basis for generating complete cross-node process missing links for subsequent path integration operations.

[0021] In S4, it also includes: S4-4, performing path integration operations on the missing path sequences by the monitoring platform in the cloud, merging and calculating the missing path sequences in which the predecessor process node identifier and the successor process node identifier are continuously arranged in the process structure, and performing repeated record elimination operations and sequence verification operations on the merged process node identifier sequence to generate a cross-node process missing link composed of multiple continuous missing nodes, and writing the cross-node process missing link into the cross-node process missing link set; In S4-4, it needs to be explained that the monitoring platform in the cloud has obtained several missing path sequences in S4-3, each of which is composed of adjacent process node identifiers in the process structure and is marked as consistent missing nodes or interface missing nodes; however, these missing path sequences often appear in segments, for example, one path sequence may only cover the predecessor continuous missing nodes near the expansion starting point, and another path sequence may cover the continuous missing nodes in the successor direction in the same process structure, so the monitoring platform in the cloud needs to further integrate these missing path sequences to form a continuous cross-node process missing link from the scattered missing node sequences. When performing path integration operations, the monitoring platform in the cloud first searches for missing path sequences in which the predecessor process node identifier and the successor process node identifier have a direct dependency relationship in the process structure; the dependency relationship between the predecessor process node identifier and the successor process node identifier in the process structure can accurately reflect the upstream and downstream order between nodes, so the monitoring platform in the cloud uses this as the basis for judging whether the starting node and the terminal node of the missing path sequence are continuously adjacent to the nodes in other missing path sequences; when the end process node identifier of a missing path sequence and the start process node identifier of another missing path sequence form a predecessor and successor relationship in the process structure, the monitoring platform in the cloud regards the two missing path sequences as mergable sequences, and connects them in the order of process node identifiers, thereby forming a longer continuous missing path. After the merging of the serially connectable missing path sequence is completed, the monitoring platform in the cloud performs a duplicate record elimination operation on the merged missing path. Duplicate records can occur when the end process node identifier of a missing path sequence is the same as the start process node identifier of another missing path sequence. Therefore, the monitoring platform in the cloud needs to compare the process node identifiers in the merged path one by one, delete the duplicate node records, and keep each process node identifier in the merged path only once, so as to avoid path structure disorder or logical errors caused by duplicate records. After the duplicate record elimination operation is completed, the monitoring platform in the cloud performs a sequence verification operation on the merging result. The purpose of the sequence verification operation is to check whether the sequence of the merged process node identifiers strictly follows the dependency relationship between the predecessor process node identifier and the successor process node identifier in the process structure. In the sequence verification process, the monitoring platform in the cloud compares the adjacent process node identifiers in the merged path one by one according to the process structure. When there is no sequence relationship between the predecessor and the successor of the adjacent process node identifiers, the monitoring platform in the cloud determines that the path has a sequence error and terminates the use of the path. When all adjacent process node identifiers in the path meet the predecessor and successor relationship recorded in the process structure, the monitoring platform in the cloud considers that the sequence verification of the path is passed. After the above merging calculation, duplicate record elimination operation and sequence verification operation are completed, the monitoring platform in the cloud finally obtains a cross-node process missing link composed of multiple process node identifiers that are continuously adjacent in the process structure and have consistent missing phenomena on multiple end-side devices. The cross-node process missing link is written into the cross-node process missing link set as the final link output result, which is used for subsequent cross-node process integrity judgment and generation of missing-type abnormal behavior judgment result.

[0022] In S5, the following is included: S5-1, the monitoring platform in the cloud performs a process integrity judgment operation on the cross-node process missing link: taking each process node identifier in the cross-node process missing link as a judgment object, performing a missing state reading operation on the missing state of the process node identifier in the cross-node process missing link, and performing a continuous missing comparison operation on the missing state and the missing state corresponding to the predecessor process node identifier and the successor process node identifier of the process node identifier in the process structure. When the result of the continuous missing comparison operation shows that any process node identifier presents a continuous missing state in the predecessor direction or the successor direction, the process node identifier is marked as a process missing node. S5-2, performing, by the monitoring platform in the cloud, a missing procedure node record operation on the procedure node identifier marked as a missing procedure node, writing the procedure node identifier into a missing procedure node set, and performing a condition determination operation on the record quantity of the missing procedure node set and a preset missing trigger condition, when the result of the condition determination operation meets the preset missing trigger condition, performing, by the monitoring platform in the cloud, an abnormal behavior output operation, and outputting a missing type abnormal behavior determination result; It is to be noted that in S5-1, the monitoring platform in the cloud takes the cross-node missing procedure link as the input object of the procedure integrity judgment; the cross-node missing procedure link is an ordered sequence of procedure node identifiers generated based on the missing behaviors reported by the plurality of end-side devices and the predecessor and successor relationship in the procedure structure in the previous step, and each procedure node identifier in the sequence has been confirmed to be in a missing state in the cloud; when performing the procedure integrity judgment operation, the monitoring platform in the cloud takes each procedure node identifier in the cross-node missing procedure link as an independent judgment object, performs a missing state reading operation on the missing state of the procedure node identifier that has been recorded, so that the missing condition of each procedure node identifier is in an explicit available state before the judgment starts; Subsequently, the monitoring platform in the cloud performs a continuous missing comparison operation on the current procedure node identifier and its directly adjacent predecessor procedure node identifier and successor procedure node identifier according to the dependency relationship between the predecessor procedure node identifier and the successor procedure node identifier pre-established in the procedure structure; the purpose of the continuous missing comparison operation is to determine whether the current procedure node identifier is in a missing state at the same time as at least one adjacent procedure node identifier; the so-called continuity here refers to that the current procedure node identifier and its predecessor procedure node identifier are both in a missing state, or the current procedure node identifier and its successor procedure node identifier are both in a missing state; when the continuous missing threshold is set to at least two procedure node identifiers, as long as the current procedure node identifier is in a missing state at the same time as any adjacent procedure node identifier, the continuous missing condition is met; if a more stringent judgment condition is required, the continuous missing threshold can also be set to at least three procedure node identifiers, at this time, the current procedure node identifier and its two adjacent continuous procedure node identifiers are both in a missing state, which constitutes continuous missing; To calculate the length of continuous missing, the monitoring platform in the cloud takes the current process node identifier as the starting point and searches in the predecessor direction and the successor direction of the process structure respectively; when searching in the predecessor direction, the monitoring platform in the cloud first checks the missing state of the predecessor process node identifier of the current process node identifier, and if the predecessor process node identifier is in the missing state, it continues to search for the predecessor process node identifier of the predecessor process node identifier; once a process node identifier that is no longer in the missing state is encountered, the search in the predecessor direction is stopped, and the number of continuous missing nodes found is taken as the length of continuous missing in the predecessor direction; the same logic applies to the successor direction, i.e., taking the current process node identifier as the starting point, searching continuously backward along the successor process node identifier until a process node identifier that does not meet the missing state is encountered, thereby obtaining the length of continuous missing in the successor direction; the monitoring platform in the cloud then compares the lengths of continuous missing in the predecessor direction and the successor direction with the preset continuous missing threshold respectively; When the comparison result shows that the length of continuous missing in either direction reaches or exceeds the preset continuous missing threshold, it means that the current process node identifier not only has a missing state itself, but also forms a continuous missing node link with its adjacent nodes in the process structure; at this time, the monitoring platform in the cloud marks the process node identifier as a process missing node; the process missing node is used to indicate that the node has a continuous missing in the process structure that has a substantial impact on the execution order of the overall process; if the current process node identifier does not reach the preset continuous missing threshold in both the predecessor direction and the successor direction, it means that the process node identifier is only an isolated missing or belongs to a short chain missing, which does not constitute a continuous missing of the process structure, and the monitoring platform in the cloud does not mark it as a process missing node, but only keeps it as a general missing state node for the subsequent process abnormality judgment operation of S5-2; It needs to be explained in S5-2 that the monitoring platform in the cloud takes the process node identifier that has been marked as a process missing node in S5-1 as input and first performs a process missing node recording operation; specifically, the monitoring platform in the cloud processes each process missing node one by one and writes the process node identifier into a process missing node set; the process missing node set is used to store all process node identifiers in the process missing state, so that the monitoring platform in the cloud can record the process missing situation in the current running period in the same data structure without the need to repeatedly search from the cross-node process missing link or other data; After the procedure missing node record operation is completed, the cloud monitoring platform performs condition judgment operation on the procedure missing node set; the core of the condition judgment operation is to compare the record number of the procedure missing node set and the specific procedure node identifier contained therein with the preset missing trigger condition item by item to determine whether the missing type abnormal behavior judgment result needs to be output; the preset missing trigger condition here is a set of judgment rules pre-set by the cloud in the system configuration stage, which is used to stipulate under what circumstances the procedure missing phenomenon should be identified as abnormal behavior; the preset missing trigger condition at least includes the following three types of judgment basis: The first type of judgment basis is the procedure missing node number threshold; the cloud monitoring platform counts the record number from the procedure missing node set, and when the record number is greater than or equal to the preset first missing node number threshold, it is considered that there is an abnormal missing situation in the number level in the procedure structure in the current running period; The second type of judgment basis is the key procedure node missing rule; the procedure structure usually contains a number of key procedure node identifiers, which are used to represent the key steps in the procedure execution process; when any key procedure node identifier appears in the procedure missing node set, even if the record number of the procedure missing node does not reach the number threshold, it is still considered as one of the conditions for triggering the missing abnormality; this judgment basis is used to identify high-risk missing behavior occurring at the key procedure position; The third type of judgment basis is the position distribution of the missing node in the procedure structure; the cloud monitoring platform judges whether the position distribution of the procedure missing node in the procedure structure satisfies the preset distribution constraint condition according to the dependency relationship between the predecessor procedure node identifier and the successor procedure node identifier in the procedure structure, for example: whether the procedure missing nodes appear continuously on the same main procedure, or whether the procedure missing nodes are concentrated in a certain procedure stage; when these distribution constraint conditions are met, the missing abnormality can also be triggered; The cloud monitoring platform comprehensively operates the above three types of judgment basis according to the preset logical relationship to form the condition judgment operation result; when the comprehensive result of the condition judgment operation satisfies the preset missing trigger condition, the cloud monitoring platform performs the abnormal behavior output operation to output the missing type abnormal behavior judgment result; when the condition judgment operation result does not satisfy the preset missing trigger condition, the cloud monitoring platform does not output the missing type abnormal behavior judgment result, but only retains the record of the procedure missing node set for subsequent statistics or trend judgment in the continuous period; through this joint judgment mode based on the number, keyness and position distribution of the procedure missing node, the cloud monitoring platform can accurately identify the missing type abnormal behavior that may affect the business execution at the procedure structure level.

[0023] An enterprise-level multi-source abnormal behavior monitoring system, comprising a structure generation module, a missing identification module, a state uploading module, a link extraction module and an abnormal judgment module; The structure generation module is configured to perform a flow structure analysis operation by the end-side device, and perform a set of expected behavior construction operation according to a function module, an interface call relationship and a flow rule deployed by the end-side device, so as to generate a set of end-side expected behaviors; The missing recognition module is configured to perform a matching calculation operation on actual behavior events collected in a running period by the end-side device, and perform a one-by-one comparison operation between the actual behavior events and the set of end-side expected behaviors, so as to identify target behaviors not covered by the actual behavior events, thereby generating a set of end-side missing behaviors; The state uploading module is configured to perform an end-cloud collaborative uploading operation on the set of end-side missing behaviors and the actual behavior events by the end-side device, so as to form an end-side expected behavior state input submitted to the cloud; The link extraction module is configured to perform a cross-node alignment calculation operation on a plurality of sets of end-side missing behaviors by a monitoring platform of the cloud, and perform a missing behavior mapping operation according to a dependent link existing in the flow structure, so as to generate a cross-node flow missing link; The abnormality judgment module is configured to perform a flow integrity judgment operation according to the cross-node flow missing link by the monitoring platform of the cloud, and output a missing-type abnormal behavior judgment result when any flow is in a missing state in the associated node.

[0024] Working principle: The monitoring process of the application is cooperatively performed by the end-side and the cloud; the end-side device first parses flow node identifiers, function module identifiers and predecessor and successor flow node identifiers according to flow structure definition data, and writes the parsed results into a flow node set and a flow transition relationship set respectively; then, in combination with the interface call relationship configured by the end-side, the end-side device calculates a corresponding interface call list for each flow node, generates a first behavior element set recording the flow node identifier, the function module identifier and the interface call list, and based on the flow rule and the flow transition relationship set, deduces the step order of the business flow, and writes the related behavior elements in order into the set of end-side expected behaviors, so as to construct a complete expected business behavior track on the end-side; During the business running period, the end-side device continuously collects actual behavior events, and writes the flow node identifiers, event interface identifiers and event time stamps in the events into an event node identifier set and an event interface mapping set after parsing; the end-side device takes the set of end-side expected behaviors as a reference, first performs a node coverage judgment on each expected behavior record, then performs an interface coverage judgment on the covered nodes, identifies flow nodes or interfaces not covered by any actual event in the running period, and forms a set of end-side missing behaviors; at the same time, the end-side device combines the missing behavior records and the actual event information associated therewith into expected behavior state records, and integrates them into a set of end-side expected behavior state inputs, and uploads them to the cloud monitoring platform through an end-cloud collaborative channel, forming a structured input that can be used for subsequent missing link inference; After the cloud monitoring platform receives the multiple end-side missing behavior sets of the end sides, a cloud missing behavior table indexed by process node identifiers is constructed, and cross-node alignment calculation is performed according to the table: whether a process node is repeatedly missing on multiple end-side devices, or whether its interface call is not triggered in the actual behavior events of multiple end sides, so as to mark it as a consistent missing node or an interface missing node; on this basis, the cloud monitoring platform performs forward and backward progressive extension on the missing nodes in combination with the predecessor and successor dependency relationship in the process structure, generates a missing path sequence composed of consecutive missing nodes, and merges, removes duplicates and checks according to the order relationship of the process structure in the path integration process, so as to obtain cross-node process missing links; finally, the cloud monitoring platform performs continuous missing comparison and missing trigger condition judgment according to the cross-node process missing links, generates the final missing type abnormal behavior judgment result for the process missing conditions that reach the continuous missing threshold or contain key nodes, and realizes accurate identification and alarm of cross-node missing type abnormalities.

[0025] The above only describes the preferred embodiments of the present application and is not used to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. An enterprise-level multi-source anomalous behavior monitoring method, characterized in that, Comprising: S1, performing a flow structure analysis operation by the end-side device, and constructing an expected behavior set according to the function modules deployed by the end-side device, the interface call relationship, and the flow rules to generate an end-side expected behavior set; S2, performing a matching calculation operation by the end-side device on the actual behavior events collected in the running period, and performing a one-by-one comparison operation between the actual behavior events and the end-side expected behavior set to identify target behaviors not covered by the actual behavior events, thereby generating an end-side missing behavior set; S3, performing an end-cloud collaborative uploading operation by the end-side device on the end-side missing behavior set and the actual behavior events to form an end-side expected behavior state input submitted to the cloud; S4, performing a cross-node alignment calculation operation by the monitoring platform in the cloud on a plurality of end-side missing behavior sets, and performing a missing behavior mapping operation according to the dependency links existing in the flow structure to generate a cross-node flow missing link; S5, performing a flow integrity judgment operation by the monitoring platform in the cloud according to the cross-node flow missing link, and outputting a missing-type abnormal behavior judgment result when any flow is in a missing state in the associated nodes in the cloud.

2. The enterprise-level multi-source abnormal behavior monitoring method according to claim 1, characterized in that: In S1, comprising: S1-1, performing a reading operation by the end-side device on the flow structure definition data for describing the flow nodes and their associated relationships, and performing a flow node analysis operation on each flow node read, and writing the flow node identifier, function module identifier, and predecessor flow node identifier and successor flow node identifier obtained by analysis into the flow node set and flow transfer relationship set in turn; S1-2, performing an interface relationship calculation operation by the end-side device according to the flow node identifier and function module identifier in the flow node set and the interface call relationship configured by the end-side device on each flow node in the flow node set, determining the interface call list corresponding to the flow node, and writing the flow node identifier, function module identifier, and interface call list into the first behavior element set according to a unified structure; S1-3, performing a sequence calculation operation by the end-side device on the flow transfer relationship set according to the flow rules, and performing a sorting operation on the predecessor flow node identifier and successor flow node identifier according to the flow rules to generate a flow step sequence; S1-4, performing an element sequence mapping calculation operation by the end-side device on the first behavior element set according to the flow step sequence, matching the corresponding behavior elements according to the flow node identifier in the flow step sequence in turn, and writing the matched behavior elements in order into the end-side expected behavior set.

3. The enterprise-level multi-source abnormal behavior monitoring method according to claim 2, characterized in that: In S2, comprising: S2-1, performing event analysis operation on each actual behavior event collected in the running period by the end-side device: sequentially resolving the flow node identifier, event interface identifier and event timestamp in each actual behavior event, and writing the resolved flow node identifier into the event node identifier set, and writing the resolved flow node identifier and the corresponding event interface identifier into the event interface mapping set according to the corresponding relationship; S2-2, performing matching calculation operation on the event node identifier set and the end-side expected behavior set by the end-side device: performing first matching determination operation on each expected behavior record in the end-side expected behavior set by taking the flow node identifier as the first matching key, marking the expected behavior record as a node uncovered state when there is no flow node identifier consistent with the flow node identifier in the event node identifier set, otherwise marking the expected behavior record as a node covered state; at the same time, for the expected behavior record marked as a node covered state, performing interface relationship comparison operation by the end-side device by taking the interface call list in the expected behavior record as the second matching key and taking the event interface identifier set corresponding to the flow node identifier in the event interface mapping set as the second matching object, marking the expected behavior record as an interface uncovered state when the intersection result of the interface relationship comparison operation is empty, otherwise marking the expected behavior record as an interface covered state; S2-3, performing missing behavior record writing operation on the expected behavior record marked as a node uncovered state or an interface uncovered state in the end-side expected behavior set by the end-side device, and writing the corresponding flow node identifier, function module identifier and interface call list into the end-side missing behavior set according to the unified structure; at the same time, for the expected behavior record marked as a node covered state and marked as an interface covered state, keeping its covered state by the end-side device to form the end-side covered behavior set, so that the end-side missing behavior set only records the target behavior not covered by any actual behavior event in the running period.

4. The enterprise-level multi-source abnormal behavior monitoring method according to claim 3, characterized in that: In S3, it comprises: S3-1, performing missing behavior traversal operation on the end-side missing behavior set by the end-side device, and reading the flow node identifier, function module identifier and interface call list in each missing behavior record, while performing event association retrieval operation on the actual behavior event collected in the running period, and writing the event interface identifier and event timestamp of the actual behavior event consistent with the flow node identifier in the event node identifier set into the expected behavior state record according to the corresponding relationship; S3-2, performing structure integration operation on all expected behavior state records by the end-side device, and writing the flow node identifier, function module identifier, interface call list, event interface identifier and event timestamp in each expected behavior state record into the end-side expected behavior state input set according to the unified structure; S3-3, performing end-cloud collaborative uploading operation on the end-side expected behavior state input set by the end-side device, transmitting the end-side expected behavior state input set to the cloud monitoring platform in the form of a data packet, so that the cloud monitoring platform obtains the input for subsequent calculation.

5. The enterprise-level multi-source abnormal behavior monitoring method of claim 4, further comprising: In S4, comprising: S4-1, performing sequential reading operation on the end-side missing behavior set from the plurality of end-side devices by the monitoring platform in the cloud, and reading the flow node identifier, function module identifier and interface call list in each missing behavior record, while recording the end-side device identifier to which the missing behavior record belongs, writing the missing conditions of the same flow node identifier under different end-side device identifiers into the cloud missing behavior reference table according to the corresponding relationship, so that the cloud missing behavior reference table records the missing conditions of each end-side device according to the flow node identifier; S4-2, performing cross-node alignment calculation operation on the cloud missing behavior reference table according to the flow node identifier by the monitoring platform in the cloud, and performing consistency judgment on the missing records under different end-side device identifiers for each flow node identifier; when there are missing records under two or more end-side device identifiers for a flow node identifier, the flow node identifier is marked as a consistent missing node; when there is only one missing record under an end-side device identifier for any flow node identifier, the monitoring platform in the cloud performs interface consistency judgment on the interface call list under different end-side device identifiers for the flow node identifier; when the interface call in the interface call list does not appear under two or more end-side device identifiers, the flow node identifier is marked as an interface missing node; when the node consistency and the interface consistency are not satisfied, the monitoring platform in the cloud keeps the inconsistent missing state of the flow node identifier as the termination condition for subsequent path calculation; S4-3, performing path expansion operation on the flow node identifier marked as a consistent missing node or an interface missing node according to the dependency relationship between the predecessor flow node identifier and the successor flow node identifier in the flow structure by the monitoring platform in the cloud, taking any marked flow node identifier as the expansion starting point, and performing progressive expansion to its predecessor flow node identifier and successor flow node identifier; when the flow node identifier obtained by progressive expansion belongs to a consistent missing node or an interface missing node, continue to expand, when the flow node identifier obtained by progressive expansion belongs to a non-consistent missing state, stop expanding, thereby forming a number of missing path sequences composed of adjacent missing nodes.

6. The enterprise-level multi-source abnormal behavior monitoring method of claim 5, further comprising: In S4, further comprising: S4-4, performing path integration operation on the missing path sequence by the monitoring platform in the cloud, merging the missing path sequence in which the predecessor flow node identifier and the successor flow node identifier are continuous in the flow structure according to the arrangement order of the flow node identifier, performing repeated record elimination operation and sequence verification operation on the merged flow node identifier sequence, generating a cross-node flow missing link composed of multiple continuous missing nodes, and writing the cross-node flow missing link into the cross-node flow missing link set.

7. The enterprise-level multi-source abnormal behavior monitoring method according to claim 6, characterized in that: S5 includes: S5-1, performing flow integrity judgment operation on the cross-node flow missing link by the monitoring platform in the cloud: taking each flow node identifier in the cross-node flow missing link as a judgment object, performing missing state reading operation on the missing state of the flow node identifier in the cross-node flow missing link, and performing continuous missing comparison operation on the missing state and the missing state corresponding to the predecessor flow node identifier and the successor flow node identifier of the flow node identifier in the flow structure, when the result of the continuous missing comparison operation shows that any flow node identifier presents a continuous missing state in the predecessor direction or the successor direction, marking the flow node identifier as a flow missing node; S5-2, performing flow missing node recording operation on the flow node identifier marked as a flow missing node by the monitoring platform in the cloud, writing the flow node identifier into the flow missing node set, and performing condition judgment operation on the record number of the flow missing node set and the preset missing trigger condition, when the result of the condition judgment operation meets the preset missing trigger condition, performing abnormal behavior output operation by the monitoring platform in the cloud, and outputting the missing-type abnormal behavior judgment result.

8. An enterprise-level multi-source abnormal behavior monitoring system, comprising a structure generation module, a missing identification module, a state uploading module, a link extraction module and an abnormal judgment module, characterized in that: The structure generation module is used for performing flow structure analysis operation by the end-side device, and performing expected behavior set construction operation according to the function module, interface calling relationship and flow rule deployed by the end-side device, to generate the end-side expected behavior set; The missing identification module is used for performing matching calculation operation on the actual behavior events collected in the running period by the end-side device, and performing item-by-item comparison operation on the actual behavior events and the end-side expected behavior set, to identify the target behavior not covered by the actual behavior events, thereby generating the end-side missing behavior set; The state uploading module is used for performing end-cloud cooperative uploading operation on the end-side missing behavior set and the actual behavior events by the end-side device, to form the end-side expected behavior state input submitted to the cloud; The link extraction module is used for performing cross-node alignment calculation operation on the multiple end-side missing behavior sets by the monitoring platform in the cloud, and performing missing behavior mapping operation according to the dependent link existing in the flow structure, to generate the cross-node flow missing link; The abnormality determination module is used for performing a process integrity judgment operation according to a missing link of a cross-node process by a monitoring platform in the cloud, and outputting a missing-type abnormal behavior determination result when any process is in a missing state in the associated node.

Images