Sandboxing is the process of attempting to discover unknown or adverse effects of programs or other activities on a computer. Sandboxing is quite popular as a method of securing or ameliorating computer systems from an adversary who attempts to compromise the machines.
There are many types of sandboxes which range from sandboxes which run on a machine or within a program (e.g. Java) to dedicated machines such as the FireEye MVX engine, which uses a Virtual Machine (VM) which requires relatively high end dedicated machines. Refer to FIG. 6, which shows an architecture diagram of the FireEye MVX system 600, including multi-vector virtual execution (MVX) engines 602a-j. FIG. 6 is an illustration in “FireEye Delivers Next-Generation Threat Protection Platform”, Feb. 25, 2013, available at http://investors.fireeye.com/releasedetail.cfm?ReleaseID=790792 (last accessed Dec. 30, 2016).
However, all current methods of sandboxing suffer from limited resources. Since simulating program activity is resource intensive (requiring memory, disk space, CPU cycles, etc.) sandboxes are generally limited in what they can achieve. For example, if a malicious program waits for a sufficiently long time period before activating it can run undetected. Of course, if the program never exits the sandbox (such as is the case for Java) this is not an issue. However, attempts to completely sandbox the operating system activities have been heretofore unsuccessful and therefore, a sandboxed process will generally be let outside the sandbox where it can do harm.
Some sandboxes are in the cloud, for example Palo-Alto's Wildfire. For these types of sandboxes, the resources are more flexible inasmuch as they can respond to demand. However, these resources are taken from a generic pool of resources and do not use the resources currently available in the enterprise. In addition, such a localized, distributed sandbox also ensures that the test environment is most matching to the target environment in which the attack occurs. FIG. 7 shows the Palo-Alto Wildfire architecture 700 including the threat intelligence cloud 702. FIG. 7 is an illustration in “At a Glance Wildfire”, Palo Alto Networks, 2016, available at https://www.paloaltonetworks.com/content/dam/pan/en_US/assets/pdf/faqs/at-a-glance-wildfire.pdf (last accessed Dec. 30, 2016).
In parallel to the burgeoning field of sandboxing, there has been work done on utilizing idle resources in computer networks. For example, the SETI@home project allows PC owners to run signal processing algorithms on their home PC. FIG. 8 shows the distribution of data 800 in the SETI@home system. There are many other projects that use idle computers to run desired programs. FIG. 8 is an illustration in David P. Anderson et al., “SETI@home: An Experiment in Public-Resource Computing”, Space Sciences Laboratory, U.C. Berkeley, available at https://setiathome.berkeley.edu/sah_papers/cacm.php (last accessed Dec. 30, 2016).
Another way of doing computation is to use so-called cloud computing. Cloud computing allows the use of remote resources to do desired computation. One particular type of cloud computing is often called private cloud computing in which the organization owns a set of computers that are available to users in that organization.
Generally, the private cloud is comprised of dedicated computers. However, it is technically possible to use idle or underutilized computers to run desired programs. Of course, it is desirable to be able to rapidly change the programs that are running on a machine. One way of doing this is to utilize a VM to run on the private cloud.
While all current sandboxing require dedicated machines, these machines actually run a virtual machine for each of the processes. Thus, it is possible to use the private cloud (or other computers) to distribute the sandbox. Thus it is possible to run the sandbox utilizing the idle cycles on the distributed machine which are not required to be dedicated to use as a sandbox machine. The use of non-dedicated machines reduces cost and increases available resources.
One advantage of using production machines to run sandboxing is that the environment will more closely relate to the actual environment which is being protected and thus most malware evasion techniques will not work. See, e.g., Dilshan Keragala, “Detecting Malware and Sandbox Evasion Techniques”, SANS Institute InfoSec Reading Room, available at https://www.sans.org/reading-room/whitepapers/forensics/detecting-malware-sandbox-evasion-techniques-36667 (last accessed Dec. 30, 2016).
Common evasion techniques which can be prevented by using production machines include but are not limited to: mouse interaction, detection of humans, real environment, online digital signature, etc.
However, there are several drawbacks with this method. The first drawback is that when using idle cycles a VM may need to be terminated before the desired level of measurements for the process is completely achieved. This can be ameliorated, e.g., by using multiple machines in parallel or by starting a new VM on a new computer after the first process is terminated.
Starting a new process requires additional computer cycles which is generally not an issue. However, using conventional sandboxing starting a new process can cause unacceptable delays to running the program on the actual desired computer.
Sideboxing is the process by which the sandboxing is done in parallel to the actual run on the computer. Thus sideboxing is particularly suited for this method.
USPTO Backgrounds
USPTO Backgrounds