Data Leakage

As stated before, Data (or Information) Leakage is the unauthorized transmission of information to outwith the system or organization. It is also essential to ensure that there is nodata leakage occuring during the authentication and authorization processes, that is the initial stages of a client initiating a link to a cloud and the setup required. When clients need to validate themselves to get access to their resource, a large amount of data is exchanged between the client and the resource host. Based on the user’s privilege levels they are authorized to access their resources. If the data exchange is not well protected, data leakage is more likely to happen [28].

Nimkar and Ghosh [119] stated that one of the security issues in IaaS VN is the routing protocol confidentiality between tenants, that is those protocols that send packets around a network. The authors investigated several protocols applied to virtual routers and switches specifically considering security issues such as origin authentication, path validation, hop integrity, address attestation and identity request server communication. They considered protocols such as MDR, ROFL, SVTR, S-BGP, IRV and So-BGP with virtual software routers on the control and data planes and hypervisor-based or hardware-based virtual switches. The paths drawn by the VN topology needs to be verified by the router with its routing protocol so these protocols must be equipped with some verification and authentication to prevent leakage or expose information during routing within the shared physical environment.

Another data leakage issue is one that Gutz et al [22] stated in their Splendid Isolation research. Their isolation approach, which they called separation, used virtual LANs (VLANs) to separate out the processing and maintain isolation to prevented data leakage between slices running parallel on the same shared environment. They coded different scenarios through programming to modify a network to satisfy client demands, despite demand diversity. When some programs ran side by side from each other the network interaction was different from running individual programs. The speculation was that if a function failed to perform, it might effect the network behaviour of the network and allow other programs to run and access resources that were denied to the broken program. Hence critical local information would be leaked, sniffed by mischievous clients and then used to investigate other tenants isolated resources. The authors noted that guaranteeing confidentiality of packet leakage and integrity was future work.

Figure 2.3: Overview of the SDN Security Survey[27].

see Figure 2.3 , section III [27]. The data targeted was not the user’s personal and sensitive data, but was the OpenFlow switch traffic controlling rules to forward or drop or to communicate with the SDN controllers. Attackers could determine valuable knowledge through learning about the packet types and actions. Such an approach allows attackers to expose the proactive/reactive configuration of OpenFlow switches through analyzing the process time of traffic forwarded between input/output interfaces or directed to the controllers. Based on the knowledge gathered of the packets type from the leaked traffic, a potential DoS attack could be generated with forged traffic to cripple the SDN/OpenFlow functionality [27].

[27] also categorized security issues for SDN security issues. They listed three main categories affecting Data Leakage:

1. Flow Rule Discoverywhich can be exposed by a Side Channel Attack on an Input Buffer, shich is expected to target only the SDN Data layer.

2. Credential Management, such as Keys and Certificates required for every VN, which only affects the data layer.

3. Forwarding Policy Discoveryvia Packet Processing Timing Analysis, affects the Control layer, Control-Data interface and the Data layer .

Scott-Hayward et al [27] also noted seven SDN issue categories which are without a research plan or proposed solutions, as of 2015, and they are Data Leakage and Data Modifications. A best practice recommendation by the authors was to secure a shared network environment from various security issues such as unauthorized access, data manipulations, and data leakages prevention by isolating the network resources via slicing. Slicing provides a better resource isolation and allocation mechanism than does VN.

Different Data Leakage sources will have different impacts based on the data which has been leaked. For example, Data Leakage from the data plane will cause data to exist in a place where is does not belong and where there is no protection plan for it. Leaking data from the control panel and the management plane is more devastating as it will extend the impact onto the data plane for manipulating/modifying the forwarding rule or changing routing functionality. Hence, a network virtualized structure should be at same level as the hardware equipment in terms of control and featureto secure the related information from leakage [6].

Data leakage between virtual elements is not important for the following cases. When two virtual elements share the underlying structure Data Leakage can happen if one element gathered information about a co-existing element. Attackers may gain knowledge from compromised leaked data in order to cause more damage. Another case is when attackers find a vulnerability in the underlying structure that makes it easy to collect critical information about co-existing components. Mis-design and mis-implementation are other issues for a shared infrastructure. Shared resources require a proper isolation in order to avoid leakage between abstracted elements in components [6].

