In our increasingly interconnected world, data security has emerged as a paramount concern. Traditionally, we've addressed the need to secure data-in-motion—data that is being transmitted between applications and end users, and data-at-rest—data stored in databases and other storage systems. But what about the data moving inside of an application, often between the APIs that constitute it? This is referred to as data-in-use, and it presents a unique set of challenges to secure.

## What We've Achieved: Data-in-Motion and Data-at-Rest Security

Data-in-motion has been successfully secured using technologies such as Virtual Private Networks (VPNs), Cloud Access Security Brokers (CASBs), and Secure Access Service Edge (SASE). VPNs create encrypted connections between users and the internet, ensuring that data cannot be intercepted or tampered with during transmission. CASBs provide visibility into cloud-based applications, enforce policies, and detect and respond to threats. SASE combines networking and security services into a single cloud-based platform to provide secure access from any location.

On the other hand, data-at-rest is secured using fine-grained access controls, next-generation Data Loss Prevention (DLP), and data classification technologies. Fine-grained access controls limit who can access data based on user roles and privileges, while next-generation DLP systems prevent unauthorized data exposure by continuously monitoring and protecting data across an organization. Data classification, in turn, involves categorizing data so that it can be easily and efficiently protected, ensuring sensitive data gets the highest protection level.

## The Unique Challenge: Securing Data-in-Use

Data-in-use is different. It refers to the active data that APIs or data microservices extract from both data-in-motion and data-at-rest to perform an application's functions. This data is seldom complete; APIs typically read and transport specific records from databases, not entire tables. They move byte-ranges from documents, not the complete documents, and combine data fragments.

This fragmented and modular nature of data-in-use makes it difficult to track and secure with the same techniques used for data-at-rest. Solutions designed for data-at-rest security work with structured and predictable data sets. In contrast, data-in-use is fluid, moving in and out of various components of an application, with uncertain data alignment and lack of clear record boundaries.

A system intending to secure data in APIs could potentially ingest every API spec to understand the data structures, permissions, and data flows. However, collecting these specifications would be burdensome for customers and still fail to provide complete security. 

Next-generation DLP products can classify the data but cannot determine its permissions and ownership, critical aspects for data-in-use security. For instance, in a multitenant application, it's less about knowing that two customers' data is private and more about ensuring Customer A's data is not accessible by Customer B. 

## The Future: Continuous Observability and Authorization with Caber CA/CO

Enter Caber CA/CO, a platform designed specifically to secure data-in-use. Rather than merely classifying data, Caber identifies the ownership and permissions that belong to the data as it moves within an application, addressing the unique challenges of data-in-use security. 

Caber provides continuous observability, meaning it monitors data-in-use in real-time, tracking its movement and usage. This approach enables quick detection and response to any anomalies or security incidents. 

Moreover, Caber applies continuous authorization. It validates permissions and data ownership at each stage of data movement and usage, ensuring that only the right entities have access to the right data at the right time. 

In a world where APIs are the building blocks of modern applications, securing data-in-use is critical. Caber's unique approach fills the security gap, providing comprehensive observability of how data-in-use moves so you can develop policies to control it, and continous authorization against those policies so you can verify they are working.

Securing data-in-use, the data moving inside applications, presents unique challenges. Traditional security measures for data-in-motion and data-at-rest are insufficient since APIs often tranport and combine fragments of data from those sources.

This is Why You Can't See Data-in-Use

Application Programming Interfaces (APIs) today are the conduit for data between and inside modern applications. However, with the complex network of loosely-coupled APIs and the continuous pace of changes introduced by CI/CD workflows, the securing applications is increasingly challenging.

The primary purpose of application security is twofold: controlling where application data can go and managing who can access it. The first aspect is a question of data integrity and confidentiality, ensuring that sensitive information doesn't fall into the wrong hands or is not altered during transmission. The second aspect is a matter of data accessibility, establishing user permissions to regulate who can view, modify, or distribute the data. These are the core tenets that drive security mechanisms in modern applications.

Implementing these principles consistently in an ever-changing environment is a daunting task. The dynamics of modern application architecture, with their sprawling ecosystem of interconnected services, have made it significantly more difficult to maintain a stable security stance. Given these challenges, Google's security initiatives, [Zanzibar](https://research.google/pubs/pub48190/) and [BeyondProd](https://cloud.google.com/docs/security/beyondprod), offer revolutionary solutions that tackle API security in a novel way.

## Google’s Security Paradigms: Zanzibar and BeyondProd

Zanzibar, aptly dubbed "The Google-Wide Authorization System," revolutionizes traditional authorization methods. Instead of depending on the specific parameters of APIs, Zanzibar incorporates ownership data directly into the data packets being transmitted. By tying authorization to the data itself, it ensures that data ownership remains constant, regardless of API changes or data pathways.

Meanwhile, BeyondProd introduces a profound shift in the approach to network security. It places stringent requirements on every user interaction, data piece, and service, establishing a network-wide, defense-in-depth security model. By focusing on data, rather than how it moves through the network, BeyondProd ensures a steady state of security, irrespective of changes in the API environment.

