The Sandbox Environment inside SPHINX Toolkit
The SPHINX Data Inspection Component, also known as the Sandbox (SB), enables a solution for creating a safe and isolated environment for security testing and continuous component validation. Using existing technologies such as containerization and virtualization, this component aspires to provide the important infrastructure and deployment services which will be executed in an isolated and safe environment. These technologies include for example: the exploitation of Docker containers and Kernel Virtual Machine (KVM), among others.
Taking into consideration the design and software development lifecycle (SDLC) principles set within SPHINX the sandbox is being developed having in mind the research scope of the project to identify the applicability and the deployment options for the sandbox.
SPHINX’s scope is to further broaden the potential of dynamic malware analysis, using sandboxing to conduct security and auditing tests, including procedures such as file integrity monitoring, vulnerability detection and regulatory compliance among others.
As presented in the above diagram the goal is to deploy systems and services in a way security tests can be conducted and monitored. To enable this, virtualization technologies are used. These technologies are more secure than containerization technologies such as Docker containers. This is supported by the strong isolation capabilities that virtualization provides in comparison to containerization.
Virtualisation technologies are important to use for deploying a sandbox. Docker containers are also frequently used as a similar technology for virtualisation; however, we must declare the key-differences between them. By design, containerization technologies such as that of Docker are designed to execute micro-services and not operating systems. Not only this, but the services running on a Docker container are kernelless meaning that all of them share the same Operating System kernel. Virtualisation technologies provide numerous capabilities including the following:
- Server consolidation: To distribute the workloads from complex systems to multiple micro-services or VMs in order to consolidate the workload effort and to manage better in terms of administration and scale better in terms of performance and system resources.
- Application consolidation: Meet the application’s requirements in terms of hardware or software by virtualizing the hardware or by meeting any of the software requirements independently.
- Sandboxing: Provide secure and isolated environments for executing unknown sources and conducting security tests and malware analysis.
- Multiple execution environments: Create multiple execution environments, increasing the scope for including quality tests.
- Virtual hardware: Virtualize hardware resources such as SCSI drives and network interfaces, among others.
- Multiple simultaneously OS: Execute multiple operating systems that interact with each other.
- Debugging: Execute software in their full potential by letting the user interact with the software.
- Software migration and Appliances: Provides flexibility, compatibility and enhance portability providing the capabilities to package a whole digital environment into an appliance.
- Test scenarios: Helps produce test scenarios that are hard to reproduce in reality and therefore enhances the capabilities for conducting security test scenarios.
Popular virtualization and hypervisor technologies include Oracle Virtualbox, VMware, KVM, Hyper-V, Xen and OpenVZ among others. Micro Virtual Machines (Micro VMs) are also a modern approach and popular approaches include AWS (Amazon Web Services) Firecracker (using KVM or Ignite Firecracker) and RancherVM. Other popular approaches for maintaining virtualization technologies is Vagrant for building and managing virtual machine environments included in a single workflow. Each of the mentioned technologies include benefits and drawbacks and the analysis and outcomes are also provided in this deliverable.
Integration capabilities are important to include the sandbox component to easily interact and integrate with other software components. Not only the automated deployment, but the integration with the other SPHINX components is important. Towards this direction, we implement the APIs and the automated processes for initiating systems-on-a-test and to provide an easy way for the end user to interact with the sandbox and to collect insights for running an executable digital environment. The integration is processed using WEB APIs and Web interface for controlling the components inside the sandbox.
Networking, subnetworking and System Isolation
Nowadays, it is important to consider the network communication as one of the most important aspects in the modern digital infrastructures and systems. This means that every component currently includes network connection and continuously interacts with other network components. In the developed sandbox there are 3 different aspects of networking. The first one is the physical network interfaces/adapters, secondly are the virtualized network adapters created by the hypervisor and third are virtualized network interfaces created for the Docker containers. As a result, it is possible to combine or revise any of the above options to meet our own goals, accordingly.
The main goal for the SPHINX sandbox and of the data inspection component is to provide a shared sandbox environment for conducting security testing. Therefore, a digital environment would be provided for separating running programs and services which might include vulnerabilities. Finally, the sandbox provides a restricted and tightly controlled set of resources for guest programs or services to run.
More information about Sandbox Environment can be found at Deliverable 4.2 that is publicly available here.