Anomalous Flow Detection in Application Programs

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current security systems, such as SIEM solutions and static analysis tools, are limited in detecting unknown threats and identifying the root cause of anomalous behavior in application programs, as they rely on manual curation of threat feeds and are unable to effectively distinguish between normal and anomalous control and data flow paths.

Innovation Solution

The approach involves instrumenting application programs to collect and record execution data, training a system to differentiate between normal and anomalous paths using machine learning, and generating a provenance graph with confidence values to identify sensitive and anomalous flows, which can be updated periodically for improved accuracy.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If rule-based mechanisms with manual curation of threat feeds are used, then detection of known threats is improved, but detection of unknown threats and identification of root cause deteriorates

Engineering Contradiction:
Improvedetection accuracyVSAvoiddetection capability
Core Design Contradiction:
Measurement precisionVSAdaptability or versatility

Solution Approach 1:

The system automatically instruments application programs to collect execution data and uses machine learning to train classifiers that distinguish normal from anomalous control and data flow paths. This self-service approach eliminates the need for manual curation of threat feeds while enabling detection of both known and unknown threats through automated pattern recognition and anomaly detection.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent replaces manual mechanical processes (security professionals reading threat advisories and extracting IoCs) with automated computational processes. Machine learning classifiers and anomaly detection algorithms automatically analyze execution data, substitute human expertise with intelligent systems that can process and learn from vast amounts of execution data without manual intervention.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

2Loss of time

If static analysis tools are used to analyze control flow call-graph, then potential security vulnerabilities are identified prior to deployment, but ability to determine actual root cause of runtime anomalies deteriorates

Engineering Contradiction:
Improveremediation timeVSAvoidroot cause identification accuracy
Core Design Contradiction:
Loss of timeVSMeasurement precision

Solution Approach 1:

The system instruments application programs during the development phase to collect execution data, enabling both pre-deployment analysis and runtime monitoring. This preliminary action allows the system to establish baseline behavior patterns before deployment while maintaining the capability to detect actual runtime anomalies and identify their root causes through comparative analysis.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system continuously collects execution data during runtime and uses machine learning to compare actual execution paths against learned normal behavior patterns. This feedback mechanism enables real-time detection of deviations from normal operation and provides actionable intelligence about the actual root cause of security incidents, not just potential vulnerabilities.

Inventive Principle:
Principle #23Feedback

3Measurement precision

If machine learning training with execution data is implemented, then detection of anomalous paths is improved, but system complexity and implementation difficulty worsens

Engineering Contradiction:
Improveanomaly detection accuracyVSAvoidsystem complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The system uses a unified machine learning framework that handles multiple functions: collecting execution data, training classifiers, detecting anomalies, and identifying root causes. This multi-functional approach consolidates what could be separate complex systems into a single integrated platform, reducing overall system complexity while maintaining high detection accuracy through versatile anomaly detection capabilities.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Measurement precision

If comprehensive execution data collection is performed, then accuracy in distinguishing normal and anomalous paths is improved, but data processing time and resource consumption worsens

Engineering Contradiction:
Improvepath differentiation accuracyVSAvoidtraining time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The system collects comprehensive execution data including control flow, data flow, and timing information to ensure accurate differentiation between normal and anomalous paths. By gathering more data than minimally required (excessive action), the system achieves superior detection accuracy while the machine learning algorithms efficiently process this rich dataset through optimized training procedures.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS11748480B2Policy-based detection of anomalous control and data flow paths in an application program
Publication Date: 2023.09.05 ARKOSE LABS HOLDINGS INC
  • US11748480B2 patent drawing
  • US11748480B2 patent drawing
  • US11748480B2 patent drawing

AI summary

Anomalous control and data flow paths in a program are determined by machine learning the program's normal control flow paths and data flow paths. A subset of those paths also may be determined to involve sensitive data and/or computation. Learning involves collecting events as the program executes, and associating those event with metadata related to the flows. This information is used to train the system about normal paths versus anomalous paths, and sensitive paths versus non-sensitive paths. Training leads to development of a baseline “provenance” graph, which is evaluated to determine “sensitive” control or data flows in the “normal” operation. This process is enhanced by analyzing log data collected during runtime execution of the program against a policy to assign confidence values to the control and data flows. Using these confidence values, anomalous edges and/or paths with respect to the policy are identified to generate a “program execution” provenance graph associated with the policy.