CN114338178B

CN114338178B - SOAR script model, script construction method, electronic device and storage medium

Info

Publication number: CN114338178B
Application number: CN202111647481.1A
Authority: CN
Inventors: 钟竹; 薛洪亮; 黄伟
Original assignee: Beijing Abt Networks Co ltd
Current assignee: Beijing Abt Networks Co ltd
Priority date: 2021-12-30
Filing date: 2021-12-30
Publication date: 2022-11-29
Anticipated expiration: 2041-12-30
Also published as: CN114338178A

Abstract

The application provides an SOAR script model, a script construction method, electronic equipment and a storage medium, wherein the method comprises the steps of obtaining an initial SOAR script model; the scenario model is built according to the initial SOAR scenario model, and comprises a controller, a trigger, a first set object container, a second set object container, a third set object container, a fourth set object container, a fifth set object container and a sixth set object container. The script model generates a target SOAR script according to the starting node, the App information, the condition judgment information, the connection direction set, the variable information and the ending node. In order to solve the problem that the problem solving process is long and the efficiency is low when the requirement problem occurs in the process of using the script.

Description

SOAR script model, script construction method, electronic device and storage medium

Technical Field

The present application relates to the field of network security technologies, and in particular, to an SOAR scenario model, a scenario construction method, an electronic device, and a storage medium.

Background

SOAR (Security organization and Response) automates and responds to Security organization and considers it as a fusion of three technologies/tools, security Organization and Automation (SOA), security Incident Response Platform (SIRP), and Threat Information Platform (TIP). The security arrangement refers to a process of combining security capabilities of different systems of a client or different components in one system together according to a certain logical relationship through a programmable Interface API (Application Programming Interface) and a manual detection point to complete a certain specific security operation. The SOAR platform can flexibly arrange the existing safety capacity, and the scene construction is completed by compiling a script (Playbook) to realize automatic operation.

The scenario is formed by connecting a series of actions (actions) in the SOAR platform and comprises a complete judging and disposing process of safe operation. However, the scenario used in the related art is inefficient in solving the problem if a demand problem occurs. For example, if the user scenario finds that the suspicious IP address needs to be blocked, the user needs to make further judgment after finding the suspicious IP address. If the judgment requirement is increased, a new scenario needs to be reconstructed and verified for a large amount of time, so that the problem solving process is long and the efficiency is low.

Disclosure of Invention

The application provides an SOAR script model, a script construction method, an electronic device and a storage medium. In order to solve the problem that the problem solving process is long and the efficiency is low when the requirement problem occurs in the process of using the script.

In a first aspect, the present application provides a method for constructing an SOAR scenario, where the method is applied to an event management system, and specifically includes the following steps:

obtaining an initial SOAR script model;

building a script model according to the initial SOAR script model, wherein the script model comprises:

a controller configured to perform manual approval, condition judgment, and a timer process;

the trigger is configured to store a plurality of pre-App information, run the pre-App information, receive the input pre-App information and trigger to enter an application program corresponding to the pre-App information;

the first set object container is configured to store a plurality of App information, run a plurality of Apps, receive the input App information, and call App interfaces corresponding to the App information to realize application docking;

a second set object container configured to store and run a connection direction set including data connection directions between a plurality of nodes;

the third set object container is configured to store and operate a connection trend condition set, and the connection trend condition set comprises condition judgment information corresponding to the data connection direction among a plurality of nodes; the condition judgment information is used for representing whether to continuously execute the data connection direction;

a fourth collection object container configured to store basic description information, organization description information, and execution environment base information corresponding to the target SOAR transcript;

a fifth collection object container configured to store variable information corresponding to the target SOAR transcript; the variable information is preset script data, and the preset script data is used for being directly called when a target SOAR script is constructed;

a sixth collection object container configured to store source description information corresponding to the target SOAR transcript, the source description information being used to characterize a source corresponding to the transcript.

Optionally, the scenario model further includes a start node and an end node, where the start node is configured to generate according to a preset start action, and the end node is configured to generate a scenario according to an end action.

Optionally, after the scenario model is built according to the initial SOAR scenario model, the method further includes:

