Auxiliary and automated workflows using structured log events

By monitoring the user interface to generate activity logs and using natural language understanding and process mining technology to build a workflow model, the inefficiency problem of existing security incident investigation systems in the face of fast and dynamic network threats is solved, and efficient and automated security incident investigations are achieved.

CN114846491BActive Publication Date: 2025-07-29INTERNATIONAL BUSINESS MACHINE CORPORATION
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
CN202080089646.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2020-02-13
Filing Date
2020-12-30
Publication Date
2025-07-29
Estimated Expiration
2040-12-30

AI Technical Summary

Technical Problem

Existing security incident investigation systems are difficult to effectively automate in the face of fast and dynamic cybersecurity threats, and lack of domain expertise, resulting in high cost and inefficiency, and cannot adapt to specific customer architecture and configuration changes.

Method used

Generate activity logs through monitoring user interfaces, extract features and variables from unstructured data using natural language understanding and process mining techniques, generate structured log events, and build workflow models based on these events to automate or assist the security incident investigation process.

Benefits of technology

It realizes efficient and automated security incident investigations in complex network security environments, reduces manual intervention, improves response speed and accuracy, and adapts to specific architectures and configurations of different customers.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114846491B_ABST
    Figure CN114846491B_ABST
Patent Text Reader

Abstract

An example system includes a processor that is used to monitor a user interface to generate an activity log including a step flow. The processor is used to extract features and common variables from unstructured data in the activity log and generate structured log events based on the extracted features and common variables. The processor generates a workflow model based on the structured log events. The processor automates or assists the workflow based on the generated workflow model.
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] The present technology relates to workflows. More specifically, the technology relates to the automation of workflows. Summary of the Invention

[0002] According to an embodiment described herein, a system may include a processor for monitoring a user interface to generate an activity log including a step flow. The processor may further extract features and common variables from unstructured data in the activity log and generate structured log events based on the extracted features and common variables. The processor may also generate a workflow model based on the structured log events. The processor may further automate or assist a workflow based on the generated workflow model. [[ID=IO]]

[0003] According to another embodiment described herein, a method may include monitoring a user interface via a processor to generate an activity log including a step process. The method may further include extracting features and common variables from unstructured data in the activity log via the processor and generating structured log events based on the extracted features and common variables. The method may further include generating a workflow model based on the structured log events via the processor. The method may also include workflow automation or assisting a workflow based on the generated workflow model via the processor.

[0004] According to another embodiment described herein, a computer program product for automating or assisting a workflow may include a computer-readable storage medium having program code embodied therewith. The computer-readable storage medium itself is not a transient signal. The program code may be executed by a processor to cause the processor to monitor a user interface to generate an activity log including a step flow. The program code may also cause the processor to extract features and common variables from unstructured data in the activity log and generate structured log events based on the extracted features and common variables. The program code may also cause the processor to generate a workflow model based on the structured log events. The program code may also cause the processor to automate or assist a workflow based on the generated workflow model. Brief Description of the Drawings

[0005] Figure 1 is a block diagram of an example system for using structured log events to automate and assist a workflow;

[0006] Figure 2 is a block diagram of an example method that can use structured log events to automate and assist a workflow;

[0007] Figure 3 is a block diagram of an example method that can generate a workflow model for automating or assisting a workflow;

[0008] Figure 4A block diagram of an example computing device that can use structured log events to automate and assist workflows;

[0009] Figure 5 A diagram of an example cloud computing environment in accordance with an embodiment described herein;

[0010] Figure 6 A diagram of an example abstract model layer in accordance with an implementation described herein; and

[0011] Figure 7 An example tangible non-transitory computer-readable medium that can use structured log events to automate and assist workflows. DETAILED DESCRIPTION

[0012] Security operations are very expensive and limited. It is not feasible to review and investigate every suspicious event in a security investigation, and each of these events may indicate a security incident that has a serious impact on the target organization. Moreover, centralized discussion and process planning for each suspicious event can be costly. In addition, there may be thousands of such processes running at a given time.

[0013] Some automated event investigation solutions are pre-built. For example, security experts can design "out-of-the-box" recipes for automated event investigation. However, these methods are highly limited and do not meet today's challenging cybersecurity landscape. For example, the rapid and dynamic creativity of attackers may prevent detection. Additionally, frequent changes to technologies can quickly render such designs ineffective. Moreover, the lack of domain expertise from vendors may make such designs ineffective from the start. Finally, company-specific cases may not work well in other situations. For example, attackers can exploit customer-specific vulnerabilities. There may also be cases where a particular customer has a specific architecture, configuration, or code, and the processes released by the vendor may not cover these cases. In addition, for attacks that may not have signatures, there may not be any simple way to automatically build an effective mechanism to fix such attacks.

