NoGap: New security monitoring technology in the Cloud

• Cloud
• Software infrastructure
• Trust Security and Transactions

Share on Twitter : NoGap: New security monitoring technology in the Cloud (New window) Share on Linkedin : NoGap: New security monitoring technology in the Cloud (New window)

Summary

More and more people and businesses are storing their data and deploying their applications in Cloud computing infrastructures that offer the advantage of powerful, flexible and inexpensive computing resources. The massive adoption of these infrastructures that concentrate sometimes sensitive data and applications makes them a prime target for IT attacks, hence the importance of security monitoring in the Cloud. Yacine Hebbal and Sylvie Laniepce, Research Engineers in Orange’s Security Department, present NoGap, a new security monitoring technology that operates from the Cloud infrastructure. From the hypervisor [1], NoGap allows the reconstruction of the activity of Virtual Machines hosted in the Cloud from a binary view to a semantic view and exposes this view to applications, in particular security applications, to detect intrusions for example. This makes it possible to envisage two families of NoGap applications: new services based on the hypervisor, typically Security-as-a-Service, but also enriched functionalities such as network and resource allocation.

Complete article

More and more people and businesses are storing their data and deploying their applications in Cloud computing infrastructures that offer the advantage of powerful, flexible and inexpensive computing resources. The massive adoption of these infrastructures that concentrate sensitive data and applications makes them a prime target for IT attacks, hence the importance of security monitoring in the Cloud. This article introduces NoGap, a new security monitoring technology that operates from the Cloud infrastructure. NoGap was demonstrated at the Orange Research Exhibition.

Introduction:

In the architecture of a Cloud environment [1], as shown in Figure 1, there is at least one server with physical resources on which a virtualisation software layer (hypervisor) [2] runs, which allows these resources to be shared between different virtual environments belonging to different Cloud users. These environments known as Virtual Machines (VMs) run simultaneously on the same physical server and each of them runs an Operating System (OS) and multiple applications just like a physical machine. Our technology presented at the Research Exhibition focuses on the security monitoring of these VMs.

Figure 1: Cloud architecture

In a Cloud environment, three approaches to VM security monitoring are possible [3], two of which are traditional. These approaches are illustrated in Figure 2:

Figure 2: Security monitoring in the Cloud

First of all, the so-called “host-based” approach, representative of an antivirus. In this case, the monitoring entity has excellent visibility of the VM’s activities, it sees everything since it is inside the VM. So it analyses the VM’s activities and detects those that present a malicious character. On the other hand, the security monitoring entity is not isolated from the VM since it is inside it, therefore it is also exposed to attacks on the VM.

A second “network-based” approach, representative of a firewall at the network level, consists of examining the information exchanged via the network between VMs to judge their security. This time, the position is reversed. The security monitoring system is correctly isolated from the VMs because it is located outside of them, but its visibility of the VMs’ activities is reduced since their security must be judged solely on the basis of visibility of network packets.

Finally, there is a third way of security monitoring, thanks to virtualisation [2]. In this case, we examine the footprint left by the VMs’ activity at the hypervisor level to judge their security. This time both criteria are correct. The security supervision system is correctly isolated from the VMs since it is at the hypervisor level, therefore outside of them, and it has good visibility of their activities since the hypervisor is interposed between the VMs and the resources they consume.

On the other hand, the hypervisor sees everything but, simply put, “doesn’t understand anything” because it sees the VMs’ activities as 0s and 1s through a raw view as shown in Figure 3. However, to supervise VM security, the hypervisor needs a semantic view, i.e. a rich view that takes into account processes, files, system calls, etc. This gap between the raw view available to the hypervisor and the semantic view it needs to monitor the VMs’ security is called the “semantic gap” and this is the issue that needs to be solved for this hypervisor-based approach. Our NoGap solution solves this challenge and bridges the semantic gap [4].

Figure 3: Hypervisor view on VMs

NoGap is a security monitoring technique that operates from the hypervisor. It allows reconstruction from the binary view to a semantic view that can be used to supervise the security of hosted VMs. NoGap can therefore provide our infrastructures with a semantic security monitoring capability for hosted VMs.

NoGap:

The idea behind NoGap is that the VM’s activities that are interesting for security monitoring are performed by functions in the VM’s kernel code (kernel functions). For example, memory management (allocation and release), process management (start, stop, scheduling) and network management (opening and closing connections, sending and receiving packets) are all performed by VM kernel functions. Also, all data that concerns these aspects is created, used and deleted by kernel functions. Therefore, the kernel functions know the addresses and the structuring of this data. Ultimately, the set of kernel functions is self-sufficient, i.e. the kernel functions know everything that is needed for a VM’s kernel to run correctly. Therefore, the kernel function code is rich in terms of semantic information.

