Safety incident investigation workspace generation and investigation control

Abstract

A safety investigation platform in a sovereign cloud includes a request processing system that receives a request for investigating an incident. A control message processing system creates a workspace in the sovereign cloud so that an investigation can be conducted in the workspace. An investigation package including investigation resources used in the investigation is identified, and the workspace is preconfigured with the identified investigation package. The control message processing system uses the investigation package to perform an investigation task in the workspace.

Description

Background Art

[0001] Computer systems are now widely used. Many computer systems host services that are accessed and used by remote client computing systems. For example, many computing systems provide cloud-based services in which various software applications are provided as services to clients.

[0002] In these types of services, a variety of different types of incidents may occur that will be investigated for correction. For example, a feature or component of the service may fail, have an error, or operate in an otherwise unexpected manner. Similarly, security breach type incidents may occur in which a covert actor gains or attempts to gain access to customer data.

[0003] These types of services can be provided across multiple different compliance boundaries. The compliance boundaries define what is sometimes called a "sovereign cloud." Different sovereign clouds can be divided along compliance boundaries. Each of the different sovereign clouds can have different compliance rules or regulations that govern how data is handled, data access, and other security issues. Data residing in a sovereign cloud that is geographically located in one region, such as Europe, can be managed by compliance rules for digital data that are applied in that region. However, data residing in a sovereign cloud that is located in another geographic region, such as the United States, can be managed by a different set of compliance rules that are applied in that region. Therefore, it can be said that the two sovereign clouds are separated by a compliance boundary because they are managed by different compliance rules.

[0004] For example, a particular sovereign cloud may have compliance rules that impose certain restrictions on access to production servers in order to limit exposure or potential exposure to customer data. Other sovereign clouds may have compliance rules or regulations that prohibit the removal of data from the sovereign cloud (e.g., prohibiting the movement of data across compliance boundaries).

[0005] The above discussion merely provides general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter. Summary of the invention

[0006] A safety investigation platform in a sovereign cloud includes a request processing system that receives a request for investigating an incident. A control message processing system creates a workspace within the sovereign cloud so that an investigation can be conducted within the workspace. An investigation package including investigation resources used in the investigation is identified, and the workspace is preconfigured with the identified investigation package. The control message processing system performs an investigation task within the workspace using the investigation package.

[0007] This summary is provided to introduce a selection of concepts in a simplified form that are further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all of the disadvantages mentioned in the background. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a block diagram of an example of a computing system architecture.

[0009] Figure 2A and Figure 2B (collectively referred to herein as FIG. 2 ) shows a diagram of Figure 1 Flowchart of one example of the operation of the architecture illustrated in FIG.

[0010] Figure 3 is a block diagram illustrating one example of a request processing system in greater detail.

[0011] Figure 4 is a block diagram illustrating one example of a control message processing system in more detail.

[0012] Figure 5 It is illustrated in Figure 3 The request processing system illustrated in Figure 4 A flow chart of one example of the operation of a control message processing system is illustrated in FIG.

[0013] Figure 6 is a block diagram illustrating one example of a data / tool ​​ingestion system in more detail.

[0014] Fig. 7A and Figure 7B (collectively referred to herein as FIG. 7 ) shows a diagram of Figure 6 Flowchart of one example of the operation of the system shown in FIG. 1 to ingest data and / or tools into a workspace.

[0015] Figure 8 is a block diagram illustrating one example of a security log generation system in more detail.

[0016] Fig. 9 It shows that Figure 8 FIG. 1 is a flowchart of an example of an operation of a security log generation system storing information in a security log storage device.

[0017] Fig.10 is a block diagram illustrating one example of a machine learning investigation system in more detail.

[0018] Fig.11 It is illustrated in Fig.10A flowchart of an example of the overall operation of the machine learning survey system to generate a survey package model and a branching logic model is shown in FIG.

[0019] Fig.11A is a flow chart illustrating one example of the operation of a survey model to generate a survey package.

[0020] Fig.12 It is illustrated in Fig.10 Flowchart of one example of operation of a machine learning survey system using a survey bag model is shown in FIG.

[0021] Fig.13 It shows that Fig.10 A flowchart of one example of the operation of a machine learning investigation system using a branching logic model is illustrated in FIG.

[0022] Fig.14 It shows that Figure 1 The illustrated architecture is a block diagram of an example in which the architecture is deployed in a cloud computing architecture.

[0023] Fig.15 is a block diagram illustrating one example of a computing environment that can be used in the architecture shown in the previous figures. DETAILED DESCRIPTION

[0024] As discussed above, compliance boundaries can make it difficult to investigate different incidents that occur within services provided within different sovereign clouds defined by those compliance boundaries. For example, it may be difficult to gain access to production servers in order to avoid any accidental disclosure of customer data. Similarly, moving data out of the sovereign cloud (e.g., across a compliance boundary) for investigation may not be an option as this may violate compliance requirements. This can make troubleshooting any security or service incidents very difficult.

[0025] Therefore, this discussion is about a security investigation platform, in which an investigator can create a dedicated investigation workspace within a specific compliance boundary in which services are provided. The security investigation platform includes a request processing system and a control message processing system. The request processing system can be a system facing the investigator (or user), and the workspace cannot be accessed without the control message processing system. The control message processing system manages the workspace based on the request received from the request processing system and performs tasks in the workspace. The control message processing system cannot be accessed by the user except receiving control messages from the request processing system. As described below, it is also possible to authenticate and / or approve requests for performing operations in the workspace. Therefore, the request processing system is isolated from the workspace, and the control message processing system is isolated from the user. Data and other functions or tools can be ingested into the workspace so that the tools can be used to operate on the data to perform various different types of investigation tasks. Data from the workspace is archived as evidence in a secure log storage device. Similarly, the machine learning system can access the secure log storage to generate a machine learning model that can be used to suggest data and (investigation tools) that can be used in a workspace generated to investigate future incidents. These can be pre-loaded into the workspace for the investigator once the workspace is created. The machine learning system can also be used to generate a branching logic model that can be used to suggest the next investigative task when a future investigation is conducted in the workspace.

[0026] Figure 1 1 is a block diagram of one example of a computing system architecture 100. The architecture 100 includes a security investigation platform service instance 102 that can access service data sources 104-106. In one example, there may be a security investigation platform service instance 102 deployed within each sovereign cloud, enabling incidents to be investigated within the sovereign cloud without any data crossing compliance boundaries.

[0027] exist Figure 1 In the example shown in , the client computing system 108 can access the security investigation platform service instance 102 through a network 110. Thus, the network 110 can be any of a variety of different types of networks, such as a wide area network, a local area network, a near field communication network, a cellular communication network, or any of a variety of other networks or combinations of networks.

[0028] Figure 1It is also shown that, in one example, the client computing system 108 generates an interface 112 for interaction by a user 114. The user 114 may be an investigator or other user who wishes to investigate an incident that occurred in one of the service data sources 104-106. Thus, the user 114 can interact with the interface 112 to control portions of the computing system 108 and the security investigation platform service instance 102 so that the user 114 can investigate the incident.

[0029] exist Figure 1 In the example shown in , the security investigation platform service instance 102 illustratively includes an investigation central manager computing system 116, one or more different workspaces 118-120, and it can include other projects 122. The user 114 illustratively provides a request to the investigation central manager computing system 116 over the network 110, indicating that the user 114 wants to investigate an incident. The incident may have been reported by a user of one of the services, or it may have been automatically detected, etc. Upon receiving the request, the investigation central manager computing system 116 illustratively generates a workspace 120 within the compliance boundary in which the incident occurred (e.g., in the same sovereign cloud). The user 114 can request that data be ingested into the workspace 120. It can be stored in a data container 122 in the workspace 120. The user 114 can also request that an investigation tool (or tools) 124 can be ingested into the workspace 120 along with any other projects 126. The user 114 can then provide input to the investigation central manager computing system 116 indicating the investigation tasks that the user 114 wishes to perform within the workspace 120. This may be, for example, operating on the data 122 using a tool 124 (which can be an investigation tool or code, etc.) to discover characteristics or other information corresponding to the incident that occurred.

[0030] exist Figure 1In the example shown in , the investigation central manager computing system 116 can include one or more processors or servers 128, a request processing system 130, a control message processing system 132, a data / tool ​​ingestion system 134, a security log generation system 136, a security log storage device 138, a machine learning investigation system 140, and it can include a variety of other items 142. The request processing system 130 is illustratively user-oriented, in that it receives the requests input by the user 114 through the client computing system 108 and the network 110. It provides control messages to the control message processing system 132 based on the received user input. Also based on the user requests provided from the user 114 to the request processing system 130, the control message processing system 132 illustratively controls the creation of workspaces 118-120, manages the life cycle of those workspaces, controls the ingestion and security logging of data (using systems 134 and 136, respectively), and operates to perform investigation tasks within the workspaces 118-120. Thus, in one example, request processing system 130 cannot access workspaces 118-120 except to issue control messages to control message processing system 132, and control message processing system 132 is not available for access by users 114 or client computing systems 108 except through request processing system 130. This type of isolation enhances security.