[0014] According to an embodiment of the present disclosure, a system can use structured log events to automatically assist or automate workflows. An example system includes a processor that monitors a user interface to generate an activity log including a step process. The processor extracts features and common variables from unstructured data in the activity log and generates structured log events based on the extracted features and common variables. The processor generates a workflow model based on the structured log events. The processor automates or assists a workflow based on the generated workflow model. Thus, embodiments of the present disclosure implement automated or assisted workflow support based on a model workflow generated from a user's monitored activities.

[0015] Now refer toFigure 1 , The block diagram illustrates an example system for automating and assisting workflows using structured log events. The example system is generally referred to by reference numeral 100 and may be implemented using Figure 2 and 3 methods 200 and 300 of Figure 4 and 5 a computing device 400 or a computer-readable medium 500.

[0016] In Figure 1 the example of

[0017] Still referring to Figure 1 , system 100 can be used to automate security best practice builders, forensic processes, system tuning, and risk mitigation processes by leveraging the knowledge and proficiency of domain experts. Specifically, system 100 uses the combination of NLU and process mining to construct the workflows that domain experts use when performing these processes. System 100 can then utilize the constructed workflows to assist users when applying these processes. For example, system 100 can recommend mitigation measures for incoming suspicious events, including information to support such mitigation measures. System 100 can also utilize the constructed workflows to automate event investigation, system tuning, and risk mitigation processes.

[0018] In Figure 1In the example, system 100 includes user API 102 used by domain experts to apply investigation procedures. As an example, a domain expert can be a system-on-chip (SoC) analyst. In different examples, the scope of these user APIs 102 can range from a simple interface for applying simple SQL queries to an NLU-based UI that can implement an interrogation system and obtain answers in free language. For example, user API 102 can implement a chatbot with advanced NLU technology to simplify the work required to investigate each suspicious event. In some examples, the chat with the user can be converted into a Rest API for querying data, and this API can be used to set basic transition rules. As used herein, transition rules include one or more conditions that cause a step of a process to move to another. For example, a user can ask the system to check if a suspicious user has logged in unsuccessfully more than N times in the past 3 days. The user can specify "if so, go to step A" and "if not, go to step B". Thus, the transition rules in this example are based on the number of failed logins in the last 3 days and are used by system 100 to determine the next step. In different examples, the data of the chat with the user can also be used to perform different actions. For example, the action can include blocking the access of a suspicious user for the next N hours. In some examples, the action can include sending a notification to the manager of the suspicious user. In different examples, the action can include increasing the audit resolution of the suspicious user. In some examples, the action can include logging the actions of the suspicious user into a violation system. In some examples, the action can include invoicing. For example, tickets can be used to flag the actions of suspicious users for manual review. In different examples, the action can include closing a case in response to detecting that the detection of a suspicious user is a false positive.

[0019] The security warning system 108 can generate security warnings in response to the detection of security events. For example, security events can be detected via a data firewall, intrusion detection system (IDS), security information and event management (SIEM) system, or other suitable technologies for security event detection. In some examples, the security warning system 108 can include multiple security warning systems.

[0020] The event investigation platform 106 can be used to investigate security events. For example, security events can be received from a SIEM, malware analysis engine, database activity analysis engine, etc. In different examples, the event investigation platform 106 includes a search engine that allows users to query internal and external databases.

[0021] The mitigation platform 104 can be used to apply configuration adjustments and mitigation commands to the organization's security system. For example, the mitigation platform 104 can be used to add an Internet Protocol (IP) address to the firewall blacklist. As another example, the mitigation platform 104 can revoke the user credentials for a specific service.

[0022] The activity monitor 110 can monitor the interaction of a domain expert with one or more systems and generate a log activity containing the step flow executed by the domain expert. In different examples, the monitoring of the activity monitor 110 can be on the client side or on the server side. In some examples, to obtain the most comprehensive record of the monitored process, the activity monitor 110 can monitor all activities of the domain expert during the process. Thus, in some examples, the activity monitor 110 can also monitor queries applied on an external platform. For example, the activity monitor 110 can monitor queries on a web platform. Additionally, in some examples, the activity monitor 110 can perform passive monitoring or active monitoring. For example, passive monitoring can be transparent to users (such as domain experts). In active monitoring, the activity monitor 110 can interact with the user to obtain insights into a specific workflow. For example, the activity monitor 110 can ask the user to highlight a portion in a response, which leads to the next step in the investigation process. In different examples, the activity monitor 110 can apply active monitoring, asking the user to help determine transformation rules and populate tokens to improve process mining. As used herein, a token refers to a list of parameters and parameter values that can be used in subsequent steps and are thus stored. For example, parameter values can be used as runtime parameter values in subsequent steps of the process. Thus, a token can be used as the context for subsequent steps. In different examples, the activity monitor 110 can allow the user to highlight artifacts in the system response that lead to the following query or lead to the conclusion of an event.

[0023] In different examples, the event log storage device 112 is a database for storing the activity logs generated by the activity monitor 110. For example, the event log memory 112 can be an internal or external database.