While both Zanzibar and BeyondProd present an ingenious paradigm for securing data, their broad-scale implementation may be impractical for many enterprises. The requisite modifications in every API to integrate these security models can be a major undertaking, potentially disrupting existing workflows and incurring significant costs.

## Caber CA/CO: Embodying Zanzibar and BeyondProd Principles Without Overhauling APIs

Enter Caber Continuous Authorization/Continuous Ownership (Caber CA/CO), a system that captures the essence of Google's security principles without requiring extensive API modifications. Caber CA/CO ties data within APIs to its ownership and permissions at rest, enabling real-time, continuous authorization.

By monitoring API calls and using the information obtained from data ownership and permissions, Caber CA/CO makes immediate authorization decisions based on the data itself. This mirrors the advanced principles of Zanzibar and BeyondProd, enabling the same level of data-centric security in a more accessible, less disruptive manner.

## In Conclusion: Navigating API Security in a Dynamic Environment

In a rapidly evolving API landscape, maintaining consistent authorization and data security is a formidable challenge. While the principles behind Google's Zanzibar and BeyondProd offer compelling solutions, their wide-scale deployment may not be practical for many enterprises. 

Fortunately, Caber CA/CO provides a viable alternative. It delivers the benefits of a robust, real-time, data-centric security model, reminiscent of Google's pioneering initiatives, but without the need for extensive API modifications. By focusing on data, ensuring continuous authorization, and adapting to the fast-paced world of APIs, Caber CA/CO emerges as an ideal solution to modern API security

 challenges.

With the proliferation of APIs and the continuous evolution of the software landscape, it's evident that traditional security models may fall short. Solutions like Zanzibar, BeyondProd, and Caber CA/CO provide a glimpse of the future of data security. They embody an approach that transcends the stability of APIs, focusing instead on the data itself—our most valuable digital asset.

Google undertook a massive effort to pass the ownership and permissions of the data APIs carry to authorize access to data at every API. Here's how you can achieve a similar benefit with Caber without disruptive changes to existing API structures or applications.

If DLP Worked Google wouldn't have Built Zanzibar

With the move to cloud native architecture, APIs (Application Programming Interfaces) have become the veins and arteries of application data flow, circulating customer-owned information between enterprise owned regions and to third-party data processors. The need for stringent and effective API security policies is self-evident, but enterprises struggle with creating and maintaining these policies because they lack visibility into the very data flows they are trying to secure. This conundrum triggers a costly "cycle of pain" that drains significant resources and disrupts operational productivity.

## The Cycle of Pain Unveiled

The cycle of pain typically begins when engineering teams are tasked with creating data flow maps to guide compliance teams. These maps are a representation of how data is expected to move within the applications, serving as the foundation upon which high-level policies are created. However, this foundational step is inherently flawed. The maps are, at best, temporal snapshots, and fail to account for mistakes, corner cases, or unanticipated interactions between APIs. As applications adapt to rapidly evolving market demands, they continually introduce new functionalities, and these modifications can shift the data flow in ways the original maps do not capture.

Despite being fundamentally flawed and static representations of a dynamic reality, these maps become the primary resource for compliance teams. They use them to create policies that specify where data can and cannot go in accordance with privacy laws and other regulations like PCI (Payment Card Industry) and HIPAA (Health Insurance Portability and Accountability Act). But given their source, these policies are inherently predisposed to inaccuracies and inefficiencies.

The third phase of the cycle involves these policies being passed to the security teams for implementation. These teams, responsible for securing the company's data, must implement the high-level policies in firewalls, Cloud Native Application Protection Platforms (CNAPP), and API security platforms. These technologies, while crucial to the security infrastructure, unfortunately offer no visibility into the different types of data being transmitted, leaving no room to validate if the implementation adheres to the intended policies.

The final phase sees the inevitable fallout of these systemic flaws when compliance audits uncover policy implementation failures. These failures trigger engineering fire-drills that disrupt product roadmaps and inflate operational costs. In essence, the cycle of pain results from the fundamental disconnect between policy creation and implementation, compounded by the lack of data visibility and accurate monitoring of data flow within APIs.

## The High Cost of the Cycle

The implications of this cycle extend far beyond non-compliance. Companies stand to lose millions of dollars due to lost productivity, costly disruptions to the product roadmap, potential fines from regulatory bodies, and reputational damage. The cycle of pain is not just about data and security—it's a multi-faceted business issue.

This cycle could be mitigated, if not entirely circumvented, if compliance policies were developed from actual data flow, and if security implementations could be continually monitored and authorized based on the real-time flow of data in APIs. It goes without saying, you can't secure what you can't see, and here too continuous observability, and data access authorization are critical to breaking the cycle.

## The Solution: Caber Continuous Authorization and Observability (Caber CA/CO)

