First Principles: Robust data breach protection with Zero Trust Packet Routing

September 10, 2024 | 13 minute read
Pradeep Vincent
Senior Vice President and Chief Technical Architect, OCI
Text Size 100%:

At Oracle Cloud Infrastructure (OCI), security is a top priority, protecting sensitive data in the cloud for our customers. Traditional network security measures often fall short, leaving data vulnerable to breaches and outages. That’s why we’ve collaborated with Applied Invention on a better standards approach called Zero Trust Packet Routing. We recently announced our implementation, Oracle Cloud Infrastructure Zero Trust Packet Routing (OCI ZPR). In this blog post, we explore the limitations of current solutions and introduce OCI ZPR as both an evolution and a revolution in network security.

In the following video, we discuss the motivation behind ZPR with Dr. Danny Hillis. We introduce the concept of intention-based data-centric security. OCI ZPR decouples security policies from network configurations, providing an extra layer of protection for your data. This addition offers a robust and failure resistant solution. It also provides a high-level overview of the OCI ZPR architecture and its key benefits.


The challenge of traditional network security

In a traditional cloud setup, data movement is typically enabled and secured through a combination of virtual network configuration and network security policies. Network and security operators manage these configuration settings, respectively. However, this comingled configuration often leads to complexities and security gaps. When the network details change, it can inadvertently affect security policies in a way that’s hard to predict or evaluate, creating vulnerabilities that can go unnoticed.

Architecture diagram for the example deployment.
Figure 1: Is your data in the cloud secure?

Additionally, traditional network security relies heavily on IP addresses and network topology. This setup can make it challenging to keep up in cloud environments with dynamic scaling and complex interconnected characteristics. As cloud setups abstract away from a simple static number of computers communicating together, the potential for misconfiguration and change errors increase, leaving data exposed to breaches and outages. Let’s illustrate that challenge with an example.

Network security challenge: Securing sensitive data in the cloud

Imagine a company, Supremo, that has developed a novel nature monitoring device to collect sensitive data for environmental research and user insights. This common example architecture is typical for an application that stores sensitive data, but it needs some level of access control. To ensure the security and confidentiality of this data, the company has designed a cloud-based service with robust security measures, including the following features:

  • Strong data and network isolation
  • Private and sensitive data stored in a central database, isolated from customer traffic and the internet
  • Untrusted inbound traffic routed through a safe ingestion workflow
  • Data for customer access aggregated into a separate public database
  • Selected scientists granted sensitive data access through a virtual private network (VPN) connection

Architecture diagram for the example deployment.
Figure 2: Supremo App Architecture

The simplified architecture of figure 2 shows many moving pieces in! For this example, we focus on the interface between the scientists and the sensitive data being collected in figure 3.  

The relevant half of the example architecture
Figure 3: Supremo App Architecture – Relevant part

As shown in figure 4, the initial network and security policies for the science app allow access only from select IP CIDR ranges over VPN links to a dynamic routing gateway (DRG) with no direct access to the central database. This configuration helps ensure that sensitive data remains secure.

Example network security policies and configuration.
Figure 4: Supremo network security policies

The challenge: Scaling security with growing demand

More devices come online, generating more data. More data leads more scientists to request access to the data. To simplify onboarding, the team implements a restricted Internet access approach, as displayed in figure 5. The tight IP constraints maintain sensitive data security with policy changes demonstrated in figure 6.

An example architecture with restricted internet access.
Figure 5: Supremo restricted public access

Example access policy changes.
Figure 6: Supremo access policy changes

However, as the data gains more popularity, more scientists and clients demand access, as shown in figure 7. The application and database both need to scale to keep up with demand. The access control lists and network security group policies become increasingly complex and unwieldy. Under the best of circumstances, reviewing pages of numbers accurately is difficult for humans.

An adjusted architecture with broader public access.
Figure 7: Supremo broader public access

A network access policy error.
Figure 8: Supremo network security policy error

More complexity can result in accidental errors in the policies shown in figure 8 that allow external parties to access the database in figure 9.

Data breach wtihin the virtual network
Figure 9: Supremo data breach

This scenario highlights the need for a more effective and efficient network security approach. We need a way to handle changing business needs while ensuring security and confidentiality properties remain intact. What was once a well-defined network configuration and security perimeter has now become a complex web of rules, inadvertently exposing the sensitive database to the internet. The complexity of the system has created a blind spot, making it difficult for security operators to detect the vulnerability easily.

A real-world concern: Data leaks and breaches

This scenario isn’t hypothetical. Misconfigurations in cloud environments have led to data leaks and breaches in the past. We can trace numerous examples of data breach events back to errors in complex network configurations, as shown from various online publications in figure 10.

Headlines of data breach incidents
Figure 10: Data breach coverage from online publications

