CASBs and Data Residency

*This blog was originally published here.

CASB (Cloud Access Security Broker) is a great tool to protect data while moving in the cloud and in your network. CASBs’ goal is governing usage and controlling shadow IT behaviors by providing visibility and control. CASBs can secure data with data leak prevention (DLP) and combat loss of data by encryption or tokenization of data. CASBs can also be used for threat protection from malware and ransomware by including anomaly detection and threat intelligence. Among a combination of these capabilities, it’s claimed that certain CASBs can solve for data residency. While CASBs can play a useful role in the data protection ecosystem, regardless of the type of deployment model, CASBs are not a true data residency solution and do not solve for data residency in an efficient, easy-to-deploy, or fully compliant manner. 

Generally speaking, there are two types of CASBs. Proxy-based and API-based. Proxy-based CASBs examine identified network traffic flows. API-based CASBs involve out-of-band deployment directly integrated with the cloud providers’ API interfaces. Both proxy-based and API based models have benefits and drawbacks. Let’s dive into them.

The Proxy-based approach

A CASB deployed in a proxy model acts as an in-line solution where it constantly checks and filters incoming traffic through a gateway and forwards network traffic that it deems safe. While this model could work for various data controlling use cases, it does not work well for data residency for the following reasons:

  • Users and data in scope have to be from known access points and devices. Unknown devices are not detectable and therefore are not factored in.  
  • In addition, the model severely affects the user experience. Network performance is severely degraded and the SaaS application’s performance is impacted when forcing all data through a common, in-line security filter.
  • Last but not least and this is where we see more and more CASB customers coming to InCountry, is when standard capabilities inside the SaaS application break down or become completely nonfunctional. These capabilities include searching, sorting and reporting.  Problems also frequently emerge when upgrades to the SaaS application are deployed.
in-line proxy-based CASB

API based approach

The API approach is an out of band approach that utilizes APIs to connect to the cloud provider. This ensures you have visibility and coverage of web-based or SaaS applications like Salesforce or Office365. While this approach is easier to deploy and configure, it could mean the organization’s existing controls are circumvented by direct API connections resulting in reduced protection of data. More importantly to our customers, it does not solve for data residency and does not provide a fully compliant solution. For API only solutions, there is a practical challenge as APIs are inconsistent among different SaaS and cloud providers.

Out of band API-Based CASB

The InCountry approach

The newness of the cloud and the diversity of SaaS applications have proven a constraint to the evolution of CASB, especially when it comes to specifically solving for data residency. What makes InCountry’s approach such a game changer, is its unique focus addressing data localization challenges.  Our solutions have been mapped to the global regulatory landscape to address customer use cases and country compliance requirements. Additionally, we take advantage of application-level integration with the SaaS solution to support data localization and access capabilities through message-based interfaces.

The InCountry Approach to data residency

Local compliance

In recent years, a large number of data regulations laws have been introduced. For businesses acting globally, it’s crucial they understand what they mean and comply with them. Companies with multinational presence are required to operate within the scope of the various pieces of legislation and policy in each jurisdiction. Since the inception of InCountry, we’ve noticed an incredible trend towards more data regulations and requirements involving data localization. Our focus and research on data residency allowed us to interact with regulatory authorities around the world and build a knowledge base that has been critical for helping customers.

The Data Residency Trend

InCountry’s goal is to give customers peace of mind while tapping into the benefits of the cloud, knowing that they can achieve compliance with local data regulations. With this, enterprises can enjoy global expansion without needing to do build outs in every country where they wish to operate. By focusing on data residency, we’ve created solutions that cover every possible scenario with data regulatory compliance as a priority. 

In analyzing the global market landscape, InCountry has identified three broad categories of data control requirements. The first we call Replicated Data where customers, countries and/or industries, have requirements stipulating that the primary copy of the protected data must be stored in the country before a copy can be stored and viewed outside the country.  In this case, the InCountry solution is configured such that protected data is first written to the InCountry data store and then written to the original cloud data store.

The second category we call Restricted Data where customers, countries and/or industries require that a designated subset of protected data must be stored in the country and cannot be copied outside the country.  However, this data may still be viewed from outside the country.  In this case, the protected data is written to the InCountry data store and a placeholder token will be written to the original cloud data store.

The third classification is Redacted Data where customers, countries and/or industries require that a designated subset of protected data can only be stored in the country and data cannot be copied or viewed outside the country. In this case, the data will be written to the InCountry data store and a placeholder token will be written to the original data store.  All server-side automation that reference these protected data fields will have to be implemented on the InCountry compute module using InCountry’s serverless API functions. 

InCountry integration models

A managed service

  • Our data residency-as-a-service platform is now available in 80 more than countries. Our local points of presence allow for speed, efficiency and compliance so customers can get up and running quickly and without investing in additional costs like infrastructure or local teams to handle these efforts. Once InCountry’s solution is configured for one country, the process of adding more countries becomes even easier.
  • Our managed distributed service acts as an extension of customers’ central clouds, hence offering an efficient and cost-effective platform making local compliance a much simpler proposition. 
  • Customers can choose to run InCountry’s platform on their own infrastructure, which is still delivered as a managed service.

InCountry – Data Residency for SaaS

InCountry for SaaS

Data protection became an integral part of companies’ strategies when adopting cloud solutions and the market became flooded with unproven solutions that claim simply too much. Similarly, data residency is increasingly becoming a core part of this trend.

Our focus is data residency and streamlining the tedious process of local compliance without compromising the experience of SaaS. Among the many reasons, customers choose SaaS products because of their simplicity in onboarding and scaling. With InCountry, customers looking to adopt best of class SaaS like Salesforce, Mambu, ServiceNow, Twilio and others, can now do so with InCountry’s data residency-as-a-service.