Network Whitelist Mode Transition for Malware Attack Mitigation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current network security measures face challenges in quickly and efficiently transitioning from normal mode to a more restrictive whitelist mode during a malware attack, often resulting in significant downtime and potential loss of productivity and revenue.
Innovation Solution
A system and method that allows for a seamless transition from a normal mode to a whitelist mode by evaluating processes on a host against a whitelist, terminating unverified processes, and quarantining critical processes, while enabling memory protection to prevent further damage, thereby minimizing downtime.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional network security measures are used during a malware attack, then security protection is maintained, but significant network downtime occurs causing loss of productivity and revenue
Solution Approach 1:
The system performs preliminary actions by pre-evaluating and whitelisting legitimate processes before a malware attack occurs. When an attack is detected, the whitelist mode is already prepared with a curated list of approved processes, enabling immediate transition without needing to evaluate everything from scratch during the crisis, thus minimizing downtime while maintaining security protection.
Solution Approach 2:
The system dynamically switches between normal mode and whitelist mode based on the detected malware attack conditions. The mode transition is flexible and adaptive, allowing the network to pivot from standard security operations to restricted whitelist-based operations only when necessary, thereby maintaining productivity during normal operations while ensuring security during attacks.
2Object-affected harmful factors
If the network transitions to whitelist mode during a malware attack, then malware execution is blocked, but critical processes may be terminated if not verified
Solution Approach 1:
The system performs preliminary verification of processes and creates a whitelist of approved processes before the actual threat materializes. This advance preparation ensures that when whitelist mode is activated, only verified legitimate processes are allowed to execute, preventing malware while preserving critical business processes that have been pre-validated.
Solution Approach 2:
The system continuously monitors process behavior and provides feedback to the whitelist verification mechanism. By observing how processes behave during normal operation and comparing them against established criteria, the system can confidently verify legitimate processes before allowing them to execute in whitelist mode, thus blocking malware while maintaining process continuity.
3Object-affected harmful factors
If processes are terminated during whitelist mode transition, then unverified processes are blocked, but business operations may be interrupted
Solution Approach 1:
The system performs preliminary verification and classification of all processes before a whitelist mode transition is needed. By pre-identifying which processes are legitimate and critical, the system can prepare a comprehensive whitelist that allows business operations to continue uninterrupted even when unverified processes are blocked during an actual attack.
Solution Approach 2:
The system applies different quality standards to different processes based on their verification status and criticality. Verified critical processes maintain full operational privileges, while unverified processes are blocked. This localized differentiation ensures that business operations continue smoothly for authorized processes while preventing harmful unverified processes, thus maintaining productivity.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method is provided in one example embodiment that includes receiving a signal to enable a whitelist mode on a host in a network, terminating a process executing on the host if the process is not verified, and blocking execution of software objects on the host if the software objects are not represented on the whitelist. In more particular embodiments, the method also includes identifying the process on a process list that enumerates one or more processes executing on the host. Yet further embodiments include quarantining the host if a second process on the process list is a critical process and if the second process is not verified. More specific embodiments include identifying and restarting another process on the process list if process memory was modified.