Non-invasive Whitelisting via Reputation Scoring
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional whitelisting security architectures often compromise convenience for heightened security, leading to user inconvenience and information overload, as they require manual administration and lack efficient decision-making mechanisms for executable objects.
Innovation Solution
A security architecture that employs a security engine to assign reputation scores to executable objects and actions, using machine learning and a combination of whitelists, blacklists, and graylists, to make intelligent decisions about execution, notification, and user verification, thereby balancing security and convenience.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional whitelisting security architecture is used to enhance security, then security reliability is improved, but user convenience deteriorates due to manual administration requirements and information overload
Solution Approach 1:
The security engine automatically evaluates executable objects and assigns reputation scores without requiring manual user intervention. The system self-manages the whitelisting process by autonomously analyzing objects, consulting threat intelligence databases, and making security decisions, thereby eliminating the need for users to manually administer security lists while maintaining high security reliability
Solution Approach 2:
The patent replaces manual mechanical administration of whitelists with an automated intelligent system. The security engine uses machine learning algorithms and threat intelligence databases to automatically evaluate and classify executable objects, substituting the mechanical process of manual list management with an automated decision-making system that improves both security reliability and user convenience
2Reliability
If manual administration of whitelists is implemented, then security control is improved, but time consumption increases due to continuous user intervention requirements
Solution Approach 1:
The security engine performs preliminary evaluation of executable objects before they are executed, automatically assigning reputation scores and making security decisions in advance. This preliminary action eliminates the need for continuous user intervention during operation, as the system has already prepared security assessments, thereby maintaining strong security control while minimizing time consumption
Solution Approach 2:
The system autonomously manages the entire whitelisting process without requiring user time investment. The security engine self-evaluates objects, consults threat intelligence databases, and automatically updates security lists, freeing users from time-consuming manual administration tasks while maintaining effective security control
3Device complexity
If traditional blacklist/whitelist approaches are used, then security simplicity is maintained, but false positives increase leading to unnecessary user interventions
Solution Approach 1:
The patent introduces reputation scores as an additional parameter for evaluating executable objects, moving beyond simple binary whitelist/blacklist classification. The security engine considers multiple factors including object characteristics, behavior patterns, and threat intelligence data to assign nuanced reputation scores, thereby reducing false positives while maintaining system simplicity through automated decision-making
Solution Approach 2:
The security engine acts as an intermediary between simple whitelist/blacklist approaches and complex security analysis. It provides automated reputation evaluation that bridges the gap between simplistic binary classification and sophisticated multi-factor analysis, reducing false positives by intelligently mediating security decisions based on comprehensive object assessment
Data Source
AI summary
In an example, there is disclosed a security architecture for enhanced, non-invasive whitelisting of executable objects. When an executable object tries to perform an action, a security engine seamlessly intercepts the action and determines whether the action is whitelisted, blacklisted, or graylisted, assigning the action a corresponding security score. Whitelisted actions may be allowed, blacklisted actions may be disallowed, and graylisted actions may require additional verification from a user. Because the score is assigned to the combination of the executable object and the action, false positives may be avoided, such as those that may occur when an executable object is prefetched but has not yet tried to perform any useful work.