[0031] Before describing the overall operation of the architecture 100 in more detail, a brief description of some of the items in the architecture 100 and their operation will now be provided. The data / investigation tool (or tool) ingestion system 134 is controlled by the control message processing system 132 to retrieve data and other functions (such as investigation tools, etc.) and ingest it into the workspaces 118-120. In doing so, the data / tool ​​ingestion system 134 can access data from the service data sources 104-106 and load it into a temporary data store within the data / tool ​​ingestion system 134. The data and / or tools can then be scanned (such as by using a malware scanner or other type of scanning system) to ensure that they do not contain any malware (or other secret logic) before being ingested into the specific workspace for which they are intended.

[0032] The security log generation system 136 illustratively generates an event record indicating all operations occurring relative to the workspace or in the workspace. The event record can identify who requested the task, the specific task performed, the data operated on, the code or logic unit used to operate on the data, the correlation between the task identified in the event record and other tasks performed in the workspace, and various other things. The security log generation system 136 illustratively generates those security event records and stores them in the security log storage device 138. In one example, the security log generation system 136 only adds additional records to the security log storage device 138 so that it does not modify or delete any existing records. Therefore, when needed, the information in the security log storage device 138 can be used to perform audit operations or other operations.

[0033] The machine learning investigation system 140 illustratively accesses information in the secure log storage device 138 (and it can also access other information) and performs machine learning based on the accessed information. The machine learning can be used to generate different types of machine learning models, which can be used to enhance future investigations. For example, it can generate an investigation package model (discussed below) that identifies different types of data and functions that are ingested into and used in a specific workspace when investigating an incident with specific characteristics. Therefore, when a similar incident is to be investigated in the future, the investigation package model can generate an investigation package that can be preloaded into a newly created workspace.

[0034] The machine learning investigation system 140 can also be used to generate a machine learning branching logic model (discussed below) that can be used during an investigation within a workspace. For example, when investigating an incident having specific characteristics within a particular workspace, the branching logic model can determine which investigative steps or tasks were performed within the workspace. It can also be determined whether those investigative tasks were successful or useful in identifying or remediating the incident. When similar incidents are reported, the branching logic model can then assist investigators in performing future investigations. For example, when a workspace is created to investigate a similar incident, the branching logic model can suggest the next investigative task or step to be performed when investigating the incident.

[0035] Figure 2A and Figure 2B(collectively referred to herein as FIG. 2 ) shows in more detail a flowchart illustrating an example of the overall operation of the architecture 100. First, assume that the security investigation platform service instance is deployed within the compliance boundary in which the service incident is to be investigated (e.g., on a sovereign cloud). This is indicated by box 150 in the flowchart of FIG. 2 . As discussed above, in one example, the security investigation platform service instance is deployed in each sovereign cloud in which it is to be used. This is indicated by box 152. As discussed above, it is illustratively deployed with a separate request processing system 130 and a control message processing system 132. This is indicated by box 154. It can also be deployed in other ways, as indicated by box 156.

[0036] At some point, the request processing system 130 detects input indicating that the user 114 wishes to begin an investigation based on the incident that has been identified. This is indicated by box 158 in the flowchart of Figure 2. The input can be authenticated and / or submitted for any desired approval. This is indicated by box 157. The detected input can also be processed in other ways. This is indicated by box 159.

[0037] The request processing system 130 then writes a message indicating the input to the control message processing system 132. This is described in more detail below and is indicated by box 160 in the flowchart of Figure 2. In response, the control message processing system 132 creates a workspace (such as workspace 120) in which the investigation will be conducted. It creates the workspace within the compliance boundary where the security investigation platform service instance 102 is also deployed. Creating the workspace is indicated by box 162 in the flowchart of Figure 2.

[0038] In one example, the control message processing system 132 may access the machine learning investigation system 140 to determine if there are any suggested investigation packages for this type of incident that should be preloaded into the workspace 120. This is indicated by block 164 in the flowchart of FIG. 2. This can be done using a machine learning investigation package model, as briefly described above and will be discussed below with respect to FIG. Figure 10-13 Described in more detail. The investigation package model using machine learning is indicated by box 166. The model will receive as input the characteristics of the incident to be investigated, and output an indication of any pre-existing investigation packages that may assist in the investigation.

[0039] The suggested survey package may identify survey resources (such as data and / or computing / analysis capabilities, such as survey tools or code) that may be employed by the user 114 in performing the survey. This is indicated by box 168 in FIG. 2. The survey package may also include other items, as indicated by box 170.

[0040] If there are any suggested survey packages, they can be ingested into the workspace 120 by the data / tool ​​ingestion system 134. This is indicated by box 172 in the flowchart of Figure 2. In one example, the suggested survey package will be presented by the request processing system 130 for approval by the user 114. Once approved, it can be ingested into the workspace 120. The ingestion of the suggested survey package with user approval is indicated by box 174. In another example, the suggested survey package can be automatically ingested, thereby automatically pre-configuring the workspace 120 for the user 114. This is indicated by box 176. It can also be suggested and / or ingested into the workspace in other ways, and this is indicated by box 178.

[0041] It is also possible that the user 114 may wish to ingest other data and / or tools in addition to the data and / or tools ingested based on the suggested survey package. In this case, the user 114 can provide input to the request processing system 130 to make such a request. In response, the system 130 can write a control message to the control message processing system 132, which in turn can control the ingestion system 134 to ingest the requested data and / or tools. In another example, the system 130 writes the control message directly to the ingestion system 134. Ingestion of any other requested data and / or tools is indicated by box 180 in the flowchart of Figure 2.

[0042] Once the workspace 120 is configured with the desired data and the desired computational / analysis functions (or tools) 124 in the data container 122, the user 114 may provide input to the request processing system 130 requesting that a particular investigative task be performed within the workspace 120. For example, the request may indicate that one of the tools or function blocks 124 is to operate on a particular portion of the data in the data container 122. This is merely an example, and other investigative tasks may also be performed. The use of the control message processing system 132 to perform an investigative task within the workspace 120 based on a user request provided to the request processing system 130 is indicated by box 182 in the flowchart of FIG. 2 .