receiving input starting nodes, app information, condition judgment information, a connection direction set, variable information and ending nodes; the method comprises the steps that App information is input into a first set object container, condition judgment information is input into a third set object container, a connecting line direction set is input into a second set object container, and variable information is input into a fifth set object container;

and the scenario model generates a target SOAR scenario according to the starting node, the App information, the condition judgment information, the connection direction set, the variable information and the ending node.

Optionally, the scenario model generates a target SOAR scenario according to the start node, the App information, the condition judgment information, the connection direction set, the variable information, and the end node, and includes:

and performing dependent connection operation on the start node, the App information, the condition judgment information, the variable information and the end node according to the connection direction set to generate a target SOAR script.

Optionally, the method further includes:

responding to the dragging operation of the plurality of identifications input on the user interface of the event management system to generate a target SOAR script; the multiple identifiers are visual identifiers corresponding to the controller, the trigger, the first set object container, the second set object container, the third set object container, the fourth set object container, the fifth set object container and the sixth set object container.

Optionally, the method further includes:

according to the condition judgment information, carrying out approval processing on part or all actions in the target SOAR script; the action subjected to the approval processing is executed by the target SOAR script, and the action not subjected to the approval processing is not executed by the target SOAR script.

In a second aspect, the present application provides an SOAR script model, specifically including:

the trigger is configured to store a plurality of pre-App information, run a plurality of pre-Apps, receive the input pre-App information and trigger to enter an application program corresponding to the pre-App information;

a second set object container configured to store and execute a set of wiring directions, the set of wiring directions including data wiring directions between the plurality of nodes;

a fourth collection object container configured to store basic description information, organization description information, and execution environment basic information corresponding to the target SOAR transcript;

In a third aspect, the present application provides a computer-readable storage medium having a computer program stored therein, wherein the computer program is configured to execute the above-mentioned SOAR scenario construction method when running.

In a fourth aspect, the present application provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the above SOAR script building method.

According to the technical scheme, the application provides an SOAR script model, a script construction method, electronic equipment and a storage medium, and the method comprises the steps of obtaining an initial SOAR script model; the scenario model is built according to the initial SOAR scenario model, and comprises a controller, a trigger, a first set object container, a second set object container, a third set object container, a fourth set object container, a fifth set object container and a sixth set object container. The script model generates a target SOAR script according to the starting node, the App information, the condition judgment information, the connection direction set, the variable information and the ending node. In order to solve the problem that the problem solving process is long and the efficiency is low when the requirement problem occurs in the process of using the script.

Drawings

In order to more clearly explain the technical solution of the present application, the drawings needed to be used in the embodiments are briefly described below, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.

Fig. 1 shows a schematic flow chart of an SOAR scenario construction method provided by the present application;

fig. 2 shows a schematic flow chart of generating a scenario provided by the present application;

FIG. 3 is a schematic diagram of an interface for selecting a trigger or setting a start node provided by the present application;

FIG. 4 shows an interface diagram of an application App required by the drag service provided by the present application;

FIG. 5 shows an interface diagram of an application App required by the drag and repeat service provided by the present application;

FIG. 6 illustrates an interface schematic of a drag controller provided herein;

FIG. 7 illustrates an interface diagram of an add variable operation provided herein;

FIG. 8 is a schematic diagram illustrating an interface for dragging a manual approval node provided by the present application;

fig. 9 shows an interface schematic diagram of an application App required by the drag service provided by the present application.

Detailed Description

To make the purpose and embodiments of the present application clearer, the following will clearly and completely describe the exemplary embodiments of the present application with reference to the attached drawings in the exemplary embodiments of the present application, and it is obvious that the described exemplary embodiments are only a part of the embodiments of the present application, and not all of the embodiments.

It should be noted that the brief descriptions of the terms in the present application are only for convenience of understanding of the embodiments described below, and are not intended to limit the embodiments of the present application. These terms should be understood in their ordinary and customary meaning unless otherwise indicated.

The terms "first," "second," "third," and the like in the description and claims of this application and in the foregoing drawings are used for distinguishing between similar or analogous objects or entities and are not necessarily intended to limit the order or sequence in which they are presented unless otherwise indicated. It is to be understood that the terms so used are interchangeable under appropriate circumstances.

