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.
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.
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.
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:
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.
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.
Figure 4: Supremo network security policies
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.
Figure 5: Supremo restricted public access
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.
Figure 7: Supremo broader public access
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.
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.
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.
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.
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.
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.
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:
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.
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.”
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.
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:
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.
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.
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.
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.
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.
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:
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 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.
Next Post