This is where Caber CA/CO steps in, a solution designed to redefine the approach to API data flow security. Caber CA/CO provides real-time visibility into data flows, enabling companies to devise robust and accurate compliance policies based on actual data movements rather than relying on potentially flawed, static maps.

Caber CA/CO empowers security teams by offering observability into API data flows. This continuous visibility allows for constant validation of policy adherence, leading to timely rectifications whenever discrepancies occur. As a result, it eradicates the risk of surprise audit failures and the subsequent expensive fire-drills, thus helping preserve the product roadmap and productivity.

Furthermore

, Caber CA/CO's authorization feature ensures that data only flows where it should, providing an extra layer of security and reinforcing policy implementation. By combining these features, Caber CA/CO not only provides a solution to the problems plaguing API security but also offers a proactive strategy that prevents the issues from arising in the first place.

In conclusion, while the cycle of pain caused by lack of API data flow visibility can be a drain on enterprises, solutions like Caber CA/CO offer a path to pain relief. By enabling continuous authorization and observability, businesses can create dynamic, accurate policies and maintain security implementations that align with these policies, thereby reducing costs, avoiding compliance failures, and preserving productivity.

Due to a lack of data flow visibility enterprise app teams have to enforce policies they have no way to verify.  And when problems arise they have few tools to help remediate them.

 App Security Cycle of Pain

For decades, enterprise application security teams have fortified their defenses primarily around the conduits of data—the digital channels that facilitate the flow of information. In the era of client-server computing, this approach was more than adequate. Enterprises could effectively safeguard data by leveraging firewalls with rules anchored on network IP addresses and ports, essentially laying a protective perimeter around the physical machines that held valuable data. The simplicity of this direct correlation between the conduit and its contained data rendered this method both effective and efficient.

This method's effectiveness stemmed from our ability to assign specific IP addresses and ports to the machines holding the data we aimed to protect. The conduit of data and the data itself were virtually identical, making it possible to exercise stringent control over access. However, as the adage goes, "You can't secure what you can't see." The irony of this saying now manifests in our current digital landscape.

### Next-Generation Firewall, Same as the Previous
The advent of web applications ushered in the era of three-tier application architecture. This evolution complicated matters by placing multiple applications on the same port, effectively diluting the once perfect correlation between the conduit and the data it contained. The rise of Software-as-a-Service (SaaS) applications further muddled the picture, rendering the IP addresses virtually meaningless.

In response to this new challenge, a new type of firewall was born. Palo Alto Networks pioneered the application firewall, a solution that could identify the applications behind firewall rules rather than merely the conduit of data. This innovative approach was a significant leap forward but was not without its flaws. We were still protecting application data by identifying the application, not the actual data itself—a critical distinction that has become increasingly consequential.

### Securing the Conduit No Longer Secures the Data
Fast-forward to the current era of cloud-native applications, with their hundreds of Application Programming Interfaces (APIs). Each API acts as a conduit for data, but the correlation between the API and the data it carries has become increasingly blurred. In effect, we're left trying to secure a nebulous collection of conduits, many of which bear little relation to the data they contain.

It's clear that in this new landscape, protecting the conduit no longer equates to protecting the data within. The stark reality is that we're trying to secure the wrong thing. It's high time we turn our attention to the actual data flowing inside these conduits, irrespective of the API or application in which it resides.

We need to move beyond the conduit-centric mindset and embrace a new approach to data security—one that directly secures the data in transit, regardless of the conduit it happens to be flowing through. This revolutionary approach calls for a new kind of firewall, one that eschews the traditional focus on the conduit and instead provides robust protection for the data itself.

### See Where Data Goes.  Secure Where Data Goes.
Enter Caber CA/CO. This groundbreaking solution offers security teams exactly what they need—a new level of visibility into the data moving within APIs. By focusing directly on the data, Caber CA/CO allows security teams to exert precise control over access to information, regardless of where it resides or the conduit it traverses.

It's no longer about securing what we can see, but rather about making the invisible visible. The data flowing within our APIs is no longer a shadowy figure lurking in the background but rather a tangible entity that we can scrutinize, understand, and effectively secure. The age-old adage of "you can't secure what you can't see" rings hollow now. We are making the invisible visible and securing it.

The path forward for enterprise application security is clear. We must transcend the dated focus on conduits and embrace a data-centric approach. Caber CA/CO is leading the way, proving that even in a world dominated by the intangible and invisible, robust data security is well within our grasp. This

 shift in focus is more than a change—it's a revolution. And as with any revolution, the old must make way for the new. It's time for us to secure the invisible, to safeguard what truly matters—the data itself.

To protect data, security teams have traditionally enforced policies on the conduits that carry the data, the network, application, and APIs.  Yet in cloud-native applications the correlation between these conduits and the data they carry falls far below our standard of Zero Trust.

All Posts

This is Why You Can't See Data-in-Use

If DLP Worked Google wouldn't have Built Zanzibar

App Security Cycle of Pain

Securing the Conduit Doesn't Secure the Data