Cisco Technology, Inc.

Appdynamics, Inc.

Harness Inc.

Traceable Inc.

Sanjay Nagaraj

Michael Margulis

Ryan Ericson

Pankaj Kumar

David Roth

Vinay Srinivasaiah

Amod Gupta

Alexander Fedotyev

Jisheng Wang

Ido Carmel

Min-Yi Shen

Inon Shkedy

Swapnil Kura

Ting Liang

Satish Kumar Mittal

Dan Koepke

Roshan Piyush

Apun Hiran

Juan Pablo Tosso Alvarez

A method for detecting volumetric attacks using multi-phase analysis of API calls is disclosed. The method includes collecting API calls data having API calls to and from protected actors. The method also includes identifying a triggering suspicious time window during which a first set of actors indicate suspicious volume spikes. Further, the method includes performing an API-sequence-based user behavior clustering to identify a subset of the API attack sequence and a second set of actors. Thereafter, the method includes correlating the activities of the second set of actors over a large period of time to identify the complete API attack sequence to extract an attack signature of the complete API attack sequence for detecting potential attacks.

Method and system for detecting volumetric attacks using multi-phase analysis of application programming interface calls

Live and legitimate user traffic is used with in depth knowledge of the business logic for an API specification to perform security testing on a set of APIs. The present system intercepts and analyzes application program interface (API) traffic, identifies user session data, and identifies traffic suitable to duplicate. The identified traffic is duplicated and modified by addition of malicious code. The modified code is then sent to its intended API destination, where it is processed as normal. The resulting response and other traffic as well as the API system and optionally other systems, such as datastore systems, are analyzed to determine if the malicious code resulted in a valid attack. Results from the modified code attack attempts are reported to a user.

Application security testing based on live traffic

In one aspect, a machine learning system for performing predictive analytics on database wait events is disclosed. The machine learning system includes a processor; a memory; and one or more modules stored in the memory and executable by a processor to perform operations including: receive database wait event data indicative wait events associated with database calls running on a monitored database; receive database performance data indicative of performance of the monitored database; correlate the received database wait event data with the received database performance data to obtain a correlation result; predict a performance issue with the monitored database based on the correlation result; and provide a user interface to display the predicted performance issue.

Predictive analytics on database wait events

A system implements code trampolining techniques by generating custom trampoline functions, compiling the functions, and executing the compiled functions directly from a library when the corresponding native function is called. The native functions may be binary functions, such as functions in C++ code, or other languages. A code generator may read a set of functions to be implemented and generate code, such as binary code, for the destination function. In doing so, the code generator may generate code which matches the source function signature. The generated code may then be compiled into a shared library which is loaded by the process being instrumented. When the library is initiated upon subsequent calls for the native function, the trampoline mechanisms will be set up between the source function and the generated destination function to operate seamlessly with matching signatures.

Dynamic configuration of native functions to intercept

The present technology may monitor an asynchronous transaction based on a custom exit point. Once an asynchronous method to be monitored has been identified, the transition framework may be tracked while executing the asynchronous method call. Within a .NET framework, monitoring may include tracking a task object, continuation method calls at the completion of a method, and tracking the continuation method as it executes other code. The asynchronous method may then be correlated within a business transaction using the returned task object data.

Asynchronous custom exit points

The present technology correlates tasks between multiple threads of an application. A payload consisting of a task object may be identified as part of a method. Identification of the task object may be performed using instrumentation or some other method. Once the task object is identified, the payload may be instrumented to track the task object or payload and correlate the task object with other executing threads. Instrumenting the payload may include determining the constructor of the task object and instrumenting the task object constructors to determine what creates the task object. Once the source of a task object or payload is determined, the current thread having the task object as a parameter and another thread which creates the task may be tied together as part of a business transaction.

Automatic task tracking

A system for naming a process being monitored that handles a requesting a framework such as a .NET framework. The process may be implemented by a .NET application framework within an IIS web server. The naming system allows for user readable names which are more than just numbers or indexes. The naming system is configured from a single location rather than from multiple locations, making it much easier to configure, change and update.

Naming of nodes in NET framework

An agent installed on application server having a WSGI web application dynamically instruments that web application. The agent may modify the application via instrumentation such that it can be monitored without specific details of the WSGI application framework. A configuration file may be modified upon detecting a call to the application configuration file through a gateway interface that receives the call. After modifying the configuration file, the modified configuration file is executed in response to the call. Additionally, for subsequent calls to that particular web application, the WSGI gateway will call the modified WSGI configuration file for execution instead of the original WSGI file.

Dynamic instrumentation of WSGI applications

A dynamic monitoring process begins with configuring a start and end method to be monitored. The dynamic monitoring process may intercept both the start and end methods as and when the loader is initiated or at runtime to dynamically attach and detach the instrumentation. A loader may then be modified to call a library method upon detection of the start method. The library method may serve as a notification to the start of the method and causes a reflector to retrieve information from the incoming request. The incoming information may include data from which a business transaction name may be determined. The business transaction name is then associated with the monitoring of the particular request. When an exit call is detected, a call may be made to the library for a method which invokes a decorator. The decorator may insert business transaction name and other data into the outgoing call.

Monitoring and correlating a binary process in a distributed business transaction

A system monitors asynchronous transactions over a different number of threads by capturing data and tracking transitions in the particular framework. Once an asynchronous method is called, the transition framework may be tracked while executing a asynchronous method call. Within a .NET framework, monitoring may include tracking a task object return, continuation method calls at the completion of a method, and tracking the continuation method as it executes other code. The asynchronous method may then be correlated within a business transaction using the returned task object data.

Growing community of inventors

Dublin, CA, United States of America

Sanjay Nagaraj