Microsoft Technology Licensing, LLC

Vidhi Agarwal

Gueorgui Chkodrov

Russell Biles

Mohamed Rouatbi

Dawn Antonette Burns

Jose Wilson Morris

Lucius B Fleuchaus

Marek Jedrzejewicz

Jeffrey Scott Shaw

Jonathan Peary Morris

Andre Oneal Alfred

Sangeetha Madderla

Georgi Chkodrov

Anjani Kumar Lavania

Justin Minaker

Shi Min Sharon Ko

Event-triggered forensics capture technologies balance security incident data availability against data processing and storage costs. A forensic correlation engine receives basic status data of a monitored computing system. A forensic computing system detects a trigger event in the basic status data, and starts capturing extended status data per a corresponding capture specification. Captured data is submitted to a forensic analysis tool. Different trigger events may cause different data captures. A query specifying which data to capture from a live stream or from virtual machines may operate as a capture trigger start event. Extended status data capture activity may be stopped by a change in the basic status data being received, by a timeout, or by forensic analysis that finds no vulnerability or threat based on captured data. Data transfers and storage may be restricted to comply with privacy regulations or policies.

Event-triggered forensics capture

The automated creation of a dataflow graph of a standing query. Once the standing query dataflow graph is created, events may be flowed into the dataflow graph to execute the standing query. In execution, a store query is accessed. The store query is structured in accordance with a store query language. A syntax graph (such as an abstract syntax tree) of the store query may then be generated. Then, using the syntax graph and a set of rules of the store query language, the dataflow graph is automatically generated. This significant speeds up and makes more easy and efficient the conversion of a store query into a standing query.

Standing query creation using store query

The storage of events of multiple types in a queriable table. The queriable table has at least one common column that corresponds to a field that is common across events regardless of event type. The queriable table also has at least one field-varying column that corresponds to a type-dependent field that depends on event type. The queriable table is populated using multiple events. For instance, the event could be at least some log events that are received from multiple computing systems. The population occurs by assigning each event to a row of the queriable table. The common column is populated with values taken the same common field across event types. On the other hand, the field-varying column is populated with values of different fields from those events depending on the event type.

Event table management using type-dependent portions

Growing community of inventors

Bellevue, WA, United States of America

Vidhi Agarwal