[0043] As briefly mentioned above (and as described below with respect to Figure 10-13The machine learning investigation system 140 (described in more detail) may also have a machine learning branching logic model that can be used to assist the user 114 in conducting an investigation within the workspace 120. The branching logic model receives input indicating the characteristics of the incident being investigated, and input indicating specific tasks or steps that have been performed so far in the investigation in the workspace 120. Predictive investigation branching can then be performed to identify and / or suggest the next investigation task to be performed. This is indicated by box 184 in the flowchart of Figure 2. Using the machine learning branching logic model to perform the task is indicated by box 186. Presenting the identified tasks as suggested tasks for approval by the user 114 is indicated by box 188. In another example, those tasks can be performed automatically, and this is indicated by box 190. Predictive investigation branching can also be performed in a variety of other ways, and this is indicated by box 192.

[0044] The secure log generation system 136 also records all operations in the secure log storage device 138 along with various different types of identification data (or metadata) that identify the operations and different characteristics of the operations. Recording these operations is indicated by box 194 in the flowchart of Figure 2. This can include recording comments provided by the user 114 indicating the results of the investigation and / or the results of individual tasks or steps performed during the investigation. Recording investigator comments is indicated by box 196. Recording operations can be performed in a variety of other ways, some of which are described below with respect to Figure 8 and Fig. 9 This is indicated by block 198 in the flow chart of FIG. 2 .

[0045] Likewise, as briefly discussed above, the machine learning investigation system 140 can then access the security log storage device and any other relevant information and perform machine learning to train (generate or update) the investigation package model and the branching logic model. This is indicated by box 200 in the flowchart of Figure 2. In one example, the machine learning is performed after the investigation is completed. In another example, it can also be performed during the investigation.

[0046] Before the investigation is complete, as indicated by block 202, processing may return to block 182 where the investigator 114 continues to perform investigation tasks or steps within the workspace 120 to continue the investigation. During those steps, additional data or tools may be ingested into the workspace 120. Additional information may be recorded and / or additional machine learning can be utilized or performed.

[0047] Figure 3 is a block diagram illustrating one example of request processing system 130 in more detail. Figure 3, the request processing system 130 illustratively includes a client interaction logic unit 204, an authentication / approval logic unit 206, a message queue interaction logic unit 208, a timeout processing logic unit 210, a data store 212, and it can include various other items 214. The client interaction logic unit 204 illustratively detects user input from the user 114 (provided through the client computing system 108) and generates output that can be used for interaction by the user 114 on the interface 112. Those user interactions can be detected and indications thereof can be provided to other items in the investigation central manager computing system 116.

[0048] The authentication / approval logic unit 206 illustratively authenticates the user 114. By doing so, it is able to determine whether the user 114 is authorized to have the access rights that the user 114 is requesting. It can authorize or authenticate the user 114 and the request in a number of different ways. Similarly, it can submit any request received to any desired approval process and then take action on it. The approval process can be manual, automatic, or a combination.

[0049] The message queue interaction logic unit 208 illustratively writes information indicating the user request it has received to a message queue (described in more detail below). For example, when a user 114 requests to create a workspace, a control message will be written to the control message queue. The control message will indicate this to the control message processing system 132. In another example, a scan control message may be written to a scan control message queue (also described below) indicating that the user 114 has requested that specific data be ingested into the workspace. In this case, the data / function ingestion system 134 performs a scan operation on the data before the data is ingested into the workspace. This is done in response to a scan message written to the scan message queue, as described below.

[0050] The timeout processing logic unit 210 can obtain timeout information from the control message processing 132 system and provide the timeout information when the user 114 requests the timeout information. For example, each control message written to the control message queue can be accessed by a different instance of the control message processing system 132. When it is accessed, a timeout variable can be modified, which indicates when the control message is accessed. The timeout variable can indicate a specific amount of time that a specific instance of the control message processing system must perform a task identified in the control message. It can report information about the timeout variable to the request processing system 130, wherein the timeout processing logic unit 210 can present the information to the user 114 when requested.

[0051] Data store 212 may be a cache, or other data store that stores information that may be needed by request processing system 130 .

[0052] Figure 4 is a block diagram illustrating one example of the control message processing system 132 in more detail. Figure 4 In the example shown in , the control message processing system 132 includes a control message queue 216 that can store control messages 218-220 written by the message queue interaction logic unit 208 in the request processing system 130. Each of the control messages 218-220 can indicate a request received by the client interaction logic unit 204 in the request processing system 130. Therefore, each of the control messages 218-220 can indicate a task or operation to be performed when conducting an investigation within the workspace.

[0053] The control message processing system 132 may also include a queue interaction logic unit 222 , one or more control message processing logic instances 224 - 226 , and it can include a variety of other items 228 .

[0054] The queue interaction logic unit 222 illustratively interacts with the control message queue 216 to select the next queued message for access by one of the control message processing logic instances 224-226. Each of those instances can obtain a control message from the control message queue 216 (using the queue interaction logic unit 222) and begin executing a task or operation identified by (or corresponding to) the control message.

[0055] exist Figure 4 In the example shown in , each control message processing logic instance can include a workspace creation logic unit 230, a workspace access management logic unit 232, a workspace lifecycle management system 234, a resource request logic unit 236, a data recording logic unit 238, a timeout logic unit 240, a request processing system interaction logic unit 242, and it can include a variety of other survey task running logic units 244.

[0056] The workspace creation logic unit 230 is illustratively used to create a new workspace (e.g., workspace 120) based on a control message indicating that a workspace is to be created. The workspace access management logic unit 232 illustratively manages access to the workspace. For example, in one example, a particular workspace can be shared by multiple different users so that they can collaboratively investigate an incident. Those users will have authentication or access information that can be used to authenticate those users or authorize those users to access the workspace. This can be managed by the workspace access management logic unit 232. In doing so, the logic unit 232 can communicate with another authorization or authentication system, or it can perform these types of management tasks itself.

[0057] The workspace lifecycle management logic unit 234 illustratively manages the lifecycles of the different workspaces 118-120 created. For example, the workspace may have a use period corresponding to a particular investigation being conducted. The lifecycle may also be limited or determined in other ways. When the lifecycle of a particular workspace is exhausted (as indicated by workspace resource release criteria, such as a survey being completed or other criteria), the logic unit 234 ensures that information from the workspace has been recorded by the security log generation system 136, and then releases the computing and data storage resources (e.g., processors and memory or other computing and data storage resources, such as blob storage devices, file sharing storage devices, etc.) used by (or allocated to) the particular workspace so that it can be used in other ways.

[0058] Resource request logic 236 determines when a resource (such as data and / or computing or analysis capabilities or other tools) has been requested for ingestion. It then interacts with data / tool ​​ingestion system 134 to request that those resources be scanned and ingested into the workspace. Data logging logic 238 provides information to security log generation system 136 so that it can generate a security event log indicating all tasks and different operations performed within the workspace.

[0059] The timeout logic unit 240 identifies the timeout variable corresponding to the particular control message currently being processed by the control message processing logic instance 224. It can report changes in this timeout variable to the request processing system 130 so that the changes can be provided to the user 114 when requested.

[0060] The request processing system interaction logic unit 242 illustratively handles different interaction items between the control message processing logic instance 224 and the request processing system 130. For example, it can handle the described interaction between the timeout logic unit 240 and the timeout processing logic unit 210 in the request processing system 130. It can also handle other interactions.

[0061] The other investigation task execution logic 244 can include a variety of different types of logic for executing a variety of different types of tasks or steps within the workspace. These can vary based on the incident being investigated, the type of investigation, etc.

[0062] Figure 5 is a flow chart illustrating one example of how the request processing system 130 and the control message processing system 132 work to perform a requested operation that may be requested by a user 114 within a particular workspace. At some point, the client interaction logic unit 204 will detect user input regarding a particular survey. This is done by Figure 5 , as indicated by box 250 in the flowchart of . It can first use the authentication logic unit 206 to authenticate the user, as indicated by box 252. The user input can request the platform service instance 102 to start an investigation or create a workspace. This is indicated by box 254. The request can be to ingest data or tools into the workspace, as indicated by box 256. It can be to perform an investigation task within the workspace, as indicated by box 258. It can be to log data to various locations, as indicated by box 260; or it can be to end the investigation, as indicated by box 262. All of these inputs can be inputs in the form of commands received from the client computing system 108, or they can be inputs in other forms. This is indicated by box 264. The client interaction logic unit 204 can also detect client input in a variety of other ways, and this is indicated by box 266.

[0063] Based on the detected user input, the message queue interaction logic unit 208 writes the control message to the control message queue 216 in the control message processing system 132. This is indicated by box 268. Note again that the request processing system 130 cannot directly access the workspaces 118-120. This is indicated by box 270. The request processing system 130 can also use the data store 212 to perform any required temporary storage operations. This is indicated by box 272. The request processing system 130 can also perform other operations to write the control message to the control message queue 216. This is indicated by box 274.

[0064] The queue interaction logic unit 222 illustratively listens to the control message queue 216 to determine whether any control messages 218-220 have been written there. When this occurs, the queue interaction logic unit 220 retrieves the next control message from the control message queue, as indicated by block 276. The queue interaction logic unit 222 can also retrieve messages from the control message queue 216 in other ways. This is indicated by Figure 5 This is indicated by block 280 in the flowchart of FIG.

[0065] The control message processing logic instance 224 then receives the control message from the queue interaction logic unit 222. Figure 5 The control message processing logic instance 224 then uses its logic unit to execute tasks in the workspace based on (or corresponding to) the control message it has received. This is indicated by box 284. The instance 244 can use the workspace creation logic unit 230 to create a workspace, as indicated by box 286. The instance 244 can use the workspace access management logic unit 232 to manage access to the workspace, as indicated by box 288. The instance 244 can use the workspace lifecycle management logic unit 234 to manage the lifecycle of the workspace, as indicated by box 290. The instance 244 can use any of the multiple task running logic units 244 to run one or more survey tasks, as indicated by box 292. The instance 244 can use the timeout logic unit 240 to perform a timeout update, as indicated by box 294. The instance 244 can use the data logging logic unit 238 to access various diagnostic logs and log the information, as indicated by block 296. The instance 244 can also request a call to the secure log generation system 136 to store data in the secure log, as indicated by block 298. The instance 244 can perform any of a variety of other tasks based on the received control message, as indicated by block 300.

[0066] As long as there are control messages in the control message queue 216, processing returns to block 276 where the queue interaction logic unit 222 obtains the message from the queue and provides it to the control message processing logic instance. Figure 5 This is indicated by block 302 in the flowchart of FIG.

[0067] Figure 6 is a block diagram illustrating one example of the data / tool ​​ingestion system 134 in more detail. Figure 6In the example shown in , the data / tool ​​ingestion system 134 illustratively includes a scan control message queue 304, which can include a plurality of different scan control messages 306-308. The system 134 also illustratively includes a resource (data / tool) access system 310, a temporary data store interaction logic unit 312, a temporary data store 314, a scanning system 316, a workspace ingestion logic unit 318, and it can include a variety of other items 320. The scanning system 316 can include a queue interaction logic unit 322, a logical identifier 324, a plurality of different types of scanning logic units 326-328, and it can include other items 330.

[0068] When the request processing system 130 receives a request to ingest data and / or tools into the workspace, the client interaction logic unit 204 provides an indication of this to the message queue interaction logic unit 208. The message queue interaction logic unit 208 then writes a scan control message to the scan control message queue 304. The scan control message identifies the resource (data and / or tool) that has been requested for ingestion into the workspace. The queue interaction logic unit 322 listens to the scan control message queue 304, and when there is a message, it obtains the next message from the queue and provides it to the logic identifier 324 and the resource access system 310. The resource access system 310 accesses the specific service data source 104-106 where the data and / or tool or logic resides, and obtains the data and / or tool or logic unit using the temporary data storage interaction logic unit 312 and stores it in the temporary data storage 314.

[0069] The logic identifier 324 identifies a particular type of scanning logic 326-328 that is used to scan the data and / or tools (or code) that are to be ingested and that have been temporarily stored in the temporary data store 314. For example, assume that the user 114 has requested to ingest an image of a virtual machine from a particular service into the workspace. The image of the virtual machine will be accessed by the resource access system 310 and stored in the temporary data store 314 by the temporary data store interaction logic 312. The scanning logic identifier 324 identifies a particular set of scanning logic 326-328 that will be used to scan the virtual image to ensure that it is not corrupted, does not contain malware, etc. For example, the scanning logic identifier 324 can identify a set of forensic tools that will be run on the virtual machine image stored in the temporary data store 314 to ensure that it is forensically acceptable to be ingested into the workspace.

[0070] The scanning system 316 generates an output to the workspace ingestion logic unit 318, which indicates the results of the scanning operation. If the scanning operation indicates that data and / or tools can be ingested into the workspace, the workspace ingestion logic unit 318 retrieves the data and / or tools from the temporary data storage 314 and ingests them into the workspace where they are used in the investigation. However, if the scanning logic unit indicates that the data and / or tools should not be ingested for some reason, it indicates this situation to the control message processing logic instance 224 responsible for handling the data ingestion, and in this instance, the request processing system interaction logic unit 242 provides an indication to the request processing system 130, which indicates the malware or other problems found by the scanning logic unit. It can then be presented to the user 114 or processed in another way.

[0071] Fig. 7A and Figure 7B (collectively referred to herein as FIG. 7 ) shows in more detail a flowchart illustrating an example of the operation of the data / tool ​​ingestion system 134 . First, assume that the client interaction logic unit 204 in the request processing system 130 receives a request from a user 114 (or elsewhere) requesting that data and / or tools or code be ingested into a particular workspace. This is indicated by box 332 in the flowchart of FIG. 7 . The request can indicate whether the data / tool ​​ingestion will be manual (as indicated by box 331) or automatic (as indicated by box 333). Automation or automatic means that the task can be performed without further involvement, except that the task may be initiated or approved. It can include other items as well as indicated by box 335. The message queue interaction logic unit 208 then places a scan control message in the scan control message queue 304, which indicates the data to be ingested. This is indicated by box 334.

[0072] The queue interaction logic 332 in the scanning system 316 then obtains the scan control message from the scan control message queue 304. This is indicated by box 336. The resource access system 310 obtains the data and / or tools to be ingested into the workspace from the specific service data store 104-106. This is indicated by box 338. The temporary data store interaction logic 312 stores the data and / or tools in the temporary data store 314 before the data and / or tools are ingested into the workspace. This is indicated by box 340.

[0073] This can be done in a variety of different ways. For example, it can be done manually, in which case a user can use an upload tool to upload (one or more) data / tools to temporary (e.g., blob) storage 314. This is indicated by box 341. The upload can also be done automatically. For example, the ingest request can include a source path and a destination URI. The resource access system 310 and the temporary data storage interaction logic unit 312 use the source path and destination URI, respectively, to access the resource and store it in the temporary data storage 314. This is indicated by box 343. The data / tool ​​can be uploaded in other ways, as indicated by box 345.

[0074] The scan logic identifier 324 then identifies a set of scan logic 326-328 that will be run on the resource that has just been stored in the temporary data store 314. This is indicated by box 342. The identified scan logic unit is then run on the resource in the temporary data store 314. This is indicated by box 344 in the flowchart of Figure 7. The scan logic unit will generate an output indicating the result of the scan. For example, it may indicate that the resource is clean (suitable for ingestion into the workspace). It may indicate that the resource has a virus or other malware, or some other secret characteristics. Determining whether the resource is clean (for example, suitable for ingestion into the workspace) is indicated by box 346 in the flowchart of Figure 7. If not, the request to ingest the resource is processed accordingly. This is indicated by box 348. For example, it may simply be that the resource is not ingested into the workspace and the request is rejected. This is indicated by box 350. An error or alarm may be triggered for presentation to the user 114. This is indicated by box 352. The get request may also be processed in a variety of other ways, and this is indicated by block 354 .

[0075] However, if it is determined at block 346 that the resource is clean, then the workspace ingest logic 318 imports the resource into the workspace for the investigation. This is indicated by block 356.

[0076] Figure 8 1 is a block diagram showing one example of the security log generation system 136 and the security log storage device 138 in more detail. Figure 8 In the example shown in , the security log generation system 136 illustratively includes an interface generation / interaction logic unit 358, an input stream merging logic unit 360, a diagnostic log interaction logic unit 362, a security event record generation logic unit 364, a storage interaction logic unit 366, and it can include various other items 368. Similarly, in Figure 8In the example shown in , the security log storage 138 can store security events in table storage 370 , blob storage 372 , or in a variety of other structures as indicated by box 374 .

[0077] In brief, as examples, the security log generation system 136 can receive a variety of different types of information from different parts of the security investigation platform service instance 102 (and from other places) to generate security event records for storage in the security log storage device 138. For example, it can receive information from the control message processing system 132, such as Figure 8 This may include information from the request processing system 130, such as that indicated by block 376 in the block diagram of FIG. Figure 8 , as indicated by box 378 in the block diagram of . It can include information from workspaces 118-120, such as Figure 8 It can receive information from diagnostic logs in various computing systems, as indicated by block 382. It can also receive various other information 384.

[0078] The interface generation / interaction logic unit 358 illustratively exposes an interface 386 that can be called by various systems that provide information to the security log generation system 136. The interface 386 can expose methods or functions that allow the security log generation system 136 to obtain the information required to generate a security event record. For example, the interface 386 may include methods and functions for receiving an event creation time or an event occurrence time, an event type indicating what occurred, identifying a user who requested the event, or a user ID that is otherwise associated with the event, an identifier of a resource that operates on it (such as a location where data is ingested, which identifies the data, etc.), an event correlation identifier that identifies the event correlation that will be the subject of the event record with other events, any diagnostic log data corresponding to the event, and it can include various other customizable parameters or other parameters. The input stream merging logic unit 360 can merge the various input streams 376-384 before or after they pass through the interface 386.

[0079] The diagnostic log interaction logic unit 362 illustratively interacts with various components, systems or other items in the security platform or from which the security platform receives information to obtain diagnostic logs from those systems. In one example, the diagnostic log interaction logic unit 362 is configured to obtain diagnostic log information from related systems each time an event is created. In other examples, it obtains diagnostic log information from all related systems intermittently, regularly, or based on other criteria, even when other security log events are not processed.

[0080] The security event record generation logic 364 generates a security event record for storage and the security log storage 138 based on the received information. Figure 8 The logic unit 364 is shown to have generated a security event record 388, which includes an event creation time 390, an event type 392, a user ID 394, an identifier 396 of the resource on which the operation was performed, an event correlation ID 398, any related diagnostic log data 400, and any of a variety of other (e.g., customizable) parameters 402.

[0081] Once the security event record 388 is generated, the storage interaction logic unit 366 stores it in the desired data structure in the security log storage device 138. For example, various types of metadata may be stored in the table storage device 370. Diagnostic log data may be stored as a blob storage device 372. These are just examples.

[0082] Fig. 9 It is illustrated in Figure 8 Flowchart of an example of the operation of the security log generation system 136 shown in FIG. First, assume that the interface generation / interaction logic 358 exposes an interface having functions or methods for receiving information for creating and storing security log event records. This is done by Fig. 9 The interface generation / interaction logic 358 then detects the interaction with the interface to generate an event record. This is indicated by box 406. For example, specific criteria can automatically trigger the generation of an event record (such as running a task within the workspace, ingesting data into the workspace, scanning data to be ingested, or any variety of other things). In another example, it may be that a user has requested the creation of an event record. Various systems may also take actions that trigger the creation of an event record. It can also be detected by other means.

[0083] The interface generation / interaction logic unit 358 then captures the event and the metadata surrounding the event through the interface 386. Fig. 9 By doing so, multiple data streams can be merged to generate the event record, as indicated by block 410. The event record can include those items shown in security event record 388, as also indicated by Fig. 9 As illustrated in the flow chart of .

[0084] When the information is captured, the security event record generation logic unit 364 generates a corresponding security event record. Fig. 9The security event record is provided to the storage interaction logic unit 366, which stores the security event record in the security log storage device 138. Fig. 9 In one example, the security log generation system 136 is configured to only generate new event records and store them in the security log storage device 138. This is indicated by box 416. In this way, already existing records cannot be deleted or modified. This is indicated by box 418. The information can be stored in the table storage device 370, the blob storage device 372, or in a variety of other ways 374. The logic unit 358 can also generate an output that indicates to other systems, components, or logic units that a new event record is stored in the storage device 138. This is indicated by Fig. 9 This is indicated by box 419 in FIG.

[0085] Fig.10 is a block diagram illustrating one example of a machine learning investigation system 140 in more detail. Fig.10 In the example shown in , the system 140 includes a learning trigger criteria detection logic unit 420, a security log interaction logic unit 422, a model generation / update data identifier 424, an investigation package model generation / update logic unit 426 (which can include a package model trainer 451, a package generation model trainer 453, and which can include other items 455), a branch model generation / update logic unit 428, a model input criteria logic unit 430, a configuration system 433, and which can include various other items 434. Fig.10 In the example shown in , the machine learning investigation system 140 is also shown to have one or more investigation package models 436, investigation package generation models 437, and branch logic models 438. Investigation package model 436 includes trigger detection logic unit 440, package identifier 442, output generator 444, and it can include other items 446. Investigation package generation model 437 includes trigger detection logic unit 439, package identifier 441, output generator 443, and it can include other items 445. Branch logic model 438 includes trigger detection logic unit 448, branch identifier 450, output generator 452, and it can also include other items 454.

[0086] Configuration system 433 can include automatic provisioning logic 447 and request processing system interaction logic 432. It can also include other items 449.

[0087] Fig.10The machine learning investigation system 140 is also shown interacting with an investigation package storage 456. The investigation package storage 456 can store one or more different investigation packages 458, and it can include various other items 460.

[0088] In short, in operation, the learning trigger criteria detection logic unit 420 detects criteria that trigger the machine learning investigation system 140 to perform model training to train (generate or update) a model, or to apply input to use a model to identify an investigation package or an investigation branch step. For example, assume that the learning trigger criteria detection logic unit 420 detects criteria that indicate that the machine learning investigation system 140 is to generate or update a model. For example, this can occur when new information is stored in the security log data storage 138. This can occur when the investigation is over and the workspace is closed. It can also occur under other criteria. In this case, the security log interaction logic unit 422 obtains information from the security log storage device 138 so that it can train one or more models (e.g., generate the model or update the model) based on the information in the security log storage device 138.

[0089] Model generation / update data identifiers 424 identify different types of data to be used to train models in system 140. For example, different sets of data and / or tools that are ingested into the workspace to investigate a particular type of incident may be identified and this information provided to investigation package model generation / update logic 426. Logic 426 then uses this information to generate and / or update one or more different investigation package models 436 and 437.

[0090] The model generation / update data identifier 424 may also identify which specific tasks were performed during the investigation in the workspace. This information may be provided to the branching logic model generation / update logic unit 428. The logic unit 428 may use the information to train (e.g., create or update) the branching logic model 438.

[0091] Once models 436, 437, and 438 are generated, they can be used to assist in the investigation of an accident. For example, the investigation package generation model 437 can identify different investigation packages 458 that may be useful in investigating accidents of different accident types. The investigation packages 458 can be associated with the characteristics of different accidents so that when an accident with those characteristics occurs in the future, the relevant investigation packages 458 can be identified and preloaded into the workspace, for example, using the investigation package model 436 and the configuration system 433.

[0092] For example, trigger detection logic 440 may receive model input criteria from model input criteria logic 430 indicating that an incident having specific characteristics has been reported and a workspace has been created for the incident. Package identifier 442 may identify one or more investigation packages 458, if any, generated by investigation package generation model 437 based on previous incidents having similar characteristics. Output generator 444 illustratively generates output indicative of those identified investigation packages and provides it to request processing system interaction logic 432, which can provide it to request processing system 130 for presentation to user 114 or another user.

[0093] Similarly, as an investigation proceeds in the workspace, tasks that have been performed in the investigation may be identified by the model input criteria logic unit 430 and provided to the branching logic model 438. The branching logic model 438 may detect those inputs using the trigger detection logic unit 448 and identify the next investigation task or step that may be suggested using the branch identifier 450. The output generator 452 generates an output indicating the next suggested task or branch. The request processing system interaction logic unit 432 can present the suggested task or branch to the user 114 or another user.

[0094] Fig.11 is a flow chart illustrating one example of the operation of the machine learning survey system 140 in generating a survey package model 436, a survey package generation model 437, and / or a branching logic model 438. First, assume that the learning trigger criteria detection logic unit 420 detects a learning trigger that triggers a learning operation so that the system 140 trains (generates or updates) a model. The learning trigger is detected by Fig.11 The trigger can be based on a variety of different criteria. For example, the learning operation can be triggered by a user input indicating that the user wants the system to train the model. This is indicated by box 464. The learning operation can be triggered by one or more new event records stored in the security log storage device 138 by the security log generation system 136. This is indicated by box 466. The learning can be triggered by a survey completed in the workspace 118-120. This is indicated by box 468. It can be triggered by the control message processing system 132 closing the workspace 118-120. This is indicated by box 470. The learning operation can also be triggered in a variety of other ways, which is indicated by box 472.

[0095] The security log interaction logic unit 422 then obtains information from the security log storage device 138. This is indicated by box 474. The information may be new information that has been added since the last learning operation was performed. It may be all the information that has been stored in the storage device 138 for a predetermined amount of time or a predetermined number of operations. It may also be other information.

[0096] The model generation / update data identifier 424 then parses the retrieved information to identify data for training (generating and / or updating) the model. This is indicated by box 476. For example, to generate or update the survey package model 436, the data identifier 424 may identify a specific subset of data retrieved from the secure log storage device 138 (as indicated by box 473). To generate or update the survey package generation model 437 (as indicated by box 473) or the branch logic model 438 (as indicated by box 475), the model generation / update data identifier 424 may identify a different subset of data retrieved from the secure log storage device 138. These are merely examples, and other model training data can be identified, as indicated by box 477.

[0097] This information is then used to train the model to be trained. If survey package model 436 is to be trained, the information is provided to survey package model generation / update logic unit 426, where package model trainer 451 trains model 436. A machine learning algorithm is run on the information to train (generate or update) model 436. If survey package generation model 437 is to be trained, the information is provided to package generation model trainer 453 which trains survey package generation model 437. If branch logic model 438 is to be trained, the information obtained by data identifier 424 is provided to branch logic model generation / update logic unit 428. A machine learning algorithm is run on the data to train (generate or update) branch logic model 438. Machine learning is performed to train the model by Fig.11 This is indicated by box 478 in the flowchart of FIG.

[0098] The training logic unit then outputs the trained models 436, 437 and / or 438 for use during the investigation. This is indicated by box 480. It can store any pre-configured survey packages 458 that have been generated by the survey package generation model 437 in the survey package storage 456. The model can also be output in other ways, as indicated by box 484.

[0099] Fig.11A 4 is a flowchart showing an example of how the survey package generation model 437 can be used. The trigger detection logic unit 439 first detects the model call trigger information that is calling the survey package generation model 437. Fig.11AThe trigger information can be based on user input 489 when the user 114 requests the generation of a relevant investigation package so that it can be loaded into the workspace. The model can be triggered based on an accident investigation signal that can be provided by the user 114 or another system, indicating that a new accident (or a threshold number of accidents) has been investigated. This is indicated by box 491. The model can be triggered based on an indication that additional data is available to generate more investigation packages 458. This is indicated by box 493. The model can also be called by other triggers, and this is indicated by box 495.

[0100] The model input criteria logic unit 430 then takes information (such as accident characteristics, which corresponds to the accident that has been investigated, or other information) and provides it to the investigation package generation model 437. This is done by Fig.11A The information may be obtained from the security log 138, as indicated by box 499. The information may also be obtained in a variety of other ways. Fig.11A This is indicated by block 501 in the flowchart of FIG.

[0101] The information is parsed by the model input criteria logic unit 430 to identify the model inputs to the model 437. The model inputs include information useful in generating new survey packets. Fig.11A This is indicated by block 503 in the flowchart of FIG.

[0102] Those features are provided as input to the survey packet generation model 437. This is done by Fig.11A Based on those inputs, package identifier 441 generates any investigation packages 458 that are helpful for the investigation using it. For example, package identifier 441 can identify the investigation resources (data, tools, code, functions, etc.) with corresponding characteristics used in the investigation (i.e., a successful investigation), and output generator 443 generates output indicating a new investigation package 458 that includes or identifies those resources.

[0103] The output generator 443 then stores the output as a survey package 458 in the survey package storage 456. Fig.11A As indicated by block 507 in the flowchart of Fig.11A As indicated by blocks 509 and 511 in the flowchart of , respectively, the packages 458 can be indexed by incident characteristics or a variety of other indexing criteria.

[0104] Fig.12 is a flow chart showing one example of how the survey package model 436 can be used. The trigger detection logic unit 440 first detects the model call trigger information that is calling the survey package model 436. Fig.12 , as indicated by box 486 in the flowchart of . The trigger information can be based on user input 488 when the user 114 is requesting the presentation of relevant investigation packages so that they can be loaded into the workspace. The model can be triggered based on an accident investigation signal 490 that can be provided by the user 114 or another system, indicating that an accident has been reported and will be investigated. The model can be triggered based on the creation of a workspace, as indicated by box 492. For example, each time a new workspace is created, this can trigger the investigation package model 436 to present suggested investigation packages for ingestion into the newly created workspace. The model can also be called by other triggers, and this is indicated by box 494.

[0105] The model input criteria logic unit 430 then obtains the accident characteristics corresponding to the accident to be investigated and provides them to the investigation package model 436. Fig.12 The characteristics of the incident may include a variety of different types of information. For example, an incident may be reported by a user in an incident report that describes the incident. Thus, the characteristics of the incident may include information in the incident report, as indicated by box 498. The characteristics may include an identifier of the specific service in which the incident occurred. This is indicated by box 540. It may include the type of incident (such as whether it was a problem with a component of a service or a potential security incident, etc.). This is indicated by box 542. The characteristics of the incident may include specific resources involved in the incident, as indicated by box 544. The characteristics may include a variety of other characteristics or metadata corresponding to the incident. This is indicated by box 544. Fig.12 This is indicated by box 546 in the flowchart of FIG.

[0106] Those characteristics are provided as input to an investigation package model 436. Based on those incidents, package identifiers 442 identify any relevant investigation packages 458 that might be helpful if ingested into the workspace. This can be done, for example, by comparing the characteristics of the newly reported incident to the characteristics of the incident from which the investigation package 458 was generated. Model 436 can be a neural network, or any of a variety of other classifiers or other types of models that take the accident characteristics as input and generate outputs that indicate one or more different investigation packages that might be helpful in the investigation.

[0107] The output generator 444 then generates an output indicative of the identified survey packages. The relevant survey packages are identified and the model output indicative of those survey packages is generated by Fig.12 This is indicated by box 548 in the flowchart of FIG.

[0108] Likewise, the identified investigation package may include data to be scanned and ingested into the workspace, as indicated by box 550. It may include functionality such as forensic tools or other logic, code, or other functionality that would be helpful to the investigation if scanned and ingested into the workspace. This is indicated by box 552. It may include a variety of other information, as indicated by box 554.

[0109] The model output is then processed by system 140. This is done by Fig.12 For example, the output can be provided to the control message processing system 132 to automatically configure the workspace with the identified survey package. This is indicated by box 558. The request processing system interaction logic unit 432 can be used to send an indication of the identified survey package to the request processing system 130 so that it can be presented to the user 114 for user authorization. This is indicated by box 560. Once authorization is received, this can be indicated to the control message processing system 132, which then ingests the survey package into the workspace. The model output can also be processed in a variety of other ways, and this is indicated by Fig.12 This is indicated by box 562 in the flowchart of FIG.

[0110] Fig.13 It shows that Fig.10 Flowchart of one example of a machine learning investigation system using a branching logic model 438 is illustrated in FIG.

[0111] The trigger detection logic unit 448 first detects a model call trigger that invokes the use of the model 438. This is done by Fig.13 This is indicated by box 564 in the flowchart of . This can be an input indicating that an investigation is in progress (such as an incident report has been received and the user 114 is attempting to investigate it). This is indicated by box 566. It can include information indicating that a task has been performed within the workspace. This is indicated by box 568. It can be a user input requesting the branching logic model 438 to suggest the next investigation task or operation. This is indicated by box 570. It can also be a variety of other triggering criteria, and this is indicated by box 572.

[0112] The model input criteria logic unit 430 then obtains various types of model inputs that can be used by the branching logic model 438 to identify the next task or step in the investigation. It provides those investigation characteristics to the branching logic model 438. This is done by Fig.13The characteristics may be different depending on the type of investigation (such as whether to investigate a potential security vulnerability, virus, performance issue, etc.). The type of investigation provided to the model 438 is indicated by box 576. The investigation characteristics may include incident characteristics that describe the incident being investigated. This is indicated by box 578. It can include an investigation task history (such as a history of tasks or investigation steps that have been performed in the workspace and the results of the task history). This is indicated by box 580. The investigation characteristics input into the branch logic model 438 can also include a variety of other characteristics, and this is indicated by box 582.

[0113] The branch identifier 450 then identifies the branch (e.g., the next task) to be executed in the workspace, and the output generator 452 generates a model output indicating the branch (next task). Fig.13 The model output may be indicated by box 584 in the flowchart of . For example, the model output may identify additional data sets that should be ingested into the workspace or additional tools or other functions that should be ingested into the workspace. This is indicated by box 586. The model output may identify the next computing task to be performed (such as the next set of forensic code to run). This is indicated by box 588. The model output can also indicate various other things, and this is indicated by box 590.

[0114] The model output is then processed. This is done by Fig.13 For example, the model output can be provided to the control message processing system 132, which automatically performs the next task identified by the model output. It can automatically ingest additional data or functions. It can perform the next investigation task within the workspace, etc. Automatically performing the next task is performed by Fig.13 This is indicated by box 594 in the flowchart of .

[0115] The model output may be sent by the request processing system interaction logic 432 to the request processing system 130, where it is presented for user authorization. This is indicated by box 596. For example, the next task may be authorized by the user 114 (or a different user) before being executed in the workspace. In this case, it can be presented to the user 114 by the request processing system 130 through the user interface 112 for authorization.

[0116] The model output can also be processed in a variety of other ways, and this is determined by Fig.13 This is indicated by box 598 in the flowchart of .

[0117] It will be noted that the above discussion has described a variety of different systems, components, tools, functions and / or logical units. It will be appreciated that such systems, components, tools, functions and / or logical units can be composed of hardware items that perform the functions associated with those systems, components, tools, functions and / or logical units (such as processors and associated memory, or other processing components, some of which are described below). In addition, the systems, components, tools, functions and / or logical units can be composed of software that is loaded into the memory and then operated by a processor or server or other computing components, as described below. The systems, components, tools, functions and / or logical units can also be composed of different combinations of hardware, software, firmware, etc., some examples of which are described below. These are just some examples of different structures that can be used to form the systems, components, tools, functions and / or logic. Other structures can also be used.

[0118] This discussion has referred to processors and servers. In one embodiment, the processors and servers include computer processors with associated memory and timing circuits not shown separately. They are functional parts of the systems or devices to which they belong, and are activated by and facilitate the functions of other components or items in these systems.

[0119] Likewise, many user interface displays have been discussed. It can take a variety of different forms, and a variety of different user-actuated input mechanisms can be set thereon. For example, the user-actuated input mechanism can be a text box, a check box, an icon, a link, a drop-down menu, a search box, etc. It can also be actuated in a variety of different ways. For example, it can be actuated using a click device (such as a trackball or a mouse). It can be actuated using a hardware button, a switch, a joystick or a keyboard, a thumb switch or a thumb pad, etc. It can also be actuated using a virtual keyboard or other virtual actuators. In addition, in the case where the screen displaying it is a touch-sensitive screen, it can be actuated using a touch gesture. In the same way, in the case where the device displaying it has a voice recognition component, it can be actuated using a voice command.

[0120] Many data stores have also been discussed. It will be noted that each of them can be divided into multiple data stores. For accessing their systems, all of them can be local, all of them can be remote, or some can be local and others can be remote. All of these configurations are contemplated herein.

[0121] Likewise, the accompanying drawings show a plurality of blocks with functions attributed to each block. It should be noted that fewer blocks may be used, and therefore functions are performed by fewer components. Likewise, more blocks and functions distributed in more components can be used.

[0122] Fig.14 is a block diagram illustrating an architecture 500 in which two sovereign clouds 502 and 504 are separated by a compliance boundary 505. Thus, data in cloud 502 is stored in a different geographic region than data in cloud 504, and digital data compliance rules governing the different regions are different. Fig.14 The architecture 100 is shown to be arranged in a cloud 502, in which services 104 and 106 are in the same sovereign cloud 502 as the security investigation platform service instance 102. The sovereign cloud 504 has services 104A and 106A (which can be similar or different from services 104 and 106) and a separate instance 102A of the platform. User 114 can access the sovereign cloud 502 using a client device 506 having a client computing system 108. User 512 can access the sovereign cloud 504 using a client device 508 having a client computing system 510. These are just examples. Cloud computing provides computing, software, data access and storage services that do not require the end user to know the physical location or configuration of the system providing the service. In various embodiments, cloud computing uses appropriate protocols to provide services over a wide area network such as the Internet. For example, a cloud computing provider provides applications over a wide area network and can access them through a web browser or any other computing component. The software or components of the architecture 100 and the corresponding data can be stored on a server at a remote location. Computing resources in a cloud computing environment can be consolidated at a remote data center location, or they can also be distributed. Cloud computing infrastructure can provide services through a shared data center, even if it appears as a single access point for users. Therefore, the components and functions described in this article can be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, it can be provided from a conventional server, or it can be installed directly on a client device, or provided in other ways.

[0123] This description is intended to include both public and private cloud computing.Cloud computing (both public and private) provides for substantially seamless pooling of resources and reduces the need to manage and configure underlying hardware infrastructure.

[0124] Public clouds are managed by the provider and typically support multiple consumers using the same infrastructure. As such, in contrast to private clouds, public clouds free end users from having to manage hardware. Private clouds can be managed by the organization itself, and the infrastructure is typically not shared with other organizations. The organization still maintains the hardware to some extent, such as installation and repair.

[0125] It should also be noted that the architecture 100 or a portion thereof can be disposed on a variety of different devices. Some of those devices include: a server, a desktop computer, a laptop computer, a tablet computer, or other mobile devices such as a palmtop computer, a cell phone, a smart phone, a multimedia player, a personal digital assistant, etc.

[0126] Fig.15 is an example of a computing environment in which, for example, architecture 100 or a portion thereof can be deployed. Fig.15 , an exemplary system for implementing some embodiments includes a general purpose computing device in the form of a computer 810. Components of the computer 810 may include, but are not limited to, a processing unit 820 (which can include a processor or server from the previous figures), a system memory 830, and a system bus 821 that couples various system components including the system memory to the processing unit 820. The system bus 821 can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus (also known as a mezzanine bus). About Figure 1 The described memory and program can be deployed in Fig.15 in the corresponding part of .

[0127] Computer 810 generally includes various computer-readable media. Computer-readable media can be any available media that can be accessed by computer 810, and include volatile and non-volatile media, removable and non-removable media. As an example and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media is different from and does not include modulated data signals or carrier waves. It includes hardware storage media, which includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data). Computer storage media include, but are not limited to: RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by computer 810. Communication media generally embody computer-readable instructions, data structures, program modules or other data in a transmission mechanism, and include any information delivery medium. The term "modulated data signal" means a square signal that sets or changes one or more of its characteristics in a way that encodes the information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

