It goes without saying that in my conversations with customers, security is one of, if not the main concern. Security might not bring customers to the cloud, but it certainly is a reason they avoid the cloud. Even though modern public clouds are on average more secure than the traditional datacenter, new threats exist in a shared environment, as well as the expanded scope, or "blast-radius", of a compromise.
In this series we would like to explore several of the cutting-edge security architectures enabling Oracle's Gen 2 Cloud Infrastructure. Oracle's Gen 2 Cloud, Oracle Cloud Infrastructure (OCI), is designed around several modern security principles. Specifically, zero-trust, least privilege networking that results from the assumption that any host or network device could be compromised. One of the primary ways we accomplish this at OCI is via Isolated Network Virtualization. By isolating and virtualizing the network with an innovative software-defined networking architecture, OCI provides a stronger base security posture to the cloud tenancy without performance cost to the instance. In this post, I'd like to introduce some of the threats that Isolated Network Virtualization was designed to mitigate, and how it does so.
When OCI was conceived as a bare-metal cloud compute service, extensive threat modeling was done to understand what threats exist in a shared cloud computing environment. In modelling these threats we found that in traditional datacenters and first generation clouds, if an instance has been compromised, there are few barriers to an attacker being able to exploit the networking configuration to access other networks and hosts. OCI's security architecture assumes the eventual compromise of some cloud instances, and therefore is designed to compartmentalize the compromise in order to eliminate attacks against other tenant virtual cloud networks. These threats aren't just limited to Bare-Metal Instances. They can also affect Virtual Machine-based instances and application container deployments when combined with VM or container escape exploits, learn more here. We explore some of those threats below.
If an attacker gains control of a bare-metal instance, or can escape a container or VM host, they can directly attack other instances on the same network segment and attempt lateral movement. Given this threat, we should take steps to isolate and control network traffic between machines and instances beyond what is usually implemented.
Controlling a network interface can also allow the attacker to surveil and modify traffic sent either to or from that host. This is the long-standing OWASP classic attack, the Man-in-the-Middle. Encryption may help to mitigate the impact to data from other instances that may be exposed, but the best solution is minimize or eliminate the exposure if possible.
Lastly, the attacker can always fall back to launching Denial of Service attacks against other instances, VCN's, or the cloud provider's infrastructure for ransom or activist purposes.
What if we could isolate instance networking in such a way as to eliminate all three of these threats entirely?
In OCI's second generation cloud, the network architecture uses specialized hardware to virtualize the network, confining host network functionality. The primary source of this functionality is a specially design piece of networking hardware called the Isolated Network Virtualization device.
This device provides instance traffic a physical proxy to the substrate network on which Virtual Cloud Network abstractions are built. This NIC has custom silicon designed for advanced networking. The card provides two interfaces. The first interface connects directly to the Host NIC through a cross-over cable for proxy functions. The second interface connects the device to the physical substrate network. VCN overlay networks are built on top of this physical substrate to provide connectivity to compute instances.
On this device is where the Isolated Network Virtualization takes place. In a traditional bare-metal host, this device would not be isolated as the card is connected to and managed by the host operating system. However in OCI, these are isolated from the base host by disabling the PCIe data lanes. Only power is received by the device over PCIe, removing any ability for the host to manage the card or interface.
This device also uses Software-Defined Networking to virtualize network traffic, removing control of the network from the host. While it is primarily used to isolate and virtualize the cloud network from the instance, it also provides other benefits. By offloading the network virtualization to an independent hardware resource, the compute processing overhead associated with network virtualization does not impact instance performance.
So, how does OCI's Isolated Network Virtualization prevent these attacks? OCI isolates physical network interfaces and cards from each other, preventing an attacker who has gained unauthorized access to the network through an instance from attacking a more sensitive resource. By isolating the network virtualization, we reduce the attack surface provided to bad actors in the case that an instance, bare-metal, virtual-machine, or container, has been compromised.
Further, by using software defined networking to create virtual cloud network overlays, OCI provides distributed security policy enforcement at network endpoints within the cloud.
As we have discussed, public clouds pose unique security threats to a shared tenant environment. One of the largest threats is the ability of an attacker to break out of their tenancy and attack other tenancies and resources in the cloud. By isolating and virtualizing cloud network function, OCI provides additional protection to limit the blast-radius of shared host compromise to the local instances and prevent attacks against other tenant virtual cloud networks. With OCIs modern approach to networking through isolation and virtualization outside of the compute instance, OCI provides customers with a better default security posture to their cloud tenancies.