Third-Party App Security Evaluation via Fake Data Signatures

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Users face challenges in assessing the security risks associated with third-party applications accessing their private data, as they may not fully understand the potential threats such as data leakage and unauthorized transactions, making it difficult to gauge the risks involved in granting access.

Innovation Solution

A system and method that generate fake data to evaluate third-party applications by monitoring their behavior, detecting misuse or security threats, and providing notifications to users, while also determining data access patterns and assigning risk scores based on observed behaviors.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If users grant permission to third-party applications to access their private data, then the applications can provide useful services and functionality, but users face security risks including data leakage, unauthorized transactions, and identity theft

Engineering Contradiction:
Improvedata access functionalityVSAvoidsecurity risks
Core Design Contradiction:
Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The system performs preliminary actions by generating fake account data before actual data access occurs, using this fake data to evaluate the third-party application's behavior patterns and security risks in advance, allowing users to make informed decisions about granting access

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system introduces an intermediary evaluation mechanism that sits between the user's private data and third-party applications. This intermediary uses fake data to assess application behavior and provides security evaluations, acting as a mediator that enables safe data access while filtering out malicious applications

Inventive Principle:
Principle #24Intermediary (Mediator)

2Ease of operation

If users provide login credentials to third-party applications for authentication, then the applications can retrieve account data from protected databases, but user credentials may be appropriated by rogue parties for fraudulent transactions and identity theft

Engineering Contradiction:
Improvedata retrieval capabilityVSAvoidcredential misuse
Core Design Contradiction:
Ease of operationVSObject-generated harmful factors

Solution Approach 1:

The system creates a copy of the authentication process using fake account data instead of real credentials. Third-party applications authenticate against fake data in a controlled environment, allowing their data access patterns to be evaluated without exposing real user credentials to potential misuse

Inventive Principle:
Principle #26Copying

3Adaptability or versatility

If an access control system allows third-party applications to access protected data resources, then users can benefit from application services, but it becomes difficult for users to appreciate potential security risks associated with granting access

Engineering Contradiction:
Improveapplication service accessVSAvoidsecurity risk awareness
Core Design Contradiction:
Adaptability or versatilityVSLoss of information

Solution Approach 1:

The system implements feedback by providing users with security risk evaluations and behavior pattern information about third-party applications based on fake data testing. This feedback loop enables users to understand potential security risks before granting access, making informed decisions about which applications to trust

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS12101349B2Systems and methods for detecting changes in data access pattern of third-party applications
Publication Date: 2024.09.24 THE TORONTO DOMINION BANK
  • US12101349B2 patent drawing
  • US12101349B2 patent drawing
  • US12101349B2 patent drawing

AI summary

A method for evaluating security of third-party application is disclosed. The method includes: in an automated test environment: launching a test instance of a first application; and obtaining a data access signature of the first application based on identifying at least one application state of the first application and account data retrieved by the first application from a user account at a protected data resource in the at least one application state; receiving, from a client device associated with the user account, an indication of access permissions for the first application to access the user account for retrieving account data; detecting a change in the data access signature of the first application; and in response to detecting the change in the data access signature of the first application, notifying the user of the detected change.