VDI (Virtual Desktop Infrastructure) is now standard in many organizations. Standalone physical endpoints are replaced with virtual machines which are indistinguishable to the user from physical PCs. The twin advantages of this approach from a business perspective are cost reduction and the simplification of the systems administration.<\/p>\n
It\u2019s also easier to create a clean workstation from scratch with VDI, and to provide employees with machine access from any mobile device. Enterprises actively use all this facilities. Let\u2019s consider how to build in effective VDI security.<\/p>\n
RAM control: what you need to know for effective security. #virtualsecurity<\/p>Tweet<\/a><\/blockquote>\n
The reasons why business has embraced VDI are clear, but employees can be resistant to change. Accustomed to familiar working practices, they need to be able to work with VDI just the same way as with locally installed operating systems. VDI must be user-transparent, regardless of the internet browser used, USB use for data copying or the application running. IT departments provide this transparency with virtual USB-ports, familiar browsers, etc. And, incidentally, opportunities for familiar malware threats as well.<\/p>\n
Why VDI infrastructure needs securing<\/h3>\n
VDI is widespread, but virtualization does not do away with the need for security. Many of the same vulnerabilities exist as for physical machines \u2013 there have been numerous cases of virtual infrastructure infection, as well as instances of malicious code using hypervisor vulnerabilities to move from the \u201csandbox\u201d directly onto the host. So multi-layered defenses for your virtualized working space are a necessity. More information about the about the need for VDI security is available at Securelist<\/a>.<\/p>\n
Different approaches to protection and the importance of RAM monitoring<\/h3>\n
The nature of virtual environments means that best-practice security approaches differ from those applicable to traditional physical infrastructures. It\u2019s worth briefly explaining why. Firstly, virtual hosts are typically lower-powered than their physical counterparts, so resource-hungry products designed for physical endpoints can result in slower overall response times. There are also issues like \u201cactivity storms\u201d, where every virtual machine attempts the same action, e.g. updating its security database, simultaneously.<\/p>\n
VDI solutions developers are always seeking new ways to minimize the load on virtual hosts. Security functions are centralized where possible, and duplication is avoided. In the ideal scenario from a systems performance perspective, nothing at all is installed on the secured host itself. A separate standalone host is responsible for securing the entire virtual infrastructure, and there is no software agent on the secured host. this approach does, however, have limitations, particularly in terms of memory (RAM) access on the secured host.<\/p>\n
Even if RAM access is possible (as it can be under some conditions), information available to the security product is limited to memory content rather than processing activity. As described below, deep dynamic behavioral analysis, including that of processes in RAM, is essential to full VDI protection.<\/p>\n
The \u201cmiddle ground\u201d between installing a heavy agent onto each host and deploying agentless protection with all its security shortcoming is using a light agent with sufficient functionality to secure the virtual host. Why is access to the host\u2019s memory so vital? The appearance of bodiless malware that exists only in memory requires it. One famous sample of this tactic is the using of legitimate Mimikatz software to launch attacks. The infection introduced works purely in the memory, seeking out user passwords hashes.<\/p>\n
Why memory control is necessary, but not sufficient<\/h3>\n
The information security industry has known about such tactics for some years, and memory-scanning of physical and virtual machines is not new. Kaspersky Lab responded by developing a driver (also implemented in \u201clight agent\u201d applications for virtual host protection) that scans the operation system kernel, other drivers, user space processes, etc. in the memory, using a number of different rules.<\/p>\n
RAM scanning is very useful in fighting malicious code, but not enough per se.#security<\/p>Tweet<\/a><\/blockquote>\n
To return to simple memory scanning, and deep behavioral analysis on the virtual host. Memory scanning is certainly valuable, but its usefulness shouldn\u2019t be overestimated. Without events recording at file systems level, system registry and OS API calls, memory scanning will catch near to nothing or will produce a raft of false positives.<\/p>\n
Technical details<\/em><\/strong><\/p>\n
The main justification for memory scanning is that researching a packed malicious file is only possible in memory, the only place where it exists in unpacked form. But well-known packer programs are already \u201ccracked\u201d by modern anti-virus engines, thus\u00a0allowing packed malware to be analysed on the disk as well.<\/p>\n
Things are not that easy\u00a0with so-called \u201cprotectors\u201d programs, which employ\u00a0virtual machines, polymorphism and other techniques. Simple memory scanning wouldn\u2019t be extremely resultive\u00a0per se in the case of protected files. Without behavioral analysis it\u2019s hard to judge the code assignment. And it\u2019s not always clear when to start scanning, i.e. to determining where to end decryption. That\u2019s assuming it has an end, and doesn\u2019t use\u00a0a \u201cdecrypt on the fly\u201d scheme.<\/p>\n
The features of packers or protectors overlap with the memory handling mechanisms in modern operating systems. In Microsoft Windows, many operations take place asynchronously. When writing data to a file, it is initially buffered in memory, after which the OS writes the entire buffer to the disk. I.e. the precise moment of writing to disk is unclear, as is the processing context in which it will occurs.<\/p>\n
Another issue \u2013 all modern operating systems now use \u2018swap files\u2019 to enhance performance. From time to time, virtual memory content is unloaded to the swap file. In the event of a security incident, the virtual memory can be loaded into the swap file just before a physical memory scan. This is a problem for agentless solutions, as they only have access to physical memory. So using a swap file to virtual memory unload would interfere with memory scanning.<\/p>\n
Finally, where a programming language interpreter is responsible for scripting language malware, only part of the malware may exist in the memory at the same time: malicious code not existed fully in the memory, but can still execute.<\/p>\n
In terms of the specifics of virtual environment defenses, OS memory mechanisms also overlap with hypervisor features. Hypervisors can take control only during a very limited number of strictly specified times, which in turn limits the possibilities\u00a0to react\u00a0to malware detection in the memory.<\/p>\n
What full multi-layered defense looks like<\/h3>\n
To sum up, RAM scanning is very useful in fighting malicious code, but should operate in parallel with detailed dynamic information about processes on the host. This data is gathered from\u00a0memory and at the\u00a0file system level by specialized agents. An over-reliance on memory scanning can slow down analysis with no significant benefits in terms of protection.<\/p>\n
Recognizing the differing needs of our customers, Kaspersky Lab implements both approaches: offering and agentless solution as well as light agent-based product. This latter is capable of gathering all the data described\u00a0for\u00a0better protection of the virtual device. A detailed comparison of these two approaches is given here<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Virtual Desktop Infrastructure is now standard in many organizations. It is as much necessary to set up proper security for virtual systems as it is for the physical infrastructure.<\/p>\n","protected":false},"author":611,"featured_media":15315,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3052],"tags":[192,97,2465,1104],"class_list":{"0":"post-6096","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-smb","9":"tag-protection","10":"tag-security-2","11":"tag-vdi","12":"tag-virtualization"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/virtual-machines-memory\/6096\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/virtual-machines-memory\/15059\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/virtual-machines-memory\/6096\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/virtual-machines-memory\/6096\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/protection\/","name":"protection"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/6096","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/611"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=6096"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/6096\/revisions"}],"predecessor-version":[{"id":30140,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/6096\/revisions\/30140"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/15315"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=6096"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=6096"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=6096"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}