Microvisor Malware Detection Appliance Architecture
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing malware detection systems are limited in detecting anomalous behavior that exploits vulnerabilities in virtual machines, as malicious code can evade detection by avoiding malicious behavior within virtual machines or exploiting vulnerabilities in the virtualization system itself.
Innovation Solution
A threat-aware microvisor is deployed in a malware detection appliance architecture, executing in kernel space to control access to kernel resources and employing a two-phase analysis approach of static and dynamic analysis, with a behavioral analysis logic engine and classifier to detect and classify suspicious behaviors indicative of malware.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If data stream analysis is used to detect malware behavior within virtual machines, then detection of malicious behavior can be achieved, but malware can evade detection by avoiding malicious behavior or exploiting virtual machine vulnerabilities
Solution Approach 1:
The system segments the virtualization architecture into multiple layers: a trusted microvisor layer at the hardware level, a hypervisor layer, and guest operating system layers. This segmentation allows the microvisor to independently monitor and detect anomalies without being affected by malware operating at higher layers, thereby improving detection reliability while preventing evasion.
Solution Approach 2:
The microvisor acts as an intermediary layer between the hardware and the hypervisor/guest OS. It mediates access to hardware resources and monitors system behavior, enabling detection of malware that attempts to exploit virtual machine vulnerabilities without compromising the integrity of the detection system itself.
2Difficulty of detecting and measuring
If virtual machines are used to isolate and analyze malicious code, then containment and analysis can be performed, but the virtualization system itself becomes vulnerable to exploitation
Solution Approach 1:
The system adds a new dimensional layer of security by placing the microvisor at the hardware level, below the traditional hypervisor layer. This dimensional change creates a trusted execution environment that can safely analyze malware in virtual machines while being immune to exploitation from above, thus maintaining both analysis capability and system security.
Solution Approach 2:
The microvisor is configured in advance as a trusted computing base with predefined security policies and monitoring capabilities. This preliminary configuration ensures that the virtualization system is secured before malware analysis begins, preventing exploitation while enabling thorough analysis of malicious code behavior.
3Measurement precision
If comprehensive monitoring of operating system data streams is performed, then anomalous behavior can be detected, but the analysis is limited to behavior within virtual machines and cannot detect exploits targeting the virtualization system
Solution Approach 1:
The microvisor is designed with multi-functionality, serving both as a security monitoring mechanism for detecting malware behavior and as a protective layer against exploits targeting the virtualization system. Its position at the hardware level enables it to detect both types of threats, thereby expanding detection coverage while maintaining precise behavioral analysis.
Data Source
AI summary
A threat-aware microvisor may be deployed in a malware detection appliance architecture and execute on a malware detection system (MDS) appliance to provide exploit and malware detection within a network environment. The microvisor may underlie an operating system kernel of the MDS appliance and execute in kernel space of the architecture to control access to kernel resources of the appliance for any operating system process. A type 0 virtual machine monitor may be disposed over the microvisor and execute in user space of the architecture as a pass-through module configured to expose the kernel resources of the appliance to the operating system kernel. One or more hypervisors, e.g., type 1 VMM, may be further disposed over the microvisor and execute in user space of the architecture under control of the microvisor to support execution of one or more guest operating systems inside one or more full virtual machines.