The terms "comprises" and "comprising," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a product or apparatus that comprises a list of elements is not necessarily limited to all elements expressly listed, but may include other elements not expressly listed or inherent to such product or apparatus.

The term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and/or software code that is capable of performing the functionality associated with that element.

In some embodiments, a problem is found or a superior assigns a task. Some approach is often used to solve problems or perform tasks. For example: a suspect IP is blocked. Then a pre-query is made as to whether the IP is on the blacklist before blocking the IP. If the IP does not exist in the blacklist, a second judgment is needed to be carried out, whether the IP is the IP with unknown source or not is judged, and if the IP is not the IP with unknown source, whether the IP appears in threat information or not is judged. Further inquiring information of threat intelligence. If the information is normal, then steps are needed to analyze the approximate source of the IP, which server is the destination, and what the requested port is. Finally, the conclusion is that the IP needs to be closed if the IP is normally false reported or the problem IP needs to be closed. And finally, determining whether to issue the blocking command, wherein the operation of issuing the blocking command is to manually log in the firewall or to use other tool software to issue the blocking command. The above is a series of methods for performing the blocking work on the suspicious IP.

It can be seen from the above embodiments that when a security event or a problem is resolved, it is necessary to request the help or permission of other persons by means of various tools (such as security service software, data processing software, gathering evidence-obtaining software, etc.). And when the problems occur for the second time or more, a fixed solution loop is formed. Or summarizing and forming a problem solution guide diagram and a related operation manual. Furthermore, in actual work, when a loop is formed to solve the problem, a scenario can be formed. The safety problem is solved or the task is executed through fixing the operation steps. And virtual nodes for manual intervention can be embedded into the script, and links such as personnel cooperation and superior permission can be seamlessly connected.

The scenario is an existing problem solving method, and the existing problem solving or target achieving process is standardized and streamlined. So that the solution can be quickly and automatically solved when the later time is met again. Repeated and trivial manual treatment is not needed, a large amount of manpower and material resources are saved, and the treatment efficiency and quality are guaranteed.

In some embodiments, the scenario corresponds to an SOAR system, and the scenario is formed by superimposing other associated basic service data on three model bases, namely, a plurality of application App Action actions (tools, software, specific capabilities, and the like), a plurality of virtual nodes (manual approval, condition judgment, timers, and the like), and a plurality of connection directions (logical context).

In the related art, when constructing the SOAR script, professional technical ability and business understanding ability are generally required, and the threshold of a technician is high. Secondly, the built SOAR script is poor in transportability, and if migration is desired, for example, migration from an A project to a B project needs to be modified, so that the research and development work period and the research and development workload are increased. Thirdly, due to the increase of the research and development work period and the research and development workload and the scarcity of technical personnel, a certain operation error rate exists in the operation process with high probability. Most importantly, solving the problem if a demand problem occurs is inefficient. For example, if it is found in the usage scenario that the suspicious IP address needs to be blocked, further determination is needed after the suspicious IP address is found. If the judgment requirement is increased, a new scenario needs to be reconstructed and verified for a large amount of time, so that the problem solving process is long and the efficiency is low.

To optimize the process of constructing SOAR scenarios in the related art described above,

the application provides a SOAR script construction method, the method is applied to an event management system, and FIG. 1 is a flow diagram of the SOAR script construction method provided by the application. Referring to fig. 1, the method specifically includes the following steps:

s1: obtaining an initial SOAR script model;

s2: building a script model according to the initial SOAR script model, wherein the script model comprises:

the first set object container is configured to store a plurality of App information, run a plurality of Apps, receive the input App information and call an App interface corresponding to the App information to realize application docking;

In some embodiments, the generation of the scenario is performed by the scenario model constructed as described above. It should be noted that the most basic granularity in the scenario includes points and lines. Points are nodes and lines are connecting directions. The types of the nodes comprise application nodes (apps), and exemplary, common standard application apps (such as an Email sending App, an IP home inquiry App, a threat intelligence inquiry App, and the like). The plurality of apps and corresponding App information may be stored in the first collective object container in advance, in the process of building the scenario, an application node is formed after the App is input to a specific App in the first collective object container, and when the scenario is executed, the corresponding App is executed and the App information thereof is executed by executing the application node.