[0128] The system memory 830 includes computer storage media in the form of volatile and / or nonvolatile memory, such as read-only memory (ROM) 831 and random access memory (RAM) 832. The basic input / output system 833 (BIOS) contains the basic routines that help transfer information between elements within the computer 810, such as during startup, and is typically stored in ROM 831. RAM 832 typically contains data and / or program modules that are immediately accessible to and / or currently being operated on by the processing unit 820. By way of example and not limitation, Fig.15 Operating system 834 , application programs 835 , other program modules 836 , and program data 837 are shown.

[0129] The computer 810 may also include other removable / non-removable volatile / non-volatile computer storage media. For example only, Fig.15A hard disk drive 841 is shown that reads or writes from a non-removable, non-volatile magnetic medium, and an optical disk drive 855 that reads or writes from a removable, non-volatile optical disk 856, such as a CD ROM or other optical media. Other removable / non-removable, volatile / non-volatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tapes, solid-state RAM, solid-state ROM, etc. The hard disk drive 841 is typically connected to the system bus 821 via a non-removable memory interface such as interface 840, and the optical disk drive 855 is typically connected to the system bus 821 via a removable memory interface such as interface 850.

[0130] Alternatively or additionally, the functions described herein may be performed at least in part by one or more hardware logic components. For example, but not limited to, illustrative types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), etc.

