Anomaly Detection in Delegate Applications via Baseline Monitoring

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing delegation protocols, such as OAuth 2.0, face challenges in detecting security breaches in delegate applications, as anomalies in communication attributes can indicate unauthorized access, making it difficult to distinguish between legitimate and malicious activity without exposing user credentials.

Innovation Solution

Implementing an anomaly detection system that builds baselines for attribute values from delegate applications, monitoring IP addresses, ISPs, and other origin-related attributes to identify unusual patterns or changes, which can indicate a breach, and triggering security mitigation actions like revoking access tokens.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If delegate applications are monitored for security breaches by examining communication attributes, then detection capability is improved, but system complexity increases

Engineering Contradiction:
Improvebreach detection capabilityVSAvoidmonitoring system complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The system performs preliminary actions by establishing baselines for delegate application communication attributes before monitoring begins. These baselines capture normal communication patterns including IP addresses, user agents, and request characteristics. When monitoring starts, actual communications are compared against these pre-established baselines to detect anomalies, eliminating the need for complex real-time analysis of normal behavior patterns.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary anomaly detection system that sits between the delegate applications and the authorization server. This intermediary monitors communications by examining attributes like IP addresses, user agents, and request patterns without interfering with the actual authentication flow. The intermediary compares observed attributes against established baselines and flags anomalies, simplifying the monitoring task while maintaining effective breach detection.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If access token validation is performed to detect breaches, then security is improved, but false positives increase because tokens remain unchanged during breaches

Engineering Contradiction:
Improvesecurity validationVSAvoidbreach detection accuracy
Core Design Contradiction:
ReliabilityVSMeasurement precision

Solution Approach 1:

The patent extracts and monitors communication attributes surrounding the access token usage rather than focusing on the token itself. Attributes such as IP address, user agent, request timing, and communication patterns are extracted and analyzed for anomalies. This approach allows the system to detect breaches without relying on token validation, avoiding false positives while maintaining security.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system monitors for parameter changes in communication attributes that occur during breaches. When a breach happens, the breaching party typically uses different IP addresses, user agents, or request patterns compared to the legitimate application. By tracking changes in these parameters over time and comparing them against established baselines, the system detects breaches accurately without being confounded by unchanged access tokens.

Inventive Principle:
Principle #35Parameter changes

3Measurement precision

If multiple attribute values are monitored and compared against baselines, then detection accuracy is improved, but processing time increases

Engineering Contradiction:
Improveanomaly detection accuracyVSAvoidmessage processing time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent applies partial monitoring by focusing on the most indicative communication attributes rather than analyzing every possible attribute. Key attributes such as IP address, user agent, and request timing are monitored intensively, while less significant attributes receive minimal or no attention. This selective approach maintains high detection accuracy by concentrating resources on the most breach-indicative parameters while reducing overall processing time.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system performs preliminary actions by pre-processing and storing baseline attribute values during a learning phase before production monitoring begins. During actual monitoring, the system compares incoming attribute values against these pre-computed baselines using efficient lookup operations rather than performing complex real-time analysis. This preliminary preparation significantly reduces processing time during breach detection while maintaining accurate multi-attribute comparison.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS12010125B2Anomaly detection in an application with delegate authorization
Publication Date: 2024.06.11 MICROSOFT TECHNOLOGY LICENSING LLC
  • US12010125B2 patent drawing
  • US12010125B2 patent drawing
  • US12010125B2 patent drawing

AI summary

Aspects of the technology described herein detect potential security breaches in delegate applications by monitoring communications received from a delegate application. Anomalies in the delegate application communications can indicate that the delegate application has been breached and is now being controlled by an entity other than an authorized entity. An anomaly may be a new or unusual attribute value within the delegate-application's communication. Initially, the anomaly detection system may a build a baseline of attribute values for a single delegate application within a single tenant and separate baseline for the tenant. If the attribute value is anomalous to both the application-specific baseline and the tenant-specific baseline then the message may be designated as anomalous. Mitigation can then be undertaken.