Further, the type of the node further includes a controller, where the controller may be a built-in controller (build-control unit) of the SOAR platform, and the controller is configured to perform manual approval, condition judgment, timer operation, and the like. The meaning of manual approval is that the operation of judgment and annotation is performed manually, illustratively, when a certain operation is executed, superior leader authorization is required, and this time is when the manually approved node functions. And performing superior leader approval authorization before execution, and if authorization is performed, continuing, otherwise, terminating.

The condition judgment means that the subsequent node can be executed after the judgment is carried out by using a fixed condition. Illustratively, the sending of the mail informs the superior leader of the specific status of completion of the assigned task. However, the task is divided into two parts, and the two parts are required to be completed together before the mail can be sent. This time is when the conditional decision node is active. Before sending the mail, judging whether the two parts are finished or not, if so, sending the mail, otherwise, blocking. And after the precondition is finished, continuing the operation.

It should be noted that there is a certain difference between the trigger, the application App and the built-in controller, and the specific difference is as follows: firstly, the business requirements are different, and the purposes are different. The application App is external and is realized by the docking of external software. Such as Email mail related applications. The built-in controller is built in the system and is a plurality of key elements required by the script operation under certain scenes, such as manual examination and approval and condition judgment. The trigger is a precondition for the play of the script. It needs to be executed under a specific data scenario. Such as a Kfaka queue snoop trigger. Data in a specific format transmitted from the Kafka message queue needs to be monitored to trigger the running of a certain scenario.

Further, the type of the node also includes a Trigger, which may be a built-in Trigger (build-Trigger) of the SOAR platform, and in the process of running the application node, some application apps or data need to cooperate with the pre-App, and after the pre-App is executed, the corresponding application apps are triggered and executed. The trigger is used for storing a plurality of pre-arranged App information and operating a plurality of pre-arranged Apps, and when the input pre-arranged App information is received, the trigger is triggered to enter an application program corresponding to the pre-arranged App information. The pre-apps are, for example, kafka message receiving App, email mail monitoring App, http data access App, file monitoring App, and the like.

Further, the types of nodes further include a Start node configured to generate according to a preset Start action and an End node (build-Start/End) configured to generate a scenario according to an End action. In the subsequent running process of the script, the execution is also carried out from the starting node to the ending node. The nodes are directional, a large number of other nodes such as application nodes exist between the starting node and the ending node from the starting node to the ending node during script running, and the nodes are executed in sequence. A line represents from a certain node to a certain node. Such as aggregate data composition by source node ID to destination node ID. A call chain is typically built to store this portion of the data when implemented at the bottom.

In some embodiments, the direction of the link is represented as the link from node to node, midway from the starting node to the ending node. Meanwhile, the method also comprises a connection line trend condition, the line has directivity, and the method can be used for judging whether a preset result is met or not by the aid of an attachment condition when the line runs to the next node, and further judging whether the line continues to move forwards or is terminated to the current node or not.

Exemplarily, the application App is an Email application App. The application action is the following function that the Email App can provide: 1. a text content mail function of sending the basis; 2. a mail function of sending text and picture combination; 3. sending the mail with extra large attachments; 4. searching mail functions in my inbox through keywords; 5. and searching the mail function sent by me through the keywords. The action parameters are addressees, subjects, carbon copy persons, texts and the like which need to be filled in. The parameters are selected and filled in to generate the corresponding action. Actions are not the same as the specific function of the action, and there are a number of different parameters. Global variables are some data that is commonly used, such as: the IP address of the OA server, the group of recipients, the phone of the frequent contact, etc. The global variable can be preset in advance and can be directly referenced when needed. Global variables are data that fit into most scenes and screenplay local variables are critical or data that need to be reused only for the current screenplay. For example: at present, the script needs ssh to link a firewall, and needs an IP and a port. The IP and port may be needed for use in subsequent applications, at which time the IP and port may be set into a script local variable, and used anywhere in the script. Relevant parameters in or linked to the mysql database, etc.