A misconfiguration in a cloud shared environment component such as mistakenly connecting two tenants to the same resource, or failing in isolation implementation, will lead to tenant critical information leakage. One of the impacts this may cause is a tenant domain being attacked by external tools or by another tenant taking advantage of that unnoticed weakness [80].

A Data Leakage attack is not categorized as a high security threat impact, but what makes it dangerous is the value of the information leaked to the attacker and the knowledge to launch a far more severe attack. VMs are the most vulnerable element in the cloud, and are likely to be, the biggest source of data leakage incidents [120].

Another case of data leakage is VM duplication in compute on-demand provisioning. Amazon EC2 provided a facility for creating a template of an image based on a created and fully functioning VM and made it public to be used by other tenants. The issue was the sensitive data content of the image when it was running as a VM. It foolishly shared the tenant contents to other tenants [121].

Rong et al [5] conducted a comprehensive survey on cloud security challenges and noted that cloud service tenants wanted answers to their doubts about their sensitive and personal data privacy. Concerns included :

• How and where their data is stored?

• Is the data reachable by anyone other than themselves? • Is it misused by any entity even the system admin?

In order for the cloud tenants to trust the sharing data storage over an untrusted storage provider, an incremental encryption mechanism was proposed [5]. Hence cloud storage services could be trusted even if the tenant does not trust the service provider. This mechanism is one of the suggested solutions to data leakage prevention.

The Cloud Security Alliance also reported a hot list of cloud computing threats and this list included shared technology issues, i.e isolation mechanism limitations and data loss leakages. Moreover, the list did not specify which mitigation resolves which issue with the use of IP monitoring, better authentication mechanisms and stronger firewall, encryption and well programmed APIs [1].

Beggs et al [123] state that one of the overlooked components is IPv6 as much solution development is still based on IPv4. Developers apparently forget to include IPv6, mis-implement them or disable them in the system. Therefore, cases of data leakage via IPv6 are highly possible. The authors also state that metadata can be categorized as a source of data leakage, as some tenants are not interested in them but they are most likely publicly available and hold valuable information that attackers can gather and use to design their attacks.

DNS leakage is one of the network critical information that exposes systems when DNS information is requested from the ISPs. Even if the system uses applications such as TOR , The Onion Router, to hide, DNS leakage is still possible according to Beggs et al [123] they indicate using dns.leaktest.com to check for DNS leaks after a DNS request is made as well as using the command tools dnsdict6 and dnsrevenum6 tools.

content format, encryption rules are designed to encrypt the data according to their type, and hence even if the data is leaked, the content would not be reachable [32].

2.10.5.1 Security as a Service (SecaaS)

Multi-tenancy and data leakage are strongly related due to sharing resources. Even with a

Security as a Service(SecaaS), data leakage is still a concern. The service needs to monitor

all the processes and data in the system but clients might not appreciate their resources being monitored by a source that is not part of their control. Data could be anonymized before they are monitored by SecaaS [32].

A data leakage vulnerability in an IaaS cloud may be triggered from the hypervisors in use and their associated APIs. Weaknesses in them could lead to illegal access of cloud tenant resources, information stealing, resource misuse or using the leaked data to form further attacks according to Catteddu and Hogben [29][103]. The authors also discuss how to deal with information leakage , as data goes through several stages between process, transmission or storage. Some stages, process data for example, should not be deleted or encrypted [29].

Thimmaraju and Rétvári’s paper [124] was presented in August 2018. They researched Virtual Network Isolation by investigating 22 vSwitches and evaluated the network isolation, enforced by vSwitches, for security. Their analysis revealed four security vulnerabilities namely: Co- location, single point of failure, privileged packet processing and manual packet parsing. They planned to implement three security designs to enhance the virtual network isolation via implementing a better robust vSwitch. Our work intersects with their research in several ways, but our research aims are different. Our research involved one of 22 vSwitches and OVS, which according to the authors presented one of the four major security weaknesses. The research differs in other ways: 1. While their research is focussed on pure VN, we tested the Cloud Virtual Network,

2. Our aim was to determine the CVNI for Data Leakage while they focussed on vSwitch design for security.

3. They implemented their scenario with special hardware, SR-IOV, which we listed in our future plans.

Our research, described in this thesis, analyses the cloud virtual network isolation to determine if tenant co-residence VN elements and configuration can be leaked.