While cloud platforms often attribute these incidents to customer error, we believe that we need to do better. As a cloud platform, it is our responsibility to provide products and primitives that enable customers to maintain a robust and failure resistant security posture. We must acknowledge that complexity is a major obstacle to security and take steps to simplify and strengthen our customers' security defenses.

How did we get here? Where do we go?

We had a special guest on the video, Dr. Danny Hillis, computing legend. Dr. Hillis was one of the earliest participants on the internet. He registered the third domain name into the global domain name system (DNS). From that early vantage point, Dr. Hillis has become an outspoken challenger of the way things are.

The beginnings of the internet were vastly different from where we are now. On January 1, 1983, the ARPANET switched to using TCP/IP, marking the birth of the modern internet. In mid-1984, the entire network could still be easily mapped and understood, as illustrated in figure 11.  While bad network actors existed even then, local accountability could handle it. Security of the network was an afterthought.

A map of the internet in the United States from 1984.
Figure 11: A map of internet networking in 1984. From https://www.vox.com/a/internet-maps.

Contrast that map to today, where some homes and most offices have more internet-connected devices than the entire internet in those early days. While security devices and techniques have innovated, scaled, and improved – it’s inescapable that the foundations on which our modern networks are built still reflects an early ethos.

If our responsibility is to provide better ways for our customers to maintain data and network security, we can’t accept these deficits. As an outspoken challenger of the way things are, Dr. Danny Hillis and his company, Applied Invention, seemed a natural collaborator. What we wanted was a better way to define and execute network security. Hillis and his team helped us to explore what network security should look like, learning from the experiences of what came before.

OCI ZPR: A paradigm shift in cloud security

As seen in our Supremo example, we need to define network security properties separate from the network arrangement. The foundational security assertion—that the sensitive database shouldn’t be available directly from the internet—didn’t change as Supremo embraced success. Information security policy should capture the intention of what happens to information and where it can go. Enforcement of that intention—how the information does or doesn’t get where it should go—is an infrastructure problem.

OCI Zero Trust Packet Routing works with the following features at its core:

  • Intent-based security policies: With OCI ZPR, customers define human-readable security policies, called OCI ZPR policies, that capture the intention of how data should flow within their network. These policies are independent of IP addresses or network topology.
  • Decoupling security from network configuration: OCI ZPR policies are managed separately from network policies. So, network administrators can change the network configuration without inadvertently changing security positions.
  • Enforcement at the network layer: OCI ZPR policies are enforced at the network layer, helping ensure that all traffic complies with the defined security intentions.
  • Continuous monitoring: OCI ZPR continuously monitors the system for any changes that might impact security intentions, helping ensure that the security posture remains robust.

OCI ZPR: Open standard

In addition to their excellence in innovation, we collaborated with Applied Invention for a second purpose. All these OCI ZPR properties are capabilities that any network operator should want. Intent-based network security controls are both extremely powerful and how network security should function in 2024. At OCI, we believe in competing on superior performance and construction and not proprietary lock-in.

Applied Invention is leading an effort to make the ZPR language and approach to be an open, international standard. We hope to see other implementations.

OCI ZPR in action: Supremo

Let’s look at how ZPR improves the complexity challenge in our Supremo example. Supremo has used ZPR in the following ways to secure their resources:

Step 1: Assign security attributes: Supremo assigns security attributes to their resources, as shown in Figure 12. All the Compute instances that run the Science application are assigned the ZPR security attribute, “science,” making them addressable with ZPR as app:science. The database instances carry the security attribute, “sensitive,” addressable as database:sensitive. The VCN that connects them is assigned ZPR security attribute, “prod.”

Example ZPR configuration with security attributes.
Figure 12: ZPR security attributes

Step 2: Wriite ZPR policies: In figure 13, the company writes ZPR policies that allow only permitted network packets to flow through the network. These policies are evaluated after other network configurations have permitted the flow, acting as a final guardian that only authorized traffic reaches the sensitive database.


Example of a ZPR security policy
Figure 13: ZPR security policy example

Policy example: Secure connectivity to sensitive database: One ZPR policy statement allows any application host with security attribute “science” to establish a SQLnet TCP connection to the database with security attribute “sensitive,” as shown in figure 13. Only tagged Science App instances can connect to the sensitive database, and all other traffic is blocked regardless of the network configuration.

Benefits of ZPR: By using ZPR, Supremo has achieved a robust security posture that’s resistant to security holes and misconfigurations. ZPR includes the following key benefits:

  • Common architecture reference: ZPR policies establish a common architecture reference, allowing security design to describe “what can talk to what” in a human-readable language.
  • Durable security intention: The intention expressed in ZPR policy is durable to the lifetime of the architecture, not the current network state.
  • Elastic infrastructure: You can write ZPR policies before, after, or during network configuration, and you can enforce, validate, and audit them independently of the topology, configuration, or network participants.
  • Separation of security policies from network configurations: ZPR separates security policies from network configurations, allowing for more flexibility and scalability in infrastructure deployment. In the example policy, no IP addresses or device quantities are defined.