Further, the method and the device can perform subsequent generation of the script by superposing business processing logic according to actual requirements based on the built script model. The method and the system are designed based on the script model to achieve script arrangement automation, page UI interactive dragging and editing modes to complete the construction of the script.

Further, after the scenario model is constructed according to the initial SOAR scenario model, fig. 2 is a schematic flow diagram of generating a scenario provided by the present application. Referring to fig. 2, the step of specifically generating the scenario includes:

s11: receiving input starting nodes, app information, condition judgment information, a connection direction set, variable information and ending nodes; the method comprises the steps that App information is input into a first set object container, condition judgment information is input into a third set object container, a connection direction set is input into a second set object container, and variable information is input into a fifth set object container;

s12: and the scenario model generates a target SOAR scenario according to the starting node, the App information, the condition judgment information, the connection direction set, the variable information and the ending node.

In some embodiments, the scenario model generates the target SOAR scenario according to the start node, the App information, the condition judgment information, the connection direction set, the variable information, and the end node, and includes: and performing dependent connection operation on the starting node, the App information, the condition judgment information, the variable information and the ending node according to the connection direction set to generate a target SOAR script.

In some embodiments, a target SOAR transcript is generated in response to a drag operation on a plurality of identifiers entered on a user interface of an event management system; the multiple identifiers are visual identifiers corresponding to the controller, the trigger, the first set object container, the second set object container, the third set object container, the fourth set object container, the fifth set object container and the sixth set object container.

For example, when the business processing logic input according to the actual requirement in the scenario model can be implemented in the user interface, referring to fig. 3, a trigger is first selected or a Start node is set, in this embodiment, the Start node (Start) is default after entering the scenario editing process, and the Start node cannot be deleted. Next, referring to fig. 4, selecting an application App required by the dragging service according to actual requirements, filling in necessary parameters, and submitting and storing the parameters. Next, referring to fig. 5, the above-described step of selecting the drag application App may be repeated. Next, referring to fig. 6, the controller is dragged, and the "condition" in the "controller" is selected, and the condition judgment information is filled in. The parameter information can use a custom expression "${ { application node name. Data. Parameter } }" format, and can also automatically acquire response data of a front application node from the context of the application node. So as to realize the business logic judgment of the controller. Next, referring to fig. 7, an add "variable" operation is performed, which may add a script local variable or reference a global variable. The variable data can be applied when App parameters are filled in. Next, referring to fig. 8, when "manual approval node" is selected and dragged, and "manual approval node" appears in the script, the automatic scheduling operation triggers a manual operation, and the personnel role that needs to respond manually clicks an approval or disapproval button, and gives a corresponding opinion. Next, referring to fig. 9, the application "send mail application App" is dragged, and after approval of manual approval, a mail is sent to the corresponding person. The above steps exemplarily construct a scenario.

As described above, the configuration of the scenario is exemplarily demonstrated, and the generated scenario is not specifically limited in the present application and can be designed according to actual situations.

In some embodiments. The method for building the script logic comprises the following steps: 1, selecting a trigger or a starting node; 2, setting variables (either referencing global variables or setting script variables), which can be repeated; 3, selecting an application or a controller, and repeating the steps; 4, setting alias names of application nodes, triggers or controllers, wherein the steps can be repeated; 5, selecting actions in the application, and repeating the steps; filling in necessary filling parameters required by the action, and obtaining values by using an expression, wherein the step can be repeated; 7, connecting wires, constructing the logic relation of the application, the trigger and the controller, and repeating the steps; and 8, saving the script to form a script yaml description file. The logic process can be designed according to actual conditions.

In some embodiments, some or all actions in the target SOAR scenario are approved according to the condition judgment information; the action subjected to the approval processing is executed by the target SOAR script, and the action not subjected to the approval processing is not executed by the target SOAR script.