[0024] The NLU engine 114 can be a model for extracting features and common variables from unstructured data in the activity log. For example, features can be users, files, or other features of the monitored system. The NLU engine 114 can convert the unstructured data into structured log events that can be processed by the process mining engine 116. Variables can be specific error types, times, etc. In different examples, the NLU engine 114 can store the structured log events in a database (such as the event log memory 112).

[0025] The process mining engine 116 can receive the domain expert log from the event log storage 112 and build a workflow model based on the domain expert log. To construct the workflow model, the process mining engine 116 can perform a process mining procedure. The process mining program can use Figure 3Method 300. For example, during the process mining process, the process mining engine 116 can convert the process into start -> step - process -> end. The process mining engine 116 can identify common "start steps". For example, a common start step can be a common start suspicious event that has initiated multiple investigations. In different examples, the start step can be used to run the process mining engine 116 to merge and optimize those processes associated with the start step. The process mining engine 116 can then identify common "sub - processes" among all processes. The process mining engine 116 can further identify the transition rules for each process. For example, the process mining engine 116 can set a predefined syntax for identifying the transition rules for each process. In different examples, the process mining engine 116 can then perform classification to identify the context of the steps. The context of the steps can also be referred to as tokens. For the purpose of classification, the process mining engine 116 can learn which parts are variables and where to extract the variables. Since learning what parts are variables and where to extract the variables can be very complex, in some examples, the process mining engine 116 can present options to the user and thus allow manual selection or adjustment of the variables. As an example, if a suspicious event involves a specific database table, the first step can issue an alert for symptoms related to this database table. The next step can run the first investigation step against that database. The classification objective can be to identify <entity: value> pairs (<entity: value> pair), so that the automation will know to set <table: "table name"> (<table: "table name">) as a running parameter instead of a constant. The process mining engine 116 can then create an optimized flow. For example, the process mining engine 116 can consider the start event, transition rules, and common sub - processes when creating the optimized flow. In different examples, the optimization of the flow can be completed within users of the same company and even across multiple companies. In some examples, the process mining engine 116 can then adjust the workflow model by allowing the user to customize and enhance the production workflow model. In various instances, the result of the process mining process is an automatically generated, best - fit, and merged process flow based on NLU. In some instances, the resulting best - fit and merged process flow can be shared among many customers.

[0026] In various examples, the server 118 may include a model that receives the constructed workflow as input and uses the constructed workflow to assist a user in applying an event investigation procedure or to fully or partially automate the investigation procedure. In some examples, the automation process may be triggered by an event detected by one of the organization's alert systems or may be triggered periodically. For example, a user may record a threat analysis process as Ex2 and schedule the threat analysis process to run automatically every N hours. In various examples, the server 118 may also include a classification algorithm for identifying entities from a script and then looking up tokens to obtain values for runtime parameters of the process. In some examples, the process is automatically defined with its transition rules and tokens. For example, the server 108 may identify that a user is to be included in a token, and the token will be dynamically generated from the first step and used throughout all subsequent steps. Additional parameter values may be added to the token at a later step for use in subsequent steps.

[0027] In various examples, assuming that the user continues to run more and more processes, the process mining engine 116 may run periodically to identify more processes and common subprocesses for the same start event. The process mining engine 116 may run a specific process mining algorithm to optimize a number of workflow processes into an optimized process. For example, the process mining engine 116 may run a phase mining algorithm. The process mining engine 116 may utilize all possible transition rules to identify and optimize the process. As an example, in a case where a user runs a first process with outliers related to Command = GRANT, and later, the same user or another user runs a process similar to threat analysis on the above process flow Ex2 for Command = SELECT, then these two processes can be combined into an optimized process with transition rules.

[0028] In this way, the server 118 can not only apply the most suitable optimized process, but also apply other processes that have not been used for a given event. In various examples, the server 118 includes a user interface that facilitates iteration between the server and security experts. For example, the user interface may present suggestions to a security analyst or provide security analyst feedback on the automation process, etc. In various examples, the server 118 may cluster across customers and recommend improvements to their processes to each customer. For example, customers may be clustered by performing a nearest neighbor algorithm. In some examples, the server 118 may interactively perform predictive analysis to suggest the next step to a user's manual process.