[0131] Discussed above and in Fig.15 The drives and their associated computer storage media shown in FIG. 8 provide storage of computer readable instructions, data structures, program modules and other data for the computer 810. Fig.15 844, application programs 845, other program modules 846, and program data 847. Note that these components may be the same as or different from operating system 834, application programs 835, other program modules 836, and program data 837. Operating system 844, application programs 845, other program modules 846, and program data 847 are given different numbers here to illustrate that they are at least different copies.

[0132] A user can enter commands and information into the computer 810 through input devices such as a keyboard 862, a microphone 863, and a pointing device 861 (e.g., a mouse, trackball, or touch pad). Other input devices (not shown) may include a joystick, a game controller, a satellite dish, a scanner, and the like. These and other input devices are typically connected to the processing unit 820 through a user input interface 860 coupled to the system bus, but may also be connected through other interfaces and bus structures, such as a parallel port, a game port, or a universal serial bus (USB). A visual display 891 or other type of display device is also connected to the system bus 821 via an interface, such as a video interface 890. In addition to the monitor, the computer may also include other peripheral output devices, such as speakers 897 and a printer 896, which may be connected through an output peripheral interface 895.

[0133] Computer 810 may be a general purpose computing device configured to perform as discussed above. It may also be a secure workstation that provides an administrator with a secure hardened workstation environment with clear application controls and various protection features (certificates, devices, utilization, etc.). Such a workstation may also employ a network access control list to further enhance security.