In some embodiments, the scenario provided by the present application includes, but is not limited to, a plurality of conditional judgment nodes (making a judgment trend according to a structure or a variable executed by a previous application), a plurality of approval nodes (requiring human intervention, requiring permission for higher level approval, etc. in a standard automation process), a plurality of virtual nodes (extensible node design, such as taking a person as an application system), a plurality of asynchronous nodes (sometimes, after an application action is completed, what operation is always to be waited for, and other application operations need to be executed asynchronously), and a plurality of sub-scenarios (nested micro-scenarios, sub-tasks, flat scenarios). The present application is not limited to the specific embodiments, and can be designed or adjusted according to the actual situation.

In some embodiments, the screenplay architecture includes, but is not limited to: 1, basic information; 2, organization mechanism description information; 3, environment basic information; 4, trigger information; 5, applying App information; 6, controller information; 7, calling the chain; and 8, variable information.

In some embodiments, the detailed composition of the transcript includes, but is not limited to: script version: the scenario is realized in a better version along with the evolution of a system in an SOAR research and development system. Then a compatibility history is required. Scenario ID: the unique identification of the script consists of 32-bit UUID. Script name: name of script. Brief introduction: brief description of the script. The description is as follows: the detailed description of the scenario, including but not limited to the specific detailed process or illustration. Labeling: the script is marked with a plurality of labels. And (4) classification: the classification of the scenario requires the management of classification when the number of scenarios is extremely large. Starting: corresponding to the application service or the built-in virtual node. Ending end: corresponding to the application service or the built-in virtual node. Whether input external input is enabled: script sometimes requires external data to drive forward solutions while dealing with specific security issues. And an interface is reserved so as to obtain external data to drive the solution. The application service node: the scenario is composed of a plurality of application services, here stored application service action data. The ID of Start and end portions corresponds to this. A controller node: virtual nodes (manual intervention, manual approval, condition judgment, timer execution, etc.) are different from nodes of common application services. Calling a chain: a script is composed of multiple apps and manually-intervened virtual nodes, and application execution has a sequential order and also has a hierarchical order of execution. The call chain is an execution circuit diagram applied in the script. Variables are as follows: including global variables, script variables (scripts sometimes need some fixed or pre-specified information to solve the actual security problem, in this case, the script can be pre-specified in advance during the script layout process to realize that the application can directly use the data in the variables during the execution process): relevant extension configuration items of the scenario. Including but not limited to: relevant data configuration, business configuration, personnel configuration and the like. Executing the organization-related information: and executing the relevant organization information of the script.

In some embodiments, the application node data information includes, but is not limited to: ID applied in the scenario: there may be multiple applications in one script, and this ID is unique in the script. Names or aliases applied in the script: a plurality of applications can be stored in one script, and the applications need to be distinguished through aliases which are not repeatable. The following steps are described: the detailed description of the currently applied node, including but not limited to a specific detailed process or illustration. The task type is as follows: a controller or a regular node. Page UI rendering data: coordinates X and Y axes, and application service request data information. Application service request data information includes, but is not limited to: the application object is: full Yaml file structure data of the application. Name of action to be performed: an application contains a number of actions, the action names used this time. Additional data: supplementing the completed additional data.

In some embodiments, the present application provides an SOAR script model, specifically comprising:

a controller configured to perform manual approval, conditional judgment, and timer processes;

In some embodiments, the present application provides a computer-readable storage medium, in which a computer program is stored, where the computer program is configured to execute the above-mentioned SOAR scenario construction method when running, and details are not described herein again.

In some embodiments, the application provides an electronic device, including a memory and a processor, where the memory stores a computer program, and the processor is configured to run the computer program to perform the above-mentioned SOAR script construction method, which is not described herein again.

It can be known from the above embodiments that the present application provides an SOAR script model, a script construction method, an electronic device, and a storage medium, the method including obtaining an initial SOAR script model; the scenario model is built according to the initial SOAR scenario model, and comprises a controller, a trigger, a first set object container, a second set object container, a third set object container, a fourth set object container, a fifth set object container and a sixth set object container. And the scenario model generates a target SOAR scenario according to the starting node, the App information, the condition judgment information, the connection direction set, the variable information and the ending node.