[0029] As a process example Ex1, a new command outlier "GRANT" may have been detected. A security analyst can send a request to find the user with the highest outlier in the "New Command" category. The system can respond by displaying the user and providing details about the outlier command. The results are processed by the NLU engine 114 to extract features into tokens. For example, these features can be used in subsequent step analysis and to find common features of these steps. The NLU engine 114 may have identified category = "New Command" and user = <userfound>. These two dynamic parameters can be copied to the token for later use. The security analyst can then request to check if the grantee of the user's outlier is a dormant user if the outlier is a new command of the GRANT type. The system can respond with "True, the user is a dormant user" and can provide information about the detected GRANT command and other information. The NLU engine 114 can then perform feature mapping, execute the relevant API, map the token to runtime parameters, and add command = GRANT & grantee = <user who received the privilege> to the token. Then, the security analyst can request to get the grantee and search for the activities of the grantee. The system can respond with "The grantee is John Smith" and provide a list of activities of user John Smith. At this point, the NLU engine 114 can add <user = John Smith> and activity = <activities found> to the token accordingly. The security analyst can further request to check if there is a sensitive object ((RestAPi runs a free text search using filters <GRANTEE> and <sensitive Object>)). The system can respond with "8 records found" and provide the search results. The NLU engine 114 can add sensitive object = <list of objects found> to the token accordingly. Then, the security analyst can request "Check if this activity appears more than once (RestAPi runs a free text search where filter count > 1)". The system can reply with "False".Then, the security analyst can further request: to check whether the number of affected records (RECORD AFFECTED) is greater than 1 (RestAPi runs a free text search, where the filter is affected records > 1 and count > 1). The system can respond: "True, the number of affected records is 6" and provide the search results. At this time, the NLU engine 114 can add the parameter affected records = 6 to the token. Then, the security analyst can send commands: "Add this user to the watch list (RestAPI adds <user> to the watch list)" and "Open a ticket (TICKET) in ServiceNow and assign it to the user's manager (RestAPI opens a ticket (TICKET) in ServiceNow and adds the output script of this process as text to the ticket)". The NLU engine 114 can accordingly add the ServiceNow ticket Id (ServiceNow.ticketId) to the token.

[0030] In the second example process (Ex2), a new command outlier "SELECT" can be detected. For example, the security analyst can request: to find the user with the highest outlier in the category "New Command". The system can respond by displaying the user and providing details about the outlier. Then, the security analyst can request: "Retrieve the outlier in the case where the new command is SELECT". The system can respond with a list of outliers where the new command is SELECT. The security analyst can request: "Run a general search for this user and look for the words OUT_FILE, UTL_HTTP". The system can respond: "True" and provide the search results. Then, the security analyst can send commands: "Open a ticket for this user", "Set the priority to high severity", and "Find and export the user name to a file or http".

[0031] For these two example processes, the process mining engine 116 can receive two corresponding workflows (WF) from the NLU engine 114 and detect that the two workflows have a common starting point. The process mining engine 116 can then run an algorithm to find the best workflow that combines the two workflows. In some examples, the algorithm of the process mining engine 116 can create a new workflow starting from step 1 (which is common to the two workflows), and then create a nested workflow that covers both use cases.

[0032] It should be understood that Figure 1 the block diagram is not intended to indicate that system 100 will include Figure 1 all the components shown. Instead, system 100 may include Figure 1Fewer or additional components not shown (e.g., additional client devices or additional resource servers, etc.).

[0033] Figure 2 is a process flow diagram of an example method that can use structured log events to automate and assist workflows. Method 200 can be implemented using any suitable computing device (such as Figure 3 computing device 300) and is described with reference to Figure 1 system 100. For example, the methods described below can be implemented by Figure 4 computing device 400.

[0034] At block 202, the processor monitors the user interface to generate an activity log including a step flow. For example, the processor can monitor a two-way conversation between a user and a service on a server. For example, the service can be a chatbot accessed via a virtual assistant, website, or application. The chatbot can converse with the user via auditory or text technology. In different examples, the user can send a request to the service as part of a security workflow, forensic process, system regulation, or risk mitigation process. In some examples, the monitoring can be passive monitoring or active monitoring.

[0035] At block 204, the processor stores the activity log in a database. For example, the database can be an internal database directly accessible by the processor or an external database accessible via a network.

[0036] At block 206, the processor extracts features and common variables from the unstructured data in the activity log and generates structured log events based on the extracted features and common variables. For example, the processor can use a trained natural language understanding model to extract features and common variables. In different examples, the extracted features can be stored on tokens. In different examples, the extracted features can include users, servers, services, times, commands, tables, fields, response times, affected records, client Internet protocol addresses, error types, error codes, violation types, violation severities, and other types of features.

[0037] At block 208, the processor generates a workflow model based on the structured log events. For example, the processor can generate an optimized workflow model for different types of workflows. In some examples, the processor can generate multiple workflow models for one type of workflow. For example, the workflow model can integrate different processes, including processes or subprocesses that are not actually used for a specific task. In some examples, the processor can cluster across customers and generate improved workflows to be recommended to each customer in the cluster. For example, the processor can process multiple workflows for a specific customer or across multiple customers, sharing data and learning across multiple customers.

[0038] At block 210, the processor automates or assists a workflow based on the generated workflow model. In some examples, the processor may automatically execute a specifically generated workflow model. For example, the processor may execute a workflow model optimized for a specific task. In some examples, the processor may execute multiple workflow models for a specific task and present the results to the user. For example, the processor may have generated additional workflow models based on structured log events and automatically execute the additional workflow models to generate multiple results to be presented. In different examples, the processor may assist the user in performing a specific task based on an optimized workflow. For example, the processor may detect that the user is at a specific step of a task and suggest performing subsequent steps. In different examples, the processor may interactively perform predictive analytics to suggest the next step of a manual process for the user. In some examples, the automation of the workflow may be triggered by a detected event from an alert system. In different examples, the automation of the workflow may be performed periodically. For example, the automated workflow may be scheduled to execute automatically at predefined time intervals.