[0134] The computer 810 operates in a network environment using logical connections to one or more remote computers, such as a remote computer 880. The remote computer 880 may be a personal computer, handheld device, server, router, network PC, peer device or other public network node, and typically includes many or all of the elements described above with respect to the computer 810. Fig.10 The logical connections depicted in the diagram include a local area network (LAN) 871 and a wide area network (WAN) 873, but may also include other networks. Such a networking environment is common in offices, enterprise-wide computer networks, intranets, and the Internet.

[0135] When used in a LAN networking environment, the computer 810 is connected to the LAN 871 through a network interface or adapter 870. When used in a WAN networking environment, the computer 810 typically includes a modem 872 or other means for establishing communications over the WAN 873 (e.g., the Internet). The modem 872 may be internal or external and may be connected to the system bus 821 via the user input interface 860 or other appropriate mechanism. In a networking environment, program modules or portions thereof described relative to the computer 810 may be stored in a remote memory storage device. By way of example and not limitation, Fig.10 Remote application programs 885 are shown as residing on remote computer 880. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0136] It should also be noted that the different examples described herein can be combined in different ways. That is, parts of one or more examples can be combined with parts of one or more other examples. All of these are contemplated herein.

[0137] Example 1 is a computing system comprising:

[0138] a request processing system that receives a create workspace request input that identifies characteristics of an incident to be investigated and indicates a user request to create a workspace within a sovereign cloud computing system, the request processing system generating a first control message based on the create workspace request input;