The SOAR script and the method for constructing the SOAR script have the advantages that the editing process for constructing the script is simple to operate, the arrangement threshold is low, and high professional technical capacity is not needed. The method only needs to know the business to be executed, how to solve the problem and the process of executing the task, and can smoothly and quickly develop a new script by operating through the script model. Secondly, the script provided by the application has high portability, and the script can be easily and conveniently exported and migrated and directly used to the migration destination. The derived content is not limited to the scenario itself, and may be recorded by the scenario-related application, scene, security event-related information, and scenario execution. And thirdly, the operation process is easy and convenient, only a dragging and connecting mode is needed, the relevant application configuration is standard, and the prompt information is only needed to be filled and stored step by step. The method is also very stable in the application execution process, and the error rate of arranging the script is basically zero. Most importantly, due to the fact that the use threshold is low, script arrangement is convenient and fast, and the script arrangement can be achieved in a flowing mode and efficient in output. The user can completely arrange and modify the existing script or develop a new script by himself. Quickly resolving the need or problem. The process from problem finding to response solving is greatly improved, the working efficiency is improved, and the productivity is improved.

The same and similar parts in the embodiments in this specification are referred to each other, and are not described herein again.

In a specific implementation manner, the present invention further provides a computer storage medium, where the computer storage medium may store a program, and when the program is executed, the program may include some or all of the steps in each embodiment of the method for displaying quantity of extended media assets provided by the present invention. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), a Random Access Memory (RAM), or the like.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the embodiments to the precise forms disclosed above. Many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles and the practical application, to thereby enable others skilled in the art to best utilize the embodiments and various embodiments with various modifications as are suited to the particular use contemplated.

Claims

1. A SOAR script building method is characterized in that the method is applied to an event management system and specifically comprises the following steps:

obtaining an initial SOAR script model;

building a scenario model according to the initial SOAR scenario model, wherein the scenario model comprises:

the first set object container is configured to store a plurality of App information, run a plurality of Apps, receive the input App information, and call an App interface corresponding to the App information to realize application docking;

a second set object container configured to store and run a set of connection directions, the set of connection directions including data connection directions between a plurality of nodes;

a third set object container configured to store and run a connection trend condition set, where the connection trend condition set includes condition judgment information corresponding to the data connection direction among a plurality of nodes; the condition judgment information is used for representing whether to continuously execute the data connection direction;

and the sixth set object container is configured to store source description information corresponding to the target SOAR script, and the source description information is used for representing the source corresponding to the script.

2. The method of claim 1, wherein the transcript model further comprises a start node and an end node, wherein the start node is configured to generate according to a preset start action and the end node is configured to generate the transcript according to an end action.

3. The method of claim 2, after said building a transcript model from said initial SOAR transcript model, further comprising:

receiving the input starting node, the input App information, the input condition judgment information, the input connection direction set, the input variable information and the input ending node; the App information is input into the first collective object container, the condition judgment information is input into a third collective object container, the connection direction collective is input into a second collective object container, and the variable information is input into a fifth collective object container;

and the scenario model generates the target SOAR scenario according to the starting node, the App information, the condition judgment information, the connection direction set, the variable information and the ending node.

4. The method of claim 3, wherein the scenario model generates the target SOAR scenario from the start node, the App information, the conditional judgment information, the set of join directions, the variable information, and the end node, comprising:

and performing dependent connection operation on the starting node, the App information, the condition judgment information, the variable information and the ending node according to the connection direction set to generate the target SOAR script.

5. The method of claim 4, further comprising:

generating the target SOAR script in response to a drag operation on a plurality of identifiers input on a user interface of the event management system; wherein the plurality of identifiers are visual identifiers corresponding to the controller, the trigger, the first set object container, the second set object container, the third set object container, the fourth set object container, the fifth set object container, and the sixth set object container.

6. The method of claim 5, further comprising:

according to the condition judgment information, examining and approving part or all of the actions in the target SOAR script; the actions subjected to the approval process are to be executed by the target SOAR script, and the actions not subjected to the approval process are not to be executed by the target SOAR script.

7. An event management system, the system comprising an SOAR transcript model, the SOAR transcript model comprising:

8. A computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to carry out the method of any one of claims 1 to 6 when executed by a processor.

9. An electronic device comprising a memory and a processor, wherein the memory has stored therein a computer program, and the processor is configured to execute the computer program to perform the method of any of claims 1 to 6.