[0039] Figure 2 The process flow diagram is not intended to indicate that the operations of method 200 are to be performed in any specific order, or that all operations of method 200 are to be included in every case. Additionally, method 200 may include any suitable number of additional operations.

[0040] Figure 3 is a process flow diagram of an example method that can generate a workflow model for automating or assisting a workflow. Method 300 can be implemented using any suitable computing device, such as Figure 3 computing device 300, and is described with reference to Figure 1 system 100. For example, method 300 can be performed by Figure 1 process mining engine 116, Figure 4 process mining module 430 of computing device 400, or Figure 7 process mining module 712.

[0041] At block 302, the processor converts structured log events into start events, step flows, and end events. A start event is an event that starts a specific monitored process. For example, a start event can be a suspicious event that starts an investigation. A step flow can include a series of steps that connect the start event to the end event. An end event can include an event that ends a specific monitored process.

[0042] At block 304, the processor detects a common start event among the monitored processes. For example, the processor may detect a common start event based on one or more characteristics shared by the start events of two or more processes. As an example, two workflow processes may start from a step including the command "fetch me the highest anomalies in the last N days".

[0043] At block 306, the processor merges and optimizes the processes based on the common start event. For example, the processor may merge processes by combining two processes into an optimized process. As an instance, the processor may merge two start steps. The processor may optimize the process by any suitable process mining technique.

[0044] At block 308, the processor detects common subprocesses among different processes. For example, common subprocesses may be detected based on shared start steps, characteristics, variables, etc.

[0045] At block 310, the processor detects the transition rules for each process among the merged processes. In some instances, the processor may set predefined syntax to detect the transition rules. The predefined syntax may be a dictionary or set of instances used by the processor to associate different words or phrases with specific characteristics or variables.

[0046] At block 312, the processor runs a classification to detect the context of each step of each process. For example, the processor may use a classifier that is trained to identify the variable parts of each step in each process and the locations of those variables. The processor may extract the variable parameters into tokens. The tokens can be used to track the parameters extracted across the steps of each process.

[0047] At block 314, the processor generates an optimized flow model based on the start event, transition rules, common subprocesses, and context. In some examples, an optimized flow model may be generated for each user of a particular organization. In different examples, an optimized flow model may be generated for a particular organization. In some examples, the processor may generate an optimized flow model that can be used by multiple organizations.

[0048] At block 316, the processor adjusts the optimized flow model based on user feedback. For example, the processor may allow the user to customize and enhance the generated optimized flow model.

[0049] Figure 3 The process flow diagram of 300 is not intended to indicate that the operations of method 300 are to be performed in any particular order, or that all the operations of method 300 are to be included in every case. Additionally, method 300 may include any suitable number of additional operations. For example, assuming the user continues to execute additional processes, the processor may periodically identify additional processes having common start events and common subprocesses. The processor may then update the optimized flow model to include any additional transition rules for these common subprocesses.

[0050] In some scenarios, the techniques described herein can be implemented in a cloud computing environment. As will be seen at least below Figures 4 - 7 and discussed in more detail, computing devices configured to automatically operate workflows using structured log events can be implemented in a cloud computing environment. It is understood in advance that although this disclosure may include a description of cloud computing, the implementation of the teachings recited herein is not limited to a cloud computing environment. Instead, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

[0051] Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the provider of the service. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0052] The characteristics are as follows:

[0053] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities, such as server time and network storage, as needed, without human interaction with the service provider.

[0054] Broad network access: Capabilities are available over a network and accessed through standard mechanisms that facilitate the use of heterogeneous thin client platforms or thick client platforms (e.g., mobile phones, laptop computers, and PDAs).

[0055] Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence, as consumers generally have no control or knowledge of the exact location of the resources provided, but may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0056] Rapid elasticity: Capabilities can be provided rapidly and elastically, automatically scaling down rapidly and releasing rapidly to scale up rapidly in some cases. To the consumer, the capabilities available for provisioning generally appear to be unlimited and can be purchased in any quantity at any time.

[0057] Measured service: The cloud system automatically controls and optimizes resource use by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource use can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

[0058] The service models are as follows:

[0059] Software as a Service (SaaS): The ability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications can be accessed from different client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even the individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0060] Platform as a Service (PaaS): The ability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but has control over the deployed applications and possibly the application hosting environment configuration.

[0061] Infrastructure as a Service (IaaS): The ability provided to the consumer is to provide processing, storage, networks, and other fundamental computing resources where the consumer can deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, deployed applications, and possibly limited control over the selected networking components (e.g., host firewall).

[0062] The deployment models are as follows:

[0063] Private cloud: The cloud infrastructure is for the exclusive use of an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0064] Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community that shares concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0065] Public cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services.

[0066] Hybrid cloud: The cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0067] The cloud computing environment is service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0068] Figure 4 FIG. 2 is a block diagram of an example computing device that can use structured log events to automate and assist a workflow. Computing device 400 can be, for example, a server, a desktop computer, a laptop computer, a tablet computer, or a smart phone. In some examples, computing device 400 can be a cloud computing node. Computing device 400 can be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform particular tasks or implement particular abstract data types. Computing device 400 can be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules can be located in both local and remote computer system storage media including memory storage devices.

[0069] Computing device 400 can include a processor 402 for executing stored instructions and a memory device 404 for providing temporary storage space for the operation of the instructions during operation. The processor can be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. Memory 404 can include random access memory (RAM), read-only memory, flash memory, or any other suitable memory system.

[0070] Processor 402 can be connected through a system interconnect 406 (e.g., PCI- etc.) to an input / output (I / O) device interface 408 that is adapted to connect computing device 400 to one or more I / O devices 410. I / O device 410 can include, for example, a keyboard and a pointing device, where the pointing device can include a touchpad or a touch screen, etc. I / O device 410 can be an internal component of computing device 400 or can be a device externally connected to computing device 400.

[0071] The processor 402 may also be linked via the system interconnect 406 to a display interface 412 adapted to connect the computing device 400 to a display device 414. The display device 414 may include a display screen as a built-in component of the computing device 400. The display device 414 may also include a computer monitor, a television set, a projector, etc. externally connected to the computing device 400. Additionally, a network interface controller (NIC) 416 may be adapted to connect the computing device 400 to a network 418 via the system interconnect 406. In some embodiments, the NIC 416 may use any suitable interface or protocol (such as the Small Computer System Interface for the Internet, etc.) to transmit data. The network 418 may be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, etc. An external computing device 420 may be connected to the computing device 400 via the network 418. In some examples, the external computing device 420 may be an external web server 420. In some examples, the external computing device 420 may be a cloud computing node.

[0072] The processor 402 may also be linked to a storage device 422 via a system interconnect 406, which may include a hard disk drive, an optical disk drive, a USB flash drive, a drive array, or any combination thereof. In some examples, the storage device may include an activity monitor module 424, an activity recorder module 426, a natural language understanding (NLU) module 428, a process mining module 430, and a workflow assistant and automator module 432. The activity monitor module 424 may monitor the user interface to generate an activity log including a step flow. For example, the step flow may include steps taken by a user to complete a particular task. The activity recorder module 426 may store the activity log in a database. For example, the database may be an internal database or an external database. The NLU module 428 may extract features and common variables from unstructured data in the activity log and generate structured log events based on the extracted features and common variables. The process mining module 430 may generate a workflow model based on the structured log events. For example, the process mining module 430 is capable of converting the structured log events into start events, step flows, and end events. The process mining module 430 may then detect common start events between the monitored processes. The process mining module 430 may also merge and optimize processes based on the common start events. The process mining module 430 may further detect common subprocesses within the processes. The process mining module 430 may then detect transition rules for each process within the merged processes. The process mining module 430 may also perform classification to detect context. The process mining module 430 may then generate an optimized flow model based on the start events, transition rules, common subprocesses, and context. In some examples, the process mining module 430 may adjust the optimized process model based on user feedback. In some instances, the process mining module 430 may cross-customer clusters and generate an improved workflow to present to each customer in the cluster. In different examples, the process mining module 430 may interactively perform predictive analysis to suggest the next step in a user's manual process. The workflow assistant and automation module 432 may automatically operate or assist the workflow based on the generated workflow model. For example, the automated or assisted workflow may be a security best practice workflow, a forensics process workflow, a system tuning workflow, or a risk mitigation process workflow.

[0073] It should be understood that Figure 4 the block diagrams are not intended to indicate that the computing device 400 will include Figure 4 all of the components shown in Figure 4Fewer or more components (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.) not shown in the figure. Additionally, any of the functions of the activity monitor module 424, the activity recorder module 426, the NLU module 428, the process mining module 430, and the workflow assistant and automator module 432 can be implemented partially or fully in hardware and / or the processor 402. For example, this functionality can be implemented using an application-specific integrated circuit, logic implemented in an embedded controller, or logic implemented in the processor 402, etc. In some embodiments, the functions of the activity monitor module 424, the activity recorder module 426, the NLU module 428, the process mining module 430, and the workflow assistant and automation module 432 can be implemented using logic, where the logic as mentioned herein can include any suitable hardware (e.g., a processor, etc.), software (e.g., an application, etc.), firmware, or any suitable combination of hardware, software, and firmware.

[0074] Now referring to Figure 5 , an illustrative cloud computing environment 500 is described. As shown, the cloud computing environment 500 includes one or more cloud computing nodes 502, and local computing devices used by cloud consumers (such as, for example, a personal digital assistant (PDA) or cellular phone 504A, a desktop computer 504B, a laptop computer 504C, and / or an in-vehicle computer system 504N) can communicate with the cloud computing nodes 502. The nodes 502 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or a combination thereof as described above. This allows the cloud computing environment 500 to provide infrastructure, platforms, and / or software as services for which cloud consumers do not need to maintain resources on local computing devices. It should be understood that Figure 5 the types of computing devices 504A-N shown in the figure are only illustrative, and the computing nodes 502 and the cloud computing environment 500 can communicate with any type of computerized device through any type of network and / or network addressable connection (e.g., using a web browser).

[0075] Now referring to Figure 6 , a set of functional abstraction layers provided by the cloud computing environment 500 ( Figure 5 ) is shown. It should be understood in advance that Figure 6 the components, layers, and functions shown in the figure are only illustrative, and the embodiments of the present invention are not limited thereto. As described, the following layers and corresponding functions are provided.

[0076] The hardware and software layer 600 includes hardware and software components. Examples of hardware components include mainframes, in one example systems; servers based on the RISC (Reduced Instruction Set Computer) architecture, in one example IBM System; IBM System; IBM System; storage device; network and network components. Examples of software components include network application server software, which is IBM in one example Application server software; and database software, which is IBM in one example Database software. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation registered in many jurisdictions worldwide).

[0077] The virtualization layer 602 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers; virtual storage; virtual networks, including virtual private networks; virtual applications and operating systems; and virtual clients. In one example, the management layer 604 can provide the functions described below. Resource provisioning provides for the dynamic procurement of computing resources and other resources for performing tasks within a cloud computing environment. Metering and pricing provides cost tracking for utilization of resources within a cloud computing environment and bills or invoices for consumption of these resources. In one example, these resources can include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. The user portal provides access to the cloud computing environment for consumers and system administrators. Service level management provides cloud computing resource allocation and management to meet the required service levels. Service level agreement (SLA) planning and fulfillment provides for the pre - arrangement and procurement of cloud computing resources based on the expected future requirements of the SLA for those cloud computing resources.

[0078] The workload layer 606 provides examples of functions that can leverage the cloud computing environment. Examples of workloads and functions that can be provided from this layer include: maps and navigation; software development and lifecycle management; virtual classroom education delivery; data analysis processing; transaction processing; and workflow automation.

[0079] The present invention can be a system, method, and / or computer program product at any possible technical detail integration level. The computer program product can include a computer - readable storage medium (or media) having computer - readable program instructions thereon for causing a processor to execute aspects of the present invention.

[0080] A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium can be, for example but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punched card or a raised structure in a groove having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable) or an electrical signal emitted through a wire.

[0081] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or to an external computer or an external storage device. The network can include a copper transmission cable, an optical transmission fiber, a wireless transmission, a router, a firewall, a switch, a gateway computer, and / or an edge server. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the corresponding computing / processing device.

[0082] The computer-readable program instructions for carrying out operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state-setting data, or code or object code written in any combination of one or more programming languages, including object-oriented programming languages (such as Smalltalk, C++ etc.) and conventional procedural programming languages (such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network (including a local area network (LAN) or a wide area network (WAN)), or may be connected to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), can execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit, so as to perform various aspects of the present invention.

[0083] Aspects of the present invention are described herein with reference to the flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present technique. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0084] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed via the processor of the computer or other programmable data processing apparatus create a means for implementing the functions / acts specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which instructions cause a computer, a programmable data processing apparatus, and / or other devices to work in a particular manner, so that the computer-readable storage medium storing the instructions includes a manufacture including instructions implementing aspects of the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0085] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other devices, so that a series of operation steps are executed on the computer, other programmable apparatus, or other devices to produce a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other devices implement the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0086] Now refer to Figure 7 which depicts a block diagram of an example tangible non-transitory computer-readable medium 700 that can use structured log events to automate and assist workflows. The tangible non-transitory computer-readable medium 700 can be accessed by a processor 702 via a computer interconnect 704. Additionally, the tangible non-transitory computer-readable medium 700 can include code for guiding the processor 702 to perform the operations of methods 200 and 300 of Figure 2 and 3 .

[0087] The various software components discussed herein can be stored on the tangible, non-transitory, computer-readable medium 700, as Figure 7 shown. For example, the activity monitor 706 includes code for monitoring the user interface to generate an activity log including a step flow. The natural language understanding (NLU) module 710 includes code for extracting features and common variables from unstructured data in the activity log and generating structured log events based on the extracted features and common variables. The process mining module 712 includes code for generating a workflow model based on the structured log events. In some examples, the process mining module 712 includes code for converting the structured log events into start events, step flows, and end events. In different examples, the process mining module 712 includes code for detecting common start events between the monitored processes. The process mining module 712 may also include code for merging and optimizing processes based on the common start events. The process mining module 712 may also include code for detecting common subprocesses among the merged processes. The process mining module 712 may also include code for detecting transition rules for each process among the processes. The process mining module 712 may also include code for performing classification to detect context. The process mining module 712 may also include code for generating an optimized flow model based on start events, transition rules, common subprocesses, and context. In some examples, the process mining module 712 may include code for adjusting the optimized flow model based on user feedback. In different examples, the process mining module 712 may also include code for clustering across customers and generating improved workflows to be recommended to each customer in the cluster. The workflow assistant and automation module 714 includes code for automatically operating or assisting workflows based on the generated workflow model. In some examples, the workflow assistant and automation module 714 includes code for interactively performing predictive analysis to suggest the next step of a user manual process. It should be understood that depending on the specific application, any number of additional software components not shown in Figure 7 may be included within the tangible, non-transitory computer-readable medium 700.

[0088] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of the possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may not occur in the order noted in the figures. For example, depending on the functions involved, two consecutive blocks shown may actually be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or actions or a combination of dedicated hardware and computer instructions. It should be understood that, depending on the specific application, any number of additional software components not shown may be included within the tangible, non-transitory computer-readable medium 700 Figure 7 that are not shown in

[0089] The description of the various embodiments of the present technology has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terms used herein have been chosen to best explain the principles of the embodiments, the practical application, or the technical improvement of the technology found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A system for processing workflows, including a processor for: Monitoring a user interface to generate an activity log including a step flow; Extracting features and common variables from unstructured data in the activity log and generating structured log events based on the extracted features and common variables; Generating a workflow model based on the structured log events, wherein, The processor is used for: Detecting common start events between monitored processes; Merging and optimizing the processes based on the common start events; Detecting common subprocesses between the processes; Detecting transition rules for each process in the merged process; Performing classification to detect context; And Generating an optimized flow model based on common start events, transition rules, common subprocesses, and context; And automating or assisting the workflow based on the generated workflow model.

2. The system according to claim 1, wherein Generating the structured log events through a natural language understanding unit, wherein the processor converts the structured log events into start events, step flows, and end events.

3. The system according to claim 1, wherein, The processor adjusts the optimized flow model based on user feedback.

4. The system according to claim 1, wherein, The processor clusters across customers and generates an improved workflow presented to each customer in the cluster.

5. The system according to claim 1, wherein The processor interactively performs predictive analysis to suggest the next step for a user manual process.

6. The system according to claim 1, wherein, The automated or assisted workflow includes a security best practice workflow, a forensic process workflow, a system tuning workflow, or a risk mitigation process workflow.

7. A computer-implemented method for processing workflows, including: Monitoring a user interface via a processor to generate an activity log including a step flow; Extracting features and common variables from unstructured data in the activity log via the processor and generating structured log events based on the extracted features and common variables; Generating a workflow model via the processor based on the structured log events, wherein generating the workflow model includes: Detecting common start events between monitored processes; Merging and optimizing the processes based on the common start events; Detecting common subprocesses between the processes; Detecting transition rules for each process in the merged process; Performing classification to detect context; and Generating an optimized flow model based on common start events, transition rules, common subprocesses, and context; and automating or assisting the workflow via the processor based on the generated workflow model.

8. The computer-implemented method according to claim 7, including converting the structured log events into start events, step flows, and end events.

9. The computer-implemented method according to claim 7, wherein, Generating the workflow model includes adjusting the optimized process model based on user feedback.

10. The computer-implemented method according to claim 7, including clustering across customers and generating an improved workflow recommended to each customer in the cluster.

11. The computer-implemented method according to claim 7, including interactively performing predictive analysis to suggest the next step for a user manual process.

12. The computer-implemented method according to claim 7, including generating an additional workflow model based on the structured log events and automatically executing the additional workflow model to generate multiple results to be presented.

13. A computer program product for processing a workflow, the computer program product comprising program code executable by a processor to cause the processor to: Monitor a user interface to generate an activity log including a step flow; Extract features and common variables from unstructured data in the activity log and generate structured log events based on the extracted features and common variables; Generate a workflow model based on the structured log events, wherein, The processor is configured to: Detect common start events between monitored processes; Merge and optimize the processes based on the common start events; Detect common subprocesses between the processes; Detect transition rules for each process in the merged process; Perform classification to detect context; And Generate an optimized flow model based on common start events, transition rules, common subprocesses, and context; And automate or assist the workflow based on the generated workflow model.

14. The computer program product according to claim 13, further comprising program code executable by the processor to convert the structured log events into start events, step flows, and end events.

15. The computer program product according to claim 13, further comprising program code executable by the processor to adjust the optimized flow model based on user feedback.

16. The computer program product according to claim 13, further comprising program code executable by the processor to perform clustering across customers and generate improved workflows recommended for each customer in the cluster.

17. The computer program product according to claim 13, further comprising program code executable by the processor to interactively perform predictive analysis to suggest the next step for a user manual process.

Citation Information

Patent Citations

  • Workflow excavating method based on inter-movement dependency relation analysis

    CN103218692A

  • Log mode discovery method and system

    CN108241658A

  • Efficient cross customer analytics

    US10467635B1

  • Automatic and dynamic predictive analytics

    US20160189203A1

  • Transformation of process model specification between formats

    US20180089602A1