[0139] a control message processing system that receives the first control message and generates a workspace within the sovereign cloud computing system based on the first control message;

[0140] a machine-learned investigation bundle suggestion model that identifies an investigation bundle based on the characteristics of the incident, the investigation bundle comprising investigation resources;

[0141] a survey bundle output generator that generates an indication of the identified survey bundle; and

[0142] A system is preconfigured that imports the identified survey packages into the workspace.

[0143] Example 2 is the computing system of any or all of the previous examples, wherein the preconfigured system comprises:

[0144] An automatic provisioning logic unit is configured to automatically load the identified survey package into the workspace.

[0145] Example 3 is the computing system of any or all of the previous examples, wherein the preconfigured system comprises:

[0146] A request processing system interaction logic unit is configured to provide the indication of the identified survey package to the request processing system for presentation as a suggested survey package for user approval.

[0147] Example 4 is the computing system of any or all of the previous examples, further comprising:

[0148] a log configured to store task data indicating investigation resources used in other workspaces to investigate other incidents having corresponding incident characteristics; and

[0149] A machine learning investigation package generation model is configured to access the mission data in the log, generate an investigation package based on the mission data, and store the investigation package and the corresponding accident characteristics in an investigation package storage.

[0150] Example 5 is a computing system of any or all of the previous examples, wherein the machine-learned investigation bundle suggestion model is configured to access the investigation bundle in the investigation bundle storage to identify the identified investigation bundle based on the characteristics of the accident and the accident characteristics corresponding to the investigation bundle stored in the investigation bundle storage.

[0151] Example 6 is the computing system of any or all of the previous examples, further comprising:

[0152] A machine learning system is configured to access the task data in the log and automatically generate and update the survey package suggestion model and the survey package generation model based on the task data in the log.

[0153] Example 7 is the computing system of any or all of the previous examples, wherein the machine learning system comprises:

[0154] a learning trigger criteria detection logic unit configured to detect a learning criterion indicating that the machine learning system is to train at least one of the survey package generation model or the survey package suggestion model; and

[0155] A survey package model training logic unit is configured to train the at least one model based on the task data in the log.

[0156] Example 8 is the computing system of any or all of the previous examples, wherein the request processing system receives an execute task request input identifying a task to be executed within the workspace and generates a second control message indicating the identified task, and the computing system further comprises:

[0157] A task execution logic unit is configured to execute the task in the workspace based on the second control message, the request processing system is isolated from the workspace, and the control message processing system is isolated from user interaction.

[0158] Example 9 is the computing system of any or all of the previous examples, further comprising:

[0159] A machine-learned branching logic model configured to identify a suggested next task to be performed in the workspace based on the characteristics of the incident and the task executed based on the second control message.

[0160] Example 10 is the computing system of any or all of the previous examples, wherein the log stores task data indicating investigation tasks performed in other workspaces to investigate other incidents having corresponding incident characteristics, and the computing system further comprises:

[0161] A branch logic model training logic unit is configured to train the branch logic model based on the task data stored in the log.

[0162] Example 11 is a computing system comprising:

[0163] a request processing system receiving a create workspace request input identifying characteristics of an incident to be investigated and indicating a user request to create a workspace within a sovereign cloud computing system, the request processing system receiving a perform task request input identifying a task to be performed within the workspace, the request processing system generating a first control message based on the create workspace request input and generating a second control message indicating the identified task;

[0164] a control message processing system that receives the first control message and the second control message and generates a workspace within the sovereign cloud computing system based on the first control message and executes the identified task within the workspace based on the second control message; and

[0165] A machine-learned branching logic model configured to identify a suggested next task to be performed in the workspace based on the characteristics of the incident and the task executed based on the second control message.

[0166] Example 12 is the computing system of any or all of the previous examples, further comprising:

[0167] A log is configured to store task data indicating tasks performed in other workspaces to investigate other incidents having the corresponding incident characteristics.

[0168] Example 13 is the computing system of any or all of the previous examples, further comprising:

[0169] A branch logic model training logic unit is configured to train the branch logic model based on the task data stored in the log.

[0170] Example 14 is the computing system of any or all of the previous examples, further comprising:

[0171] A request processing system interaction logic unit is configured to provide an indication of the suggested next task to the request processing system for presentation as a suggested next task for user approval.

[0172] Example 15 is the computing system of any or all of the previous examples, further comprising:

[0173] a machine-learned investigation bundle suggestion model that identifies an investigation bundle based on the characteristics of the incident, the investigation bundle comprising investigation resources;

[0174] a survey bundle output generator that generates an indication of the identified survey bundle; and

[0175] A system is preconfigured that imports the identified survey packages into the workspace.

[0176] Example 16 is the computing system of any or all of the previous examples, wherein the log is configured to store task data indicating investigative resources used in other workspaces to investigate other incidents having corresponding incident characteristics, and the computing system further comprises:

[0177] A machine learning investigation package generation model is configured to: access the task data in the log, generate an investigation package based on the task data, and store the investigation package and the corresponding accident characteristics in an investigation package storage.

[0178] Example 17 is the computing system of any or all of the previous examples, further comprising:

[0179] A machine learning system is configured to access the task data in the log and automatically generate and update the survey package suggestion model and the survey package generation model based on the task data in the log.

[0180] Example 18 is a computer-implemented method comprising:

[0181] receiving, at a request processing system in a sovereign cloud computing system, a create workspace request input identifying characteristics of an incident to be investigated and indicating a user request to create a workspace within the sovereign cloud computing system;

[0182] receiving, at the request processing system, a perform task request input identifying a task to be performed within the workspace;

[0183] generating a first control message based on the create workspace request input, and generating a second control message indicating the identified task;

[0184] generating a workspace in the sovereign cloud computing system based on the first control message using a control message processing system in the sovereign cloud computing system;

[0185] executing the identified task within the workspace based on the second control message;

[0186] using a machine-learned branching logic model configured to identify a suggested next task to be performed in the workspace based on the characteristics of the incident and the task to be run based on the second control message;

[0187] generating a suggested next task output indicative of the suggested next task; and

[0188] The suggested next task output is provided to the request processing system for presentation to the user.

[0189] Example 19 is the computer-implemented method of any or all of the previous examples, further comprising:

[0190] storing task data indicating tasks performed in other workspaces to investigate other incidents having corresponding incident characteristics; and

[0191] The branching logic model is trained based on the task data stored in the log.

[0192] Example 20 is the computer-implemented method of any or all of the previous examples, further comprising:

[0193] identifying an investigation package including investigation resources based on the characteristics of the incident; and

[0194] The identified survey packages are automatically imported into the workspace.

[0195] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A computing system comprising: a request processing system that receives a create workspace request input that identifies characteristics of an incident to be investigated and indicates a user request to create a workspace within a sovereign cloud computing system, the request processing system generating a first control message based on the create workspace request input; a control message processing system that receives the first control message and generates a workspace within the sovereign cloud computing system based on the first control message; a machine-learned investigation bundle suggestion model that identifies an investigation bundle based on the characteristics of the incident, the investigation bundle comprising investigation resources; a survey bundle output generator that generates an indication of the identified survey bundle; and A system is preconfigured that imports the identified survey packages into the workspace.

2. The computing system of claim 1, wherein: The pre-configured system includes: An automatic provisioning logic unit is configured to automatically load the identified survey package into the workspace.

3. The computing system of claim 1, wherein: The pre-configured system includes: A request processing system interaction logic unit is configured to provide the indication of the identified survey package to the request processing system for presentation as a suggested survey package for user approval.

4. The computing system of claim 1, and further comprising: a log configured to store task data indicating investigation resources used in other workspaces to investigate other incidents having corresponding incident characteristics; as well as A machine learning investigation package generation model is configured to: access the task data in the log, generate an investigation package based on the task data, and store the investigation package and the corresponding accident characteristics in an investigation package storage.

5. The computing system of claim 4, wherein: The machine-learned investigation bundle suggestion model is configured to access the investigation bundles in the investigation bundle storage to identify an identified investigation bundle based on the characteristics of the accident and the accident characteristics corresponding to the investigation bundles stored in the investigation bundle storage.

6. The computing system of claim 4, and further comprising: A machine learning system is configured to access the task data in the log and automatically generate and update the survey package suggestion model and the survey package generation model based on the task data in the log.

7. The computing system of claim 6, wherein: The machine learning system comprises: a learning trigger criteria detection logic unit configured to detect a learning criterion indicating that the machine learning system is to train at least one of the survey package generation model or the survey package suggestion model; and A survey package model training logic unit is configured to train the at least one model based on the task data in the log.

8. The computing system of claim 4, wherein: The request processing system receives an execute task request input identifying a task to be executed within the workspace and generates a second control message indicative of the identified task, and the computing system further comprises: A task execution logic unit is configured to execute the task in the workspace based on the second control message, the request processing system is isolated from the workspace, and the control message processing system is isolated from user interaction.

9. The computing system of claim 8, and further comprising: A machine-learned branching logic model configured to identify a suggested next task to be performed in the workspace based on the characteristics of the incident and the task executed based on the second control message.

10. The computing system of claim 9, wherein: The log stores task data indicating investigation tasks performed in other workspaces to investigate other accidents having corresponding accident characteristics, and the computing system further includes: A branch logic model training logic unit is configured to train the branch logic model based on the task data stored in the log.

11. A computing system comprising: a request processing system receiving a create workspace request input identifying characteristics of an incident to be investigated and indicating a user request to create a workspace within a sovereign cloud computing system, the request processing system receiving a perform task request input identifying a task to be performed within the workspace, the request processing system generating a first control message based on the create workspace request input and generating a second control message indicating the identified task; a control message processing system that receives the first control message and the second control message and generates a workspace within the sovereign cloud computing system based on the first control message and executes the identified task within the workspace based on the second control message; as well as A machine-learned branching logic model configured to identify a suggested next task to be performed in the workspace based on the characteristics of the incident and the task executed based on the second control message.

12. The computing system of claim 11, and further comprising: A log is configured to store task data indicating tasks performed in other workspaces to investigate other incidents having the corresponding incident characteristics.

13. The computing system of claim 12, and further comprising: A branch logic model training logic unit is configured to train the branch logic model based on the task data stored in the log.

14. The computing system of claim 11, and further comprising: A request processing system interaction logic unit is configured to provide an indication of the suggested next task to the request processing system for presentation as a suggested next task for user approval.

15. A computer-implemented method comprising: receiving, at a request processing system in a sovereign cloud computing system, a create workspace request input identifying characteristics of an incident to be investigated and indicating a user request to create a workspace within the sovereign cloud computing system; receiving, at the request processing system, a perform task request input identifying a task to be performed within the workspace; generating a first control message based on the create workspace request input, and generating a second control message indicating the identified task; generating a workspace in the sovereign cloud computing system based on the first control message using a control message processing system in the sovereign cloud computing system; executing the identified task within the workspace based on the second control message; using a machine-learned branching logic model configured to identify a suggested next task to be performed in the workspace based on the characteristics of the incident and the task to be run based on the second control message; generating a suggested next task output indicative of the suggested next task; as well as The suggested next task output is provided to the request processing system for presentation to the user.

Images