System and method for providing a virtualized secure data containment service with a networked environment

• US 8,756,696 B1
• Filed: 10/29/2011
• Issued: 06/17/2014
• Est. Priority Date: 10/30/2010
• Status: Active Grant

• Current Assignee: SRA International, Inc. (General Dynamics Corporation)
• Original Assignee: SRA International, Inc. (General Dynamics Corporation)
• Inventors: Miller, Brian
• Primary Examiner(s): Arani, Taghi
• Assistant Examiner(s): LANE, GREGORY A
• Application Number:
  US13/284,874
• Time in Patent Office: 962 Days
• Field of Search: 726/24, 726/25, 709/247
• US Class Current: 726/25
• CPC Class Codes: G06F 11/301 where the computing system is a virtual computing platform, e.g. logically partitioned systems virtual machines G06F9/45533; logical partitioning of resources G06F9/5077
• CPC Class Codes: G06F 2009/45587 Isolation or security of virtual machine instances
• CPC Class Codes: G06F 21/53 by executing in a restricted environment, e.g. sandbox or secure virtual machine
• CPC Class Codes: G06F 21/566 Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
• CPC Class Codes: G06F 9/45558 Hypervisor-specific management and integration aspects
• CPC Class Codes: H04L 63/04 for providing a confidential data exchange among entities communicating through data packet networks
• CPC Class Codes: H04L 63/14 for detecting or protecting against malicious traffic
• CPC Class Codes: H04L 63/1416 Event detection, e.g. attack signature detection
• CPC Class Codes: H04L 63/1491 using deception as countermeasure, e.g. honeypots, honeynets, decoys or entrapment

Abstract

The present invention relates to a technique for debugging and testing potential virus, trojans, and other malware programs. The present invention, named Cyberlock™ provides a technique to analyze malware programs on a network in a secure manner, which allows multiple users to access or monitor the analysis. In the present invention, a virtual machine (VM) may be run on a network, emulating the operation of a Windows, LINUX, or Apple operating system (or other O/S), and the malware or suspected malware may be executed on that virtual machine. The virtual machine is isolated on the network, but accessible to one or more users, in such a manner than the malware or suspected malware may be analyzed.

Claims

1. A method of testing, in a computer network, potential malware, the method comprising the steps of:

establishing at least one Virtual Machine on a first computer coupled to the computer network and operating suspected malware on the at least one Virtual Machine;

coupling, at least one second computer to the computer network and the first computer such that image display data from the at least one Virtual Machine on the first computer is transmitted from the first computer to the at least one second computer for image display on the second computer;

observing in the image display data from the at least one Virtual Machine on the first computer, from at least one second computer coupled to the computer network and the first computer, source code variables identifying attempts by the suspected malware operating on the at least one Virtual Machine to change Memory and Bridge configuration settings of the at least one Virtual Machine on the first computer to observe how the suspected malware hops memory to attempt access to a hard drive of a host operating system; and

locking down flexible memory and partition space of RAM of the at least one Virtual Machine;

to ensure that no shared memory or hard drive is accessed by the suspected malware running on the at least one Virtual Machine;

wherein the step of locking down flexible memory and partition space of RAM of the at least one Virtual Machine comprises the steps of;

modifying how the host operating system handles memory by lowering a sys control config file to ‘

zero’

by setting the variable “

vm.swappiness=zero”

to instruct the host operating system not to swap processes out of RAM to hard disk; and

setting a variable Vm.overcommit_memory=1 to disallow the host operating system from overcommitting memory that it currently has installed, as a backup to the process swap to keep the host operating system from swapping from RAM to disk and therefore potentially writing viruses to disk.

4. The method of claim 1, wherein transmitting image display data from the at least one Virtual Machine to the at least one second computer provides secure peering of the at least one Virtual Machine desktop back to an end user one second computer using a Virtual Network Computing (VNC) protocol within the at least one Virtual Machine.

5. The method of claim 4, further comprising the steps of:

changing a remote viewing VNC enableport password protocol in the at least one Virtual Machine to circumvent a default requirement to use a proprietary interface in the at least one Virtual Machine which requires endpoint installation, configurations of groups, usernames and passwords for all users of the system;

enabling a VNC applet SSL to communicate to a proxy server; and

creating an SSL tunnel from a user desktop on the at least one second computer to a proxy operating on the first computer with the at least one Virtual Machine.

6. The method of claim 5, wherein the SSL tunnel comprises a two-way SSL encrypted tunnel to prevent hijacking of the session and stealing passwords by the suspected malware operating on the at least one Virtual Machine, and to prevent the suspected malware operating on the at least one Virtual Machine from sitting on the server and viewing the session.

7. The method of claim 6, further comprising the step of enabling a true or false configuration within the at least one Virtual Machine to allow a VNC server to be turned on, which is set to true on a per virtual machine setting.

8. The method of claim 7, further comprising the step of:

directing data coming through a webpage to go through the proxy server, to prevent the suspected malware operating on the at least one Virtual Machine from accessing the Internet.

9. The method of claim 5, further comprising the step of:

configuring the proxy server to assign unique ports unique to each of the at least one Virtual Machines, assigned to each unique user, such that each of the at least one Virtual Machines is assigned an individual port number, allowing administrators to assign one user to one at least one of the at least one Virtual Machines.

10. The method of claim 9, further comprising the steps of:

generating a secure session authentication to ensure unique Virtual Machine sessions are assigned to a unique port for a unique user;

generating a unique password at the proxy server, to allow user access to VNC port, where each password is autogenerated to allow access, and then destroyed; and

transmitting the password via the SSL tunnel to prevent access by potential malware.

11. The method of claim 5, wherein to allow a user to observe operation of the suspected malware operating on the at least one Virtual Machine while containing the suspected malware from propagating from the at least one Virtual Machine, the method further comprises the steps of:

disabling a standard Virtual Machine display;

disabling installation of a Multilingual User Interface (MUI) file; and

turning off a console port for the Virtual Machine,

wherein the proxy server calls a specific command in the Virtual Machine to allocate a Virtual Machine session to a specific user and port.

12. The method of claim 1, further comprising the step of:

isolating a host operating system operating on the first computer, by preventing the host operating system'"'"'s network interface on the first computer from being accessed by memory from the at least one Virtual Machine operating on the first computer to allow a user to observe operation of the suspected malware operating on the at least one Virtual Machine while containing the suspected malware from propagating from the at least one Virtual Machine.

13. The method of claim 12, wherein to allow a user to observe operation of the suspected malware operating on the at least one Virtual Machine while containing the suspected malware from propagating from the at least one Virtual Machine, the step of isolating the host operating system further comprises the steps of:

removing a bridge network under a Linux file system; and

instructing the at least one Virtual Machine not use the bridge using a cobbler puppet load.

14. The method of claim 1, further comprising the step of:

on the first computer, altering a default regular scheduler of the host operating system of the first computer to use the deadline regular scheduler for all requests to provide improved performance of the at least one Virtual Machine under heavy work loads.

15. The method of claim 14, further comprising the step of:

changing, in a boot menu of the host operating system on the first computer, variable ‘

elevator’

=deadline to change the default regular scheduler of the host operating system.

16. The method of claim 1, further comprising the steps of:

creating a data bridge between the at least one Virtual Machine and one or more operating systems by generating a custom optical disc image to allow the at least one Virtual Machine to interact with one or more of Windows XP, Vista, 2000, NT, Windows 7, Linux, Solaris, Mac OS;

wherein the data bridge addresses Unicode characters coming across not normally handled by the ISO command MK ISO FS and allows any file to be converted to an optical disc image and the optical disc image transmitted across the data bridge.

30. The method of claim 1, wherein the at least one Virtual Machine application programming interface (API) uses a Perl script operating between the at least one Virtual Machine and the proxy, such that if the at least one Virtual Machine displays a dialog box, the Perl Script handles communications with the at least one Virtual Machine on behalf of a user.

2. A method of testing, in a computer network, potential malware, the method comprising the steps of:

establishing at least one Virtual Machine on a first computer coupled to the computer network and operating suspected malware on the at least one Virtual Machine;

coupling, at least one second computer to the computer network and the first computer such that image display data from the at least one Virtual Machine on the first computer is transmitted from the first computer to the at least one second computer for image display on the second computer;

observing in the image display data from the at least one Virtual Machine on the first computer, from at least one second computer coupled to the computer network and the first computer, source code variables identifying attempts by the suspected malware operating on the at least one Virtual Machine to change Memory and Bridge configuration settings of the at least one Virtual Machine on the first computer to observe how the suspected malware hops memory to attempt access to a hard drive of a host operating system;

enabling an accurate aspect ratio and resolution of the image display on the at least one second computer, of the image display data from the at least one Virtual Machine using a Virtual Network Computing (VNC) protocol within the at least one Virtual Machine; and

using a proxy to handle a secure socket layer (SSL) connection between the at least one Virtual Machine and the least one second computer to run Perl scripts that call the at least one Virtual Machine.

3. The method of claim 2, wherein the at least one Virtual Machine application programming interface (API) uses a Perl script operating between the at least one Virtual Machine and the proxy, such that if the at least one Virtual Machine displays a dialog box, the Perl Script handles communications with the at least one Virtual Machine on behalf of a user.

17. The method of claim 2, wherein transmitting image display data from the at least one Virtual Machine to the at least one second computer provides secure peering of the at least one Virtual Machine desktop back to an end user one second computer using a Virtual Network Computing (VNC) protocol within the at least one Virtual Machine.

18. The method of claim 17, further comprising the steps of:

changing a remote viewing VNC enableport password protocol in the at least one Virtual Machine to circumvent a default requirement to use a proprietary interface in the at least one Virtual Machine which requires endpoint installation, configurations of groups, usernames and passwords for all users of the system;

enabling a VNC applet SSL to communicate to a proxy server; and

creating an SSL tunnel from a user desktop on the at least one second computer to a proxy operating on the first computer with the at least one Virtual Machine.

19. The method of claim 18, wherein the SSL tunnel comprises a two-way SSL encrypted tunnel to prevent hijacking of the session and stealing passwords by the suspected malware operating on the at least one Virtual Machine, and to prevent the suspected malware operating on the at least one Virtual Machine from sitting on the server and viewing the session.

20. The method of claim 19, further comprising the step of enabling a true or false configuration within the at least one Virtual Machine to allow a VNC server to be turned on, which is set to true on a per virtual machine setting.

21. The method of claim 20, further comprising the step of:

directing data coming through a webpage to go through the proxy server, to prevent the suspected malware operating on the at least one Virtual Machine from accessing the Internet.

22. The method of claim 18, further comprising the step of:

configuring the proxy server to assign unique ports unique to each of the at least one Virtual Machines, assigned to each unique user, such that each of the at least one Virtual Machines is assigned an individual port number, allowing administrators to assign one user to one at least one of the at least one Virtual Machines.

23. The method of claim 22, further comprising the steps of:

generating a secure session authentication to ensure unique Virtual Machine sessions are assigned to a unique port for a unique user;

generating a unique password at the proxy server, to allow user access to VNC port, where each password is autogenerated to allow access, and then destroyed; and

transmitting the password via the SSL tunnel to prevent access by potential malware.

24. The method of claim 18, wherein to allow a user to observe operation of the suspected malware operating on the at least one Virtual Machine while containing the suspected malware from propagating from the at least one Virtual Machine, the method further comprises the steps of:

disabling a standard Virtual Machine display;

disabling installation of a Multilingual User Interface (MUI) file; and

turning off a console port for the Virtual Machine,

wherein the proxy server calls a specific command in the Virtual Machine to allocate a Virtual Machine session to a specific user and port.

25. The method of claim 2, further comprising the step of:

isolating a host operating system operating on the first computer, by preventing the host operating system'"'"'s network interface on the first computer from being accessed by memory from the at least one Virtual Machine operating on the first computer to allow a user to observe operation of the suspected malware operating on the at least one Virtual Machine while containing the suspected malware from propagating from the at least one Virtual Machine.

26. The method of claim 25, wherein to allow a user to observe operation of the suspected malware operating on the at least one Virtual Machine while containing the suspected malware from propagating from the at least one Virtual Machine, the step of isolating the host operating system further comprises the steps of:

removing a bridge network under a Linux file system; and

instructing the at least one Virtual Machine not use the bridge using a cobbler puppet load.

27. The method of claim 2, further comprising the step of:

on the first computer, altering a default regular scheduler of the host operating system of the first computer to use the deadline regular scheduler for all requests to provide improved performance of the at least one Virtual Machine under heavy work loads.

28. The method of claim 27, further comprising the step of:

changing, in a boot menu of the host operating system on the first computer, variable ‘

elevator’

=deadline to change the default regular scheduler of the host operating system.

29. The method of claim 2, further comprising the steps of:

creating a data bridge between the at least one Virtual Machine and one or more operating systems by generating a custom optical disc image to allow the at least one Virtual Machine to interact with one or more of Windows XP, Vista, 2000, NT, Windows 7, Linux, Solaris, Mac OS;

wherein the data bridge addresses Unicode characters coming across not normally handled by the ISO command MK ISO FS and allows any file to be converted to an optical disc image and the optical disc image transmitted across the data bridge.