Flowchart of ZPR policies providing security protection
Figure 14: ZPR protection despite error in network policy

By implementing ZPR, Supremo has helped ensure that their sensitive data remains secure, even as their network configuration evolves over time. With OCI ZPR, Supremo defined a OCI ZPR policy that allowed connections to the sensitive database only from instances with security attribute “science.” Regardless of the network configuration or error shown in figure 14, any other traffic to the database is blocked, as shown in figure 15. OCI ZPR reinforced security intentions, even as the network details changed.

Architectural diagram of ZP IDs preventing data breach
Figure 15: ZPR protection prevents data breach

Similar ZPR policies for ingestion and aggregation workflows, a public database and Supremo’s app in the original architecture in Figure 2 protect those systems from the risks of data breach.

OCI ZPR architecture

Let’s walk through how OCI ZPR works. The OCI ZPR Service records ZPR policies that customers write. Subsequently, OCI ZPR translates these policies into a machine-oriented intermediate form to be efficiently interpreted at specific points in the network.

OCI ZPR translates the human-readable ZPR policies into machine-interpreted network security policies. These network security policies are sent to the VCN control plane. The VCN control plane propagates the ZPR security attributes and ZPR-generated network security policies to all the necessary endpoints. The network endpoints can then enforce these policies on the network packet flow, shown in figure 16.

Architectural diagram of how OCI ZPR works
Figure 16: ZPR policy enforcement

Network traffic passing through a ZPR-enabled network gets annotated with context-appropriate ZPR security attributes in figure 17. Every connection from any resource on a ZPR network carries these attributes. For example, every flow is annotated with the distinct ZPR ID of the flow’s origin network. Outside traffic is annotated as such. So, from our example, network traffic from the internet is annotated with a different ZPR ID than network traffic from app:science instances independent of the IP addresses on the network packets.

Architectural diagram of OCI ZPR packet inspection
Figure 17: OCI ZPR packet inspection example

Each network decision point uses the annotated ZPR IDs to determine whether the attributes of any ZPR network connection comply with the configured ZPR policy. This evaluation is independent and after any other network configurations are applied. A ZPR policy is only more restrictive: The network device must be configured to permit the traffic and ZPR must agree that the traffic is compliant.

ZPR directives are about network flow, not network packets or packet contents. So ZPR policy evaluation is performed during flow establishment and the results cached. The cached results are used for processing network packets of established network flows and consequently, ZPR policy evaluations don’t have noticeable network latency or throughput performance impact.

Conclusion

OCI ZPR marks a significant advancement in cloud security. By decoupling security policies from network configurations, OCI ZPR provides an extra layer of protection for data in the cloud. With OCI ZPR, Oracle Cloud Infrastructure is committed to providing our customers with the highest level of security and peace of mind, so they can focus on their core business while trusting that their data is secure.

Consider the following key takeaways:

  • IP network was architected to thrive in a trusted environment with security added as an afterthought.
  • Current network security in the cloud isn’t robust enough for security-conscious enterprise customers that have data in the cloud. 
  • ZPR marks a paradigm shift in cloud network security. Shifting security to intention-based data centric security solution is more robust.
  • ZPR is built using an open standard that can be used in the cloud, on-premises, hybrid cloud and multicloud environments.

Oracle Cloud Infrastructure Engineering handles the most demanding workloads for enterprise customers, which has pushed us to think differently about designing our cloud platform. We have more of these engineering deep dives as part of this First Principles series, hosted by Pradeep Vincent and other experienced engineers at Oracle.

For more information, see the following resources:

Pradeep Vincent

Senior Vice President and Chief Technical Architect, OCI

Pradeep Vincent is the Chief Technical Architect and Senior Vice President at Oracle Cloud Infrastructure (OCI). He is a technology and software architect with more than 20 years of experience in tech companies such as Oracle, AWS, and IBM. He has a deep understanding of Cloud Infrastructure, Compute, Storage and Networking. Pradeep has been with Oracle for more than eight years leading a team of architects and software engineers building Oracle’s Public Cloud. He also leads OCI’s Architecture and Engineering Community initiatives. 

Show more

Previous Post

Enhanced monitoring in OKE with Logging Analytics

Winston Lin | 5 min read

Next Post


Announcing private IP address support for OCI Object Storage using private endpoints

Rajiv Garg | 6 min read
Oracle Chatbot
Disconnected