Predictive Whitelisting Security Module for Malware Detection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current malware detection methods, such as blacklisting and whitelisting, are inadequate in protecting computer systems from targeted attacks, as they require prior knowledge of malware and are inflexible, especially in large networks where administrative efforts are significant.
Innovation Solution
A security module that implements predictive whitelisting by checking files for similarity to trusted reference files using a two-stage process involving identity and similarity checks, allowing execution if the file is deemed similar, and includes a machine learning algorithm for continuous learning and flexible decision-making.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If blacklisting is used to detect malware, then known malware can be blocked, but custom-made malware like Stuxnet cannot be detected because it is not yet in the blacklist
Solution Approach 1:
The system performs preliminary actions by creating a whitelist of trusted files and their characteristics before malware attacks occur. This proactive approach establishes a baseline of legitimate software behavior, enabling the system to detect deviations that indicate malware, including custom-made threats like Stuxnet, without requiring prior knowledge of specific malware signatures.
Solution Approach 2:
Instead of blacklisting known malware (negative identification), the patent inverts the approach by whitelisting known good files and their characteristics (positive identification). This inversion allows the system to identify malware by detecting files that do not match legitimate patterns, thereby improving detection of unknown and custom-made malware while maintaining reliability for known threats.
2Reliability
If whitelisting is used to control applications, then only authorized software can run, but switching to different legitimate software during updates is not possible without updating the whitelist, leading to considerable administrative overhead
Solution Approach 1:
The system monitors changes in file parameters and characteristics over time, establishing baselines for legitimate software behavior. When software updates occur, the system detects parameter changes within acceptable ranges rather than requiring complete whitelist updates. This parameter-based approach maintains security while automatically adapting to legitimate software updates, significantly reducing administrative overhead in large networks.
Solution Approach 2:
The whitelist system is made dynamic by continuously monitoring file characteristics and adapting to legitimate changes. Instead of a static whitelist requiring manual updates, the system dynamically adjusts to software updates by detecting and learning new legitimate file patterns, enabling automatic adaptation to changing software environments while maintaining security constraints.
3Reliability
If a traditional antivirus scanner is used, then malware detection requires prior occurrence and detection, but this provides insufficient protection against targeted attacks
Solution Approach 1:
The system performs preliminary analysis of file characteristics and establishes baselines of legitimate software behavior before malware can be introduced or execute. By pre-defining what legitimate files should look like and how they should behave, the system can immediately detect and block malware upon introduction, eliminating the time delay inherent in traditional antivirus scanners that wait for malware to occur and be detected.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A security module (SM) and associated procedure for a computer system (CS). The security module (SM) includes an input interface (IN1) for capturing at least one feature of a file. A check logic (PL) is configured to verify, based on at least one feature, whether the file is similar to one or more reference files, where the one or more reference files are considered trusted and the file is different from the one or more reference files. The check logic (PL) is configured to authorize execution of the file on a computer system only if the check concludes that there is a similarity to the one or more reference files.