Whitelisting System with Rule-Based Override Mechanism
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current whitelisting methods in computer security often result in unnecessary blocking of trusted programs, requiring constant updates and leading to false positives, while existing blacklisting approaches leave a window of opportunity for new malicious software infections until signatures are added to the blacklist.
Innovation Solution
A system that uses whitelists with override capabilities, allowing execution of programs based on rules such as directory paths, certifications, and user behavior, enabling trusted programs to run without prior inclusion in the whitelist, while revoking permissions if malware is detected in those paths.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a whitelist approach is used to block unknown programs, then security against new malware is improved, but false positives increase and trusted programs are blocked
Solution Approach 1:
The patent introduces an intermediary evaluation mechanism between the whitelist and program execution. Instead of directly blocking unknown programs, the system evaluates them against multiple criteria (reputation, behavior, source) and uses a scoring system to determine whether to allow execution. This intermediary layer reduces false positives while maintaining security.
Solution Approach 2:
The system changes the parameter of program evaluation from binary (whitelist/blacklist) to a multi-dimensional scoring system. Programs are evaluated on multiple parameters including reputation score, behavior analysis, and source reliability, allowing nuanced decisions about execution rather than simple allow/deny based on presence in a list.
2Ease of operation
If a blacklist approach is used to allow known programs, then program execution is improved, but security against new malware deteriorates due to detection delay
Solution Approach 1:
The system performs preliminary evaluation of programs before they are added to the whitelist. Programs undergo reputation checks, behavior analysis, and source verification in advance. This preliminary action ensures that when new legitimate programs need to be executed, they have already been evaluated and can be quickly added to the whitelist without security delays.
Solution Approach 2:
The system implements continuous feedback loops where program behavior is monitored after execution. This feedback is used to update the evaluation models and adjust the behavior of similar programs. The feedback mechanism allows the system to learn from actual program behavior and improve its security decisions over time.
3Ease of operation
If whitelists are constantly updated to include new programs, then program execution is improved, but system complexity and maintenance burden increase
Solution Approach 1:
The system implements self-service mechanisms where programs can automatically register themselves with the whitelist through digital signatures and certificate verification. Legitimate programs present their credentials, and the system automatically evaluates and adds them to the whitelist without requiring manual administrator intervention for each program.
Solution Approach 2:
The system uses universal evaluation criteria and a unified scoring mechanism that applies to all programs regardless of type or source. This multi-functional approach allows the same evaluation framework to handle executables, scripts, plugins, and other program types, simplifying whitelist management across diverse software.
Data Source
AI summary
A system and method of protecting a computer includes providing a whitelist of known applications and a set of rules for determining if a program is benign. Upon an attempt to initiate a program, determining if the program is in the whitelist and if the program is in the whitelist, allowing the program to run. If the program is not in the whitelist, determining if the program is benign based upon the set of rules or strategy and presenting the rule/strategy to the user. If the user accepts the rule/strategy, running the program and updating the whitelist for allowing future attempts to run the program and any other program that conforms to the one rule. If the program is not determined to be benign, the program is not allowed to execution unless a specific override is made.