To bridge the semantic gap, NoGap works in two stages. During the first stage, NoGap identifies the addresses and names of the kernel functions in a VM’s memory and then, during the second stage, it instruments them (i.e. intercepts, calls or analyses them) to get semantic information about the VM’s activities and data.

The first issue with this approach is that the location of the kernel code in the VM’s memory is unknown to the hypervisor because, on the one hand, it is dependent on the type and version of the OS running in the VM and, on the other hand, it changes randomly when the VM is restarted for security reasons. The second issue is that there are no specific instructions that mark the start and end addresses of a function.

Therefore, the main challenge in the NoGap approach is to identify the addresses and names of kernel functions in the VM’s memory in a fast, automatic, OS-independent (generic) way, without prior knowledge of which OS is running in the VM’s memory (black box). All these properties are required to deploy this kind of technology in an Infrastructure-as-a-Service (IaaS) Cloud.

To solve these issues, NoGap locates the kernel code in the VM’s memory, fragment by fragment, from a single arbitrary kernel instruction automatically identified from the hypervisor in the VM’s memory [5]. Then NoGap derives the addresses and names of the kernel functions from the addresses and binary signatures of the fragments located in the kernel code (computed with the MD5 algorithm [6]).

NoGap satisfies the properties required for deployment in an IaaS Cloud and identifies the majority of kernel function names and addresses in a VM (about 75% of functions on average). There is no state-of-the-art equivalent and the NoGap approach has been patented [7].

Once the addresses and names of the kernel functions have been identified, NoGap allows the kernel functions to be instrumented, i.e. manipulating the function instructions, processor or memory of the VM to intercept, call or analyse these kernel functions from the hypervisor. The interception of the execution of the kernel functions makes it possible to follow the VM’s behaviour and to know its activity. For example, when the execution of the memory allocation function is intercepted, the hypervisor uses NoGap to infer that the VM is allocating memory. During this interception, the hypervisor can also deduce the amount of memory the VM is trying to allocate from the intercepted function’s call parameters. So NoGap allows the hypervisor to have a very detailed understanding of the supervised VM’s activities through the interception of the execution of kernel functions. NoGap also allows the hypervisor to call kernel functions to read or modify the state of a VM. For example, read or modify data from a VM or perform actions inside the VM such as stopping a process, closing a port, closing a network connection, etc. Finally, NoGap allows the hypervisor to analyse kernel functions to discover information useful for security monitoring, such as addresses of relevant data structures.

Example of a NoGap-based security application:

To illustrate how a security monitoring application takes advantage of the interception, calling and analysis of kernel functions from the hypervisor using NoGap, we have chosen to implement a hidden process detection application [8]. We emphasise that it is not so much this particular application that is important, but rather the way the security application works with the kernel function instrumentation possibilities offered by NoGap.

A hidden process is an active process that, due to a malicious modification of kernel data, becomes invisible in the list of running processes of the VM’s OS. So classic security and system administration tools that access this list will be fooled and will not see the malicious process running. To detect the existence of an active and hidden process in a VM, the approach implemented in this NoGap-based application example exploits the fact that an active process is inevitably periodically scheduled by the VM’s OS through a kernel function.

Thanks to NoGap, this security application can firstly intercept a kernel function from the hypervisor, responsible for process scheduling to detect active processes in the VM. For each process scheduling interception, the security application then checks whether the process being scheduled exists in the list of active processes declared by the OS. The address of this list of active processes and the positions of the different data fields of interest for this security application (e.g. PID, next process, previous process, etc.) are automatically identified from the hypervisor, thanks to NoGap, through the analysis mechanism of the kernel functions that access this data. If a process that is being scheduled is not found in the list of active processes, the security application judges that this process is a hidden process. In this case, it calls a VM kernel function from the hypervisor through NoGap to stop the execution of the hidden process whose information (e.g. PID) is available in the parameters of the kernel function intercepted during the first stage.

This example demonstrates that, through the identification then instrumentation of kernel functions through NoGap, the hypervisor becomes semantically aware of the VM’s activities that it sees at its level and is capable of detecting an intrusion and reacting to it.

Conclusion:

NoGap makes it possible to produce a semantic view of the VM’s activity from the hypervisor and to expose this view to applications, in particular security applications that exploit this view to detect intrusions, for example. It can therefore be said that NoGap, thanks to the identification and instrumentation of kernel functions, makes it possible to have a Cloud infrastructure that is semantically aware of the activity of hosted environments. This makes it possible to envisage two families of NoGap applications. First of all, new services based on the hypervisor, typically Security as a Service, but also perhaps to enrich, thanks to semantics, the functionalities that are incumbent on the infrastructure, such as the network and resource allocation for example.