Security event scheduling method and device, equipment and storage medium
By obtaining event data of security events in the SOAR engine and determining their threat level and priority, the problem of lack of consideration of factors such as permissions, tenants, script weights and other factors in the existing technology is solved, and efficient, flexible scheduling and rapid response to security events is achieved.
Patent Information
- Application Number
- CN202411613409.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-12
- Publication Date
- 2025-03-11
AI Technical Summary
When scheduling security events, the existing SOAR engine lacks considerations for factors such as permissions, tenants, script weights, etc., and cannot meet the requirements of responding to scripts quickly and flexibly to handle security events.
By obtaining event data of security events, determining their threat level and priority, and scheduling and processing based on this information. The specific steps include: obtaining event data, determining the degree of threat, determining priority based on the degree of threat and other factors, and finally scheduling and processing based on the priority.
It realizes efficient and flexible scheduling of real threat security incidents, ensures the security and compliance of scheduling, and can respond quickly and flexibly to high-priority security incidents.
Smart Images

Figure CN119598449A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing technology, and in particular to a security event scheduling method, device, equipment and storage medium. Background Art
[0002] Security Orchestration, Automation and Response (SOAR engine) is a technology used to help users collect, analyze and respond to security incidents. The SOAR engine processes various information monitored by the security operation and maintenance team in an automated and semi-automated manner, defines, sorts and triggers standardized incident response activities, thereby improving the efficiency and accuracy of security incident processing.
[0003] Traditional SOAR engines usually schedule script tasks by polling. However, when SOAR engines in the prior art process security incidents, they lack consideration of various factors such as permissions, tenants, and script weights, and cannot meet the requirements of fast and flexible response scripts to process security incidents.
[0004] Therefore, how to efficiently and flexibly schedule security events is the problem that needs to be solved at present. Summary of the invention
[0005] The present application provides a security event scheduling method, apparatus, device and storage medium to solve the problem that the existing SOAR engine cannot flexibly and efficiently schedule security events.
[0006] In a first aspect, the present application provides a security event scheduling method, the method comprising:
[0007] Acquire event data of a security event, and determine the threat level of the security event based on the event data;
[0008] When the threat level is greater than a preset threshold, determining the priority of the security event according to the event data;
[0009] The security event is scheduled and processed based on the priority of the security event.
[0010] In a possible implementation, the event data includes: an attribute label and a tenant weight corresponding to the security event, and determining the priority of the security event according to the event data includes:
[0011] Determine label matching information according to the attribute label and the process label corresponding to the full process, wherein the label matching information includes: N first process labels matching the attribute label among the multiple process labels, and a process weight corresponding to each first process label;
[0012] Based on the event execution parameters of N first processes relative to the security event within a preset time period, determining a target process from the N first processes, wherein the N first processes are processes corresponding to the N first process labels, and the target process is a process with the best event execution parameters among the N first processes;
[0013] The priority of the security event is determined based on the tag matching information, the tenant weight, and the process weight corresponding to the target process.
[0014] In a possible implementation, before determining the priority of the security event based on the tag matching information, the tenant weight, and the corresponding process weight of the target process, the method further includes:
[0015] Determining whether the target process requires manual audit;
[0016] In the case where it is determined that the target process needs to be manually audited, determining an audit step weight of the target process, wherein the audit step weight is determined according to the number of audit steps;
[0017] The determining the priority of the security event based on the tag matching information, the tenant weight, and the corresponding process weight of the target process includes:
[0018] The priority of the security event is determined based on the tag matching information, the tenant weight, the audit step weight, and the corresponding process weight of the target process.
[0019] In a possible implementation, the event data includes: occurrence time, occurrence location, event type, and tenant information. Determining the threat level of the security event based on the event data includes:
[0020] Determining a first threat parameter according to the tenant information, the occurrence time, and the occurrence location;
[0021] Determining a second threat parameter according to the event type and the security event sensitivity list;
[0022] A threat level of the security event is determined based on the first threat parameter and the second threat parameter.
[0023] In a possible implementation, the scheduling and processing of the security event based on the priority of the security event includes:
[0024] Determine whether the number of pending events in the task queue has reached a preset number;
[0025] If yes, scheduling and processing the security event according to the priority of the security event and the priority of the pending events in the task queue;
[0026] If not, the security event is added to the task queue according to the priority of the security event to schedule the security event.
[0027] In a possible implementation, scheduling the security event according to the priority of the security event and the priority of the pending events in the task queue includes:
[0028] Determine whether the priority of the security event is greater than the priority of the last pending event in the task queue, and sort the pending events in the task queue according to their priority;
[0029] If yes, suspend the pending event at the last position and add the security event to the task queue;
[0030] If not, the security event is suspended for processing until the priority of the security event is greater than the priority of the last event to be processed in the task queue.
[0031] In a possible implementation, the method further includes:
[0032] After the security event is executed, an audit request is sent to the auditor, and the security event is suspended, wherein the audit request is used to instruct manual audit processing of the security event;
[0033] Receive the audit results fed back by the auditors;
[0034] When the audit result indicates that the manual audit is passed, updating and storing the event status of the security event;
[0035] When the audit result indicates that the manual audit has not passed, the execution procedure of the security event is terminated.
[0036] In a second aspect, the present application provides a security event scheduling device, the device comprising:
[0037] An acquisition module, used to acquire event data of security events;
[0038] a processing module for determining the threat level of the security event based on the event data; when the threat level is greater than a preset threshold, determining the priority of the security event according to the event data; and scheduling the security event based on the priority of the security event.
[0039] In one possible implementation, the event data includes: an attribute tag and a tenant weight corresponding to the security event, and the processing module is specifically used to determine the tag matching information based on the attribute tag and the process tag corresponding to the full process, wherein the tag matching information includes: N first process tags among multiple process tags that match the attribute tag, and the process weight corresponding to each first process tag; based on the event execution parameters of the N first processes relative to the security event within a preset time period, determining the target process from the N first processes, wherein the N first processes are processes corresponding to the N first process tags, and the target process is the process with the best event execution parameters among the N first processes; determining the priority of the security event based on the tag matching information, the tenant weight and the process weight corresponding to the target process.
[0040] In a possible implementation, the processing module is further used to determine whether the target process needs to be manually audited; if it is determined that the target process needs to be manually audited, determine the audit step weight of the target process, where the audit step weight is determined according to the number of audit steps;
[0041] The processing module is specifically used to determine the priority of the security event based on the tag matching information, the tenant weight, the audit step weight and the corresponding process weight of the target process.
[0042] In a possible implementation, the event data includes: the time of occurrence, the location of occurrence, the event type, and tenant information.
[0043] In one possible implementation, the processing module is specifically used to determine a first threat parameter based on the tenant information, the time of occurrence, and the location of occurrence; determine a second threat parameter based on the event type and the security event sensitivity list; and determine the threat level of the security event based on the first threat parameter and the second threat parameter.
[0044] In a possible implementation, the device further includes: a judgment module;
[0045] The determination module is used to determine whether the number of pending events in the task queue has reached a preset number;
[0046] The processing module is used to schedule and process the security event according to the priority of the security event and the priority of the event to be processed in the task queue when the number of events to be processed in the task queue reaches a preset number;
[0047] When the number of pending events in the task queue does not reach a preset number, the security event is added to the task queue according to the priority of the security event, so as to schedule the security event for processing.
[0048] In a possible implementation, the judgment module is further used to judge whether the priority of the security event is greater than the priority of the last pending event in the task queue, and the pending events in the task queue are sorted according to the priority;
[0049] The processing module is specifically used for suspending the last pending event in the task queue when the priority of the security event is greater than the priority of the last pending event in the task queue, and adding the security event to the task queue;
[0050] When the priority of the security event is not greater than the priority of the last pending event in the task queue, the security event is suspended until the priority of the security event is greater than the priority of the last pending event in the task queue.
[0051] In a possible implementation, the device further includes: a transceiver module;
[0052] The transceiver module is used to send an audit request to the auditor after the security event is completed;
[0053] The processing module is further used to suspend the security event after sending an audit request to the auditor, wherein the audit request is used to instruct manual audit processing of the security event;
[0054] The transceiver module is also used to receive the audit results fed back by the auditor;
[0055] The processing module is further configured to update and store the event status of the security event when the audit result indicates that the manual audit has passed;
[0056] When the audit result indicates that the manual audit has not passed, the execution procedure of the security event is terminated.
[0057] In a third aspect, the present application provides a security event scheduling device, including: a memory, a processor, and a communication interface;
[0058] Wherein, the memory stores computer-executable instructions, and the communication interface is used to communicate with other devices via a transmission medium;
[0059] The processor executes the computer-executable instructions stored in the memory to implement the security event scheduling method as described in the first aspect and various possible implementation methods of the first aspect.
[0060] In a fifth aspect, the present application provides a computer storage medium having computer execution instructions stored thereon, wherein the computer execution instructions are executed by a processor to implement the security event scheduling method as described in the first aspect and various possible implementation methods of the first aspect.
[0061] In a sixth aspect, the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the security event scheduling method as described in the first aspect and various possible implementation methods of the first aspect.
[0062] The present application provides a method, device, equipment and storage medium for scheduling security events. The method obtains event data of security events and determines the threat level of the security events based on the event data; when the threat level is greater than a preset threshold, the priority of the security events is determined according to the event data; based on the priority of the security events, the security events are scheduled and processed; since the method only schedules and processes security events that are real threats, the security and compliance of the scheduling are ensured, and since the scheduling is performed based on the priority, a fast and flexible response to security events with high priority can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS
[0063] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0064] Figure 1 A schematic diagram of a security event scheduling method provided in an embodiment of the present application Figure 1 ;
[0065] Figure 2 A schematic diagram of a security event scheduling method provided in an embodiment of the present application Figure 2 ;
[0066] Figure 3 A schematic diagram of the structure of a security event scheduling device provided in this application;
[0067] Figure 4 A schematic diagram of the structure of a security event scheduling device provided in this application.
[0068] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION
[0069] In order to make the purpose, technical solutions and advantages of this application clearer, the technical solutions in this application will be clearly and completely described below in conjunction with the drawings in this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0070] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present invention and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in sequences other than those illustrated or described herein.
[0071] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.
[0072] Security Orchestration, Automation and Response (SOAR engine) is a technology used to help users collect, analyze and respond to security incidents. The SOAR engine processes various information monitored by the security operation and maintenance team in an automated and semi-automated manner, defines, sorts and triggers standardized incident response activities, thereby improving the efficiency and accuracy of security incident processing.
[0073] Traditional SOAR engines usually schedule script tasks by polling. However, when SOAR engines in the prior art process security incidents, they lack consideration of various factors such as permissions, tenants, and script weights, and cannot meet the requirements of fast and flexible response scripts to process security incidents.
[0074] Therefore, how to efficiently and flexibly schedule security events is the problem that needs to be solved at present.
[0075] In response to the above problems, the embodiments of the present application provide a method for scheduling security events, which first determines whether a security event is a real threat, and when the security event is determined to be a real threat, determines the corresponding priority based on the event data, and then schedules the security event based on the priority. Since the method only schedules security events that are real threats, the security and compliance of the scheduling are ensured, and since the scheduling is performed based on the priority, it is possible to respond quickly and flexibly to security events with high priority.
[0076] The following specific embodiments are used to describe in detail the technical solution of the present application and how the technical solution of the present application solves the above technical problems. The following specific embodiments can be implemented independently or in combination with each other, and the same or similar concepts or processes may not be described in detail in some embodiments.
[0077] Figure 1 A schematic diagram of a security event scheduling method provided in an embodiment of the present application Figure 1 .
[0078] like Figure 1 As shown, the security event scheduling method provided in this embodiment includes:
[0079] S101: Acquire event data of a security event, and determine the threat level of the security event based on the event data.
[0080] The event data may include, for example, the time and location of the corresponding security event, and the corresponding tenant.
[0081] The event data of a security event may be, for example, data read from a message queue, or data read from a log file, or data uploaded by a third party calling an API interface, and this application does not impose any restrictions on this.
[0082] It is understandable that in actual scenarios, threat scenarios are constantly changing dynamically, so there may be some non-real security threat events.
[0083] After acquiring the event data, a threat analysis can be performed on the security event based on the event data to determine whether the security event is a real threat event. If the security event is a real threat event, it is determined that the security event will be scheduled for processing; if the security event is not a real threat event, there is no need to schedule the security event.
[0084] When analyzing security incidents, the analysis can be based on multiple dimensions. For example, based on the event data, it can be determined whether the security incident is within the scope of permitted authority execution, or whether the tenant corresponding to the security incident is within the contract period, etc.
[0085] S102: When the threat level is greater than a preset threshold, determining the priority of the security event according to the event data.
[0086] The preset threshold value may be determined based on historical data or the event type of the security event. The priority of the security event is used to indicate the order in which the security event is executed.
[0087] When the threat level is greater than the preset threshold, it indicates that the security event is a real threat event, and the security event needs to be scheduled and processed.
[0088] The priority can be determined based on, for example, the permission control of the security incident, the importance of the tenant, the process requirements, and other dimensions. Please see below for the specific determination process.
[0089] S103: Scheduling the security event based on the priority of the security event.
[0090] After the priority of the security event is determined, the security event can be scheduled and processed based on the priority.
[0091] It is understandable that, for example, multiple security events can be divided into critical events and non-critical events according to the priority of the security events. When scheduling security events, critical events can be scheduled first, and non-critical events can be scheduled after the critical events are executed.
[0092] Or based on the priorities of multiple security events, they are executed in descending order of priority.
[0093] The security event scheduling method provided in this embodiment obtains event data of a security event, and determines the threat level of the security event based on the event data; when the threat level is greater than a preset threshold, determines the priority of the security event based on the event data; and schedules the security event based on the priority of the security event. Since the method only schedules security events that are real threats, the security and compliance of the scheduling are ensured, and since the scheduling is performed based on the priority, a fast and flexible response to high-priority security events can be achieved.
[0094] Figure 2 A schematic diagram of a security event scheduling method provided in an embodiment of the present application Figure 2 The event data in this embodiment includes: the time of occurrence, the location of occurrence, the event type, tenant information, attribute tags, and the tenant weight corresponding to the security event; Figure 1 Based on the embodiment, a possible implementation of the security event scheduling method is described in detail. Figure 2 As shown, the security event scheduling method shown in this embodiment includes:
[0095] S201: Determine a first threat parameter according to tenant information, occurrence time, and occurrence location.
[0096] The tenant information may include, for example, the contract period corresponding to the tenant, the scope of event execution authority authorized by the tenant, the tenant's automatic disposal authority, and the assets corresponding to the tenant, etc. The location of occurrence is used to indicate the location of the attacking IP and / or the destination IP in the security incident.
[0097] In this step, the specific manner of determining the first threat parameter may include, for example, at least one of the following:
[0098] A) Determine whether the tenant corresponding to the security incident is currently within the contract period based on the time of occurrence of the security incident and the contract period corresponding to the tenant;
[0099] B) According to the tenant's automatic handling authority, determine whether the tenant corresponding to the security incident has enabled the automatic handling authority;
[0100] C) Determine whether the security event is within the permitted execution authority scope based on the event type of the security event and the event execution authority scope authorized by the tenant;
[0101] D) Determine whether the attacking IP or target IP of the security incident is the tenant's asset based on the tenant's corresponding assets and the location of the security incident.
[0102] The results of the above-mentioned multiple specific methods can be used as the first threat parameter alone, or can be combined to obtain the first threat parameter. It can be understood that when the more dimensions are used to determine the first threat parameter, the more accurate the first threat parameter is.
[0103] S202: Determine a second threat parameter according to the event type and the security event sensitivity list.
[0104] The security event sensitive list includes a variety of event types, such as shell, injection, execution, zombie, Trojan, virus, command and other event types.
[0105] In this step, for example, it can be determined whether the event type of the security event is in the security event sensitive list. If it is, the second threat parameter can be determined based on the weight of the event type of the security event in the security event sensitive list.
[0106] It is understandable that the weights of multiple event types in the security event sensitive list may be the same or different. It is determined by the threat level of the event type to security. For example, the threat level of Trojan horse events to security is greater than that of execution events, so the weight of Trojan horse events in the security event sensitive list is greater than that of execution events.
[0107] S203: Determine the threat level of the security event based on the first threat parameter and the second threat parameter.
[0108] The threat level of a security incident may be determined, for example, by the following formula:
[0109] R=P(a1)*P(a2)*P(b)*P(c)+P(d)
[0110] Among them, R is the threat level of the security incident, P(a1) is used to indicate whether the tenant is within the contract period, P(a2) is used to indicate whether the tenant has opened the automatic disposal permission, P(b) is used to indicate whether the attack IP in the security incident is the tenant's asset, P(c) is used to indicate whether the target IP in the security incident is the tenant's asset, and P(d) is used to indicate whether the event type of the security incident is in the security incident sensitive list.
[0111] It can be understood that P(a1)∈{01}, P(a2)∈{01}, P(b)∈{01}, P(c)∈{01}, P(d)∈[0,1]. The value range of R is: R∈[0,2].
[0112] S204: When the threat level is greater than a preset threshold, determine label matching information according to the attribute label and the process label corresponding to the full process.
[0113] The label matching information includes: N first process labels that match the attribute label among the multiple process labels, and a process weight corresponding to each first process label.
[0114] The attribute tag may indicate the type or attribute of the security event. The process may refer to a script program running on a device. Different processes correspond to different tasks. For example, if the task is written in Python, the Python process needs to be called to process it. If the task is written in JavaScript, the JavaScript process needs to be called to process it. If the task is written in shell, the shell process needs to be called to process it.
[0115] Different processes will be assigned at least one matching process tag before executing a task, such as exec=shell, exec=sql, payload=http, payload=insert, type=execution, etc. After each process executes a task, the execution result will be recorded and stored for subsequent statistics of the execution status of each process relative to security events.
[0116] After determining the threat level of a security incident, it is also necessary to determine whether the security incident is a real threat incident.
[0117] It can be understood that if R∈(1,2], it means that P(a1), P(a2), P(b) and P(c) are all 1, that is, the tenant has enabled the automatic disposal permission, the tenant is within the contract period, and the target IP and the attack IP are both the tenant's own assets. In other words, the security incident is more likely to be the tenant's own operation. Therefore, it is determined that the security incident is not a real threat incident, and the security incident can be scheduled for processing.
[0118] If R∈[0,1], it means that at least one parameter among P(a1), P(a2), P(b) and P(c) has a value of 0, which means that the security event may not be an operation of the tenant itself. Therefore, it is necessary to determine whether the security event is a real threat event based on the configured preset threshold.
[0119] The value range of the preset threshold may be, for example, [0.5, 1]. If R is within the value range of the preset threshold, it is determined whether the security event is a real threat event. At this time, it is necessary to determine the label matching information of the security event based on the attribute label and the process label corresponding to the full process.
[0120] The specific method of determining the label matching information in this step may be, for example: based on the attribute label, determining N first process labels that match the attribute label from all process labels.
[0121] S205: Determine a target process from the N first processes based on event execution parameters of the N first processes relative to the security event within a preset time period.
[0122] The N first processes are processes corresponding to the N first process labels, and the target process is a process with the best event execution parameters among the N first processes.
[0123] The preset time period may be, for example, within an hour, within a day, within a week, etc., and this application does not impose any limitation on this.
[0124] The event execution parameters are used to indicate the execution status of the security event in the historical moment, such as the total number of executions, the execution result of each execution, etc.
[0125] S206: Determine the priority of the security incident based on the tag matching information, the tenant weight, and the process weight corresponding to the target process.
[0126] In this step, the following formula can be used to determine the priority of the security incident:
[0127]
[0128] in, is the sum of the weights of the N first process labels that match the security event, α i is the process weight corresponding to the first process label of the i-th process, α i It will increase as the number of hits of the tag increases; is the sum of the weights of the M first process labels that match the security event within the preset period, ∑Label i is the sum of hits of the i-th first process label within the preset period;
[0129] β j is the occurrence weight of the security event within the preset period, β j It will increase as the number of times the security event occurs increases. j is the number of occurrences of the security event within the preset period. is the total number of security events that occur within the preset period, Time is the current time, EventTime is the last time the security event occurred, γ is the tenant weight, and δ is the process weight corresponding to the target process.
[0130] In a possible implementation, if the target process is a process that requires manual audit, the weight corresponding to the manual audit needs to be fully considered when determining the priority of the security event, as follows:
[0131] Determine whether the target process requires manual audit;
[0132] When it is determined that the target process requires manual audit, the audit step weight of the target process is determined.
[0133] Among them, the audit step weight is determined according to the number of audit steps. It is understandable that the number of manual audit steps corresponding to security incidents of different threat levels is different, and the audit content may also be different.
[0134] If it is determined that a manual audit is required, the priority of the security incident can be determined based on the tag matching information, tenant weight, audit step weight, and the corresponding process weight of the target process.
[0135] Specifically, the following formula can be used to determine the priority of security events:
[0136]
[0137] Among them, ε k Audit step for the target process k The weight of the audit is L, and L is the number of steps for manual audit.
[0138] S207: Determine whether the number of pending events in the task queue has reached a preset number; if so, execute step S208; if not, execute step S209.
[0139] When it is determined that the security event can be executed, the security event needs to be put into the task queue to schedule the pending events in the task queue.
[0140] The task queue contains multiple pending events, which can be existing security events or newly added security events. The pending events in the task queue all have corresponding priorities, and they are sorted in the task queue from high to low priority. That is, when executing security events, the pending events are scheduled according to the priority sorting in the task queue.
[0141] The upper limit of the pending events contained in the task queue may be, for example, A, and the preset number may be, for example, A, or a value corresponding to a certain proportion of A, such as 0.85A or 0.9A.
[0142] After determining the priority of the security event, it is necessary to first determine whether the number of pending events in the task queue has reached a preset number, that is, to determine whether there is any free space in the task queue to place the security event.
[0143] S208: Scheduling the security event according to the priority of the security event and the priority of the pending events in the task queue.
[0144] If the number of pending events in the task queue reaches a preset number, it indicates that there is no free space in the task queue to place the security event. At this time, it is necessary to determine the priority of the pending events in the task queue, and then schedule the security event according to the priority of the pending events in the task queue and the priority of the security event.
[0145] In a possible implementation, based on the priority of the pending event in the task queue and the priority of the security event, a specific implementation of scheduling the security event may include, for example:
[0146] First determine whether the priority of the security event is greater than the priority of the last pending event in the task queue.
[0147] Among them, since the pending events in the task queue are sorted according to the priority, the priority of the pending event at the end is the lowest.
[0148] If the priority of the security event is greater than the priority of the last pending event in the task queue, it means that the scheduling urgency of the security event is higher than that of the last pending event. At this time, the last pending event needs to be suspended and the security event needs to be added to the task queue.
[0149] If the priority of the security event is not greater than the priority of the last pending event in the task queue, it means that the scheduling urgency of the security event is ranked after the last pending event. At this time, the security event can be suspended until the priority of the security event is greater than the priority of the last pending event in the task queue.
[0150] It can be understood that when a security event is placed in a task queue, it is not placed at the end of the task queue. Instead, the placement of the security event is determined based on the order of priority of multiple pending events (including the security event) in the current task queue. It may be placed in the first place, in the middle, or at the end.
[0151] S209: Add the security event to the task queue according to the priority of the security event to schedule and process the security event.
[0152] If the number of pending events in the task queue does not reach the preset number, it means that there is currently an empty position in the task queue to place the security event. At this time, you only need to put the security event into the task queue. Its specific placement position may be at the first position, the middle position, or the last position.
[0153] In a possible implementation, since some processes need to be manually audited, after the security event is executed, for the processes that need to be manually audited, an audit request can be sent to the auditor and the security event can be suspended.
[0154] The audit request is used to instruct manual audit processing of security events.
[0155] After receiving the audit results fed back by the auditors, it can be determined whether to terminate the security incident or update the event status of the security incident based on the audit results.
[0156] It can be understood that the audit result is used to indicate whether the manual audit has passed. When the audit result indicates that the manual audit has passed, it means that the security incident has been processed and the processing result is correct. At this time, the event status of the security incident can be updated, and the event data corresponding to the updated security incident can be stored in the database to provide data support for the subsequent execution of the security incident;
[0157] When the audit result indicates that the manual audit has not passed, the execution procedure of the security event is terminated.
[0158] An embodiment of the present application provides a security event scheduling method. The method determines whether a security event is a real threat event from multiple dimensions, so that the real threat events to be scheduled are more accurate and more secure. At the same time, the method determines the priority of security events based on dimensions such as permission control, tenant weight, process, and security policy, so that the priority determination of security events is more accurate, thereby providing strong support for the subsequent flexible scheduling of security events of different priorities, and improving the execution efficiency and flexibility of time scheduling. In addition, the method introduces a manual audit procedure to further improve the security of security events.
[0159] This embodiment provides a security event scheduling device. Figure 3 This is a schematic diagram of the structure of a security event scheduling device provided in an embodiment of the present application. Figure 3 As shown, the security event scheduling device 300 provided in this embodiment includes:
[0160] The acquisition module 301 is used to acquire event data of security events;
[0161] The processing module 302 is used to determine the threat level of the security event based on the event data, and when the threat level is greater than a preset threshold, determine the priority of the security event according to the event data, and schedule the security event based on the priority of the security event.
[0162] In one possible implementation, the event data includes: an attribute tag and a tenant weight corresponding to the security event, and the processing module 302 is specifically used to determine the tag matching information based on the attribute tag and the process tag corresponding to the full process, wherein the tag matching information includes: N first process tags among multiple process tags that match the attribute tag, and the process weight corresponding to each first process tag; based on the event execution parameters of the N first processes relative to the security event within a preset time period, determining the target process from the N first processes, wherein the N first processes are processes corresponding to the N first process tags, and the target process is the process with the best event execution parameters among the N first processes; determining the priority of the security event based on the tag matching information, the tenant weight and the process weight corresponding to the target process.
[0163] In a possible implementation, the processing module 302 is further used to determine whether the target process needs to be manually audited; if it is determined that the target process needs to be manually audited, determine the audit step weight of the target process, where the audit step weight is determined according to the number of audit steps;
[0164] The processing module 302 is specifically used to determine the priority of the security event based on the tag matching information, the tenant weight, the audit step weight, and the corresponding process weight of the target process.
[0165] In a possible implementation, the event data includes: the time of occurrence, the location of occurrence, the event type, and tenant information.
[0166] In one possible implementation, the processing module 302 is specifically used to determine a first threat parameter based on the tenant information, the time of occurrence, and the location of occurrence; determine a second threat parameter based on the event type and the security event sensitive list; and determine the threat level of the security event based on the first threat parameter and the second threat parameter.
[0167] In a possible implementation, the device further includes: a determination module 303;
[0168] The determination module 303 is used to determine whether the number of pending events in the task queue has reached a preset number;
[0169] The processing module 302 is used to schedule the security event according to the priority of the security event and the priority of the event to be processed in the task queue when the number of events to be processed in the task queue reaches a preset number;
[0170] When the number of pending events in the task queue does not reach a preset number, the security event is added to the task queue according to the priority of the security event, so as to schedule the security event for processing.
[0171] In a possible implementation, the judgment module 303 is further used to judge whether the priority of the security event is greater than the priority of the last pending event in the task queue, and the pending events in the task queue are sorted according to the priority;
[0172] The processing module 302 is specifically used for suspending the last pending event in the task queue when the priority of the security event is greater than the priority of the last pending event in the task queue, and adding the security event to the task queue;
[0173] When the priority of the security event is not greater than the priority of the last pending event in the task queue, the security event is suspended until the priority of the security event is greater than the priority of the last pending event in the task queue.
[0174] In a possible implementation, the device further includes: a transceiver module 304;
[0175] The transceiver module 304 is used to send an audit request to the auditor after the security event is completed;
[0176] The processing module 302 is further used to suspend the security event after sending an audit request to the auditor, wherein the audit request is used to instruct manual audit processing of the security event;
[0177] The transceiver module 304 is also used to receive the audit results fed back by the auditor;
[0178] The processing module 302 is further configured to update and store the event status of the security event when the audit result indicates that the manual audit has passed;
[0179] When the audit result indicates that the manual audit has not passed, the execution procedure of the security event is terminated.
[0180] A security event scheduling device provided in this embodiment can execute the security event scheduling method provided in the above method embodiment. Its implementation principle and technical effect are similar, and this embodiment will not be described in detail here.
[0181] Figure 4 This is a schematic diagram of the structure of a security event scheduling device provided in an embodiment of the present application. Figure 4As shown, the security event scheduling device 400 may include at least one processor 401, at least one storage medium 402, and a communication interface 403. Among them, at least one processor 401 is used to implement the security event scheduling method provided in the above embodiment of the present application.
[0182] At least one memory 402 is used to store program instructions and / or data. The memory 402 is coupled to the processor 401. The coupling in the embodiment of the present application is an indirect coupling or communication connection between devices, units or modules, which can be electrical, mechanical or other forms, and is used for information exchange between devices, units or modules. The processor 401 may operate in conjunction with the memory 402. The processor 401 may execute program instructions stored in the memory 402. At least one of the at least one memory may be included in the processor.
[0183] The communication interface 403 is used to communicate with other devices through a transmission medium, so that the security event scheduling device 400 can communicate with other devices. The communication interface 403 can be, for example, a transceiver, an interface, a bus, a circuit, or a device capable of implementing a transceiver function. The processor 401 can use the communication interface 403 to send and receive data and / or information, and is used to implement the method provided in the above embodiment of the present application. Please refer to the detailed description in the previous embodiment for details, which will not be repeated here.
[0184] The specific connection medium between the processor 401, the memory 402 and the communication interface 403 is not limited in the embodiment of the present application. Figure 4 In the embodiment, the processor 401, the memory 402 and the communication interface 403 are connected via a bus 404. The bus 404 is Figure 4 The connection between other components is only for schematic illustration and is not intended to be limiting. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.
[0185] It should be understood that the processor in the embodiment of the present application can be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method embodiment can be completed by the hardware integrated logic circuit or software instructions in the processor. The above processor can be a general processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiment of the present application can be directly embodied as a hardware decoding processor to perform, or the hardware and software modules in the decoding processor can be combined to perform. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.
[0186] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), and direct RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0187] In an embodiment of the present application, a computer storage medium is also provided, on which computer execution instructions are stored. When the computer execution instructions are executed by a processor, the technical solution of the above-mentioned security event scheduling method embodiment is implemented. The implementation principle and technical effect are similar and will not be repeated here.
[0188] A computer program product is also provided in an embodiment of the present application, including a computer program. When the computer program is executed by a processor, the technical solution of the above-mentioned security event scheduling method embodiment is implemented. The implementation principle and technical effect are similar and will not be repeated here.
[0189] Those of ordinary skill in the art will appreciate that the various illustrative logical blocks and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or in combination with computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. The steps in the several embodiments provided in this application can be implemented by different execution units or execution modules, or by different devices. It should be understood that the disclosed apparatus, device and method can be implemented in other ways. For example, the method embodiments described above are merely illustrative. For example, multiple steps in the method embodiments can be implemented by multiple units or modules of the corresponding apparatus. The division of units in the apparatus is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, which may be electrical, mechanical or other forms.
[0190] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0191] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0192] In the above-described embodiments, the functions of each functional unit can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions (programs). When the computer program instructions (programs) are loaded and executed on a computer, the flow or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital video disc (DVD)), or a semiconductor medium (e.g., a solid state drive (SSD)), etc.
[0193] If this function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.
[0194] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.
[0195] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
Claims
1. A security event scheduling method, characterized in that: The method comprises: Acquire event data of a security event, and determine the threat level of the security event based on the event data; When the threat level is greater than a preset threshold, determining the priority of the security event according to the event data; The security event is scheduled and processed based on the priority of the security event.
2. The method according to claim 1, characterized in that The event data includes: an attribute label and a tenant weight corresponding to the security event, and determining the priority of the security event according to the event data includes: Determine label matching information according to the attribute label and the process label corresponding to the full process, wherein the label matching information includes: N first process labels matching the attribute label among the multiple process labels, and a process weight corresponding to each first process label; Based on the event execution parameters of N first processes relative to the security event within a preset time period, determining a target process from the N first processes, wherein the N first processes are processes corresponding to the N first process labels, and the target process is a process with the best event execution parameters among the N first processes; The priority of the security event is determined based on the tag matching information, the tenant weight, and the process weight corresponding to the target process.
3. The method according to claim 2, characterized in that Before determining the priority of the security event based on the tag matching information, the tenant weight, and the corresponding process weight of the target process, the method further includes: Determining whether the target process requires manual audit; In the case where it is determined that the target process needs to be manually audited, determining an audit step weight of the target process, wherein the audit step weight is determined according to the number of audit steps; The determining the priority of the security event based on the tag matching information, the tenant weight, and the corresponding process weight of the target process includes: The priority of the security event is determined based on the tag matching information, the tenant weight, the audit step weight, and the corresponding process weight of the target process.
4. The method according to claim 1, characterized in that: The event data includes: the time of occurrence, the location of occurrence, the event type and tenant information. The determining of the threat level of the security event based on the event data includes: Determining a first threat parameter according to the tenant information, the occurrence time, and the occurrence location; Determining a second threat parameter according to the event type and the security event sensitivity list; A threat level of the security event is determined based on the first threat parameter and the second threat parameter.
5. The method according to claim 3, characterized in that: The scheduling and processing of the security event based on the priority of the security event includes: Determine whether the number of pending events in the task queue has reached a preset number; If yes, scheduling and processing the security event according to the priority of the security event and the priority of the pending events in the task queue; If not, the security event is added to the task queue according to the priority of the security event to schedule the security event.
6. The method according to claim 5, characterized in that The scheduling and processing of the security event according to the priority of the security event and the priority of the pending events in the task queue includes: Determine whether the priority of the security event is greater than the priority of the last pending event in the task queue, and sort the pending events in the task queue according to their priority; If yes, suspend the pending event at the last position and add the security event to the task queue; If not, the security event is suspended for processing until the priority of the security event is greater than the priority of the last event to be processed in the task queue.
7. The method according to claim 6, characterized in that The method further comprises: After the security event is executed, an audit request is sent to the auditor, and the security event is suspended, wherein the audit request is used to instruct manual audit processing of the security event; Receive the audit results fed back by the auditors; When the audit result indicates that the manual audit is passed, updating and storing the event status of the security event; When the audit result indicates that the manual audit has not passed, the execution procedure of the security event is terminated.
8. A security event scheduling device, characterized in that: The device comprises: An acquisition module, used to acquire event data of security events; a processing module for determining the threat level of the security event based on the event data; when the threat level is greater than a preset threshold, determining the priority of the security event according to the event data; and scheduling the security event based on the priority of the security event.
9. A security event scheduling device, characterized in that: include: Memory, processor and communication interface; Wherein, the memory stores computer-executable instructions, and the communication interface is used to communicate with other devices via a transmission medium; The processor executes the computer-executable instructions stored in the memory to implement the security event scheduling method as described in any one of claims 1-7.
10. A computer storage medium, characterized in that: The computer storage medium stores computer execution instructions, which, when executed by a processor, are used to implement the security event scheduling method according to any one of claims 1 to 7.