Are Your Cloud Data Flows Jeopardizing Compliance and Security?

Cloud data rarely stays in one place. It’s duplicated and moved between services, databases, and environments as a matter of course. Data movement is essential for businesses that want to build data-driven processes and products, but can also create risks if it’s not monitored by security teams.

For the sake of example, let’s imagine how a single, PII-containing CRM record can travel – and then consider the security implications:

This is a very simplified example which does not account for staging and testing environments, unmanaged databases, or shadow data. But you can still see how within 24 hours, the same record now exists in five different data stores, is processed by applications that are potentially running in different regions, and – depending on the architecture in place – might exist on more than one public cloud.

Why is this a problem for data security?

Complying with data residency and sovereignty gets complicated

In the example above, the PII belonged to Mr. Heidelberg of Berlin, Germany. This data is likely subject to the GDPR. To comply with the data sovereignty requirements, the data must reside in servers located in the European Union (or in countries with similar data protection laws). 

It’s quite likely that the cloud account spans multiple regions, including non-compliant ones. If the data is being moved or duplicated across different data stores and cloud regions, it can become difficult to track and ensure that the data is being stored in the right region.

To prevent this, the business needs a way to identify PII across its cloud environment(s), and to find connected records. For example, the CRM record might have been joined with additional data such as support tickets or marketing interactions as part of a ‘customer 360’ initiative – creating additional PII records that also need to be accounted for.

Sensitive data travels between environments instead of staying segregated

Sensitive data needs to be kept separately (segregated), and under stricter access control policies. This is a basic data security best practice but also a matter of compliance with various regulations – for example, ISO 27002:2022 requires organizations to separate development, test, and production environments.

However, it is very common for developers to download data onto their own machine or to move it between environments for testing purposes – mainly because it makes their life easier and allows them to run more realistic tests. But if sensitive data is being moved, it can put the business at risk.

The business needs to understand data flows between environments, identify when segregation requirements are being ignored, and find out if unauthorized principals are getting access to it along the way.

Security incidents can fly under the radar

When nonstop data movement is considered business-as-usual, it’s easy for an actual data breach to go unnoticed. An organization that works with multiple vendors might not bat an eyelid when an external account is accessing a sensitive database – but this type of nonchalance could be exploited by bad actors.

Mapping data flows helps to separate the wheat from the chaff, and identify the flows that should trigger an immediate response from SOC teams. If they see data going to an external account, they need to be able to know immediately whether this is in fact a vendor, and whether this vendor has the right permissions to access this dataset.

Considerations for Monitoring Data Movement in Public Clouds

While data movement poses risks, it’s an inherent part of the way businesses leverage the public cloud. Similarly to dealing with shadow data, security policies and solutions need to balance between business agility and preventing data breach events. Below are key guidelines for achieving this:

Setting a baseline: Effective monitoring requires that the security organization has a ‘baseline’ of where data is meant to reside (physically or logically), can identify deviations, and can prioritize the incidents that pose a risk – usually the ones that involve sensitive data flowing into unauthorized or unmonitored data stores.

Look at the past, present, and future of your data: In some cases, you’ll be able to prevent the policy violation before it happens; in others, your monitoring should lead to further analysis and forensic investigation. Monitoring should encompass:

• The past – where did the data get created? Where does it belong? Are there additional versions of this data?. 
• The present – where is the data right now? How did it get there? Does it belong in this data store, or should it be elsewhere? Is it moving where it shouldn't? 
• The future – is there an opportunity for the data to move where it shouldn't? Can we prevent wrong data movement if it happens?

Data context and content matters: Not all data is created equal. Classifying your data and creating an inventory of sensitive assets should help you prioritize risks. For each data asset, you should be able to answer:

• Does this data have locality or sovereignty characteristics (e.g., data related to EU or California residents)?
• Does your data have other compliance-related characteristics (e.g., electronic health records)?
• Are the same sensitive records stored in multiple data stores?
• Which security policy does the data fall under?

‍Make data movement transparent for security teams: Once you’ve identified and prioritized your sensitive data assets, you want to provide visibility into this data moves between regions, between environments, and to external consumers such as vendors or service providers. 

Develop the ability to identify when an incident has occurred: Your monitoring solution should not end with reducing static risk to data. Monitoring data flows in real time should alert you to high-risk incidents such as:

• Sensitive data being moved between development and production environments
• A configuration change which creates an opportunity for unauthorized access to the data 
• Data being moved into non-compliant storage locations (e.g., EU resident data moved out of the EU)
• Unusually large volumes of company data being downloaded or copied locally 

Steps to Reduce Data Flow Risk

Of course, monitoring is just the first step. Once you have a clear picture of your cloud data flows, you can design an effective data security strategy that protects data at rest and in motion. Here’s what you can do to minimize the risk of costly and damaging data leaks:

1. Reduce the attack surface: Remove duplicate records and review data retention policies to prevent your organization’s data footprint from growing unnecessarily large.
2. Enforce compliance: Use automated controls to monitor and identify data movement that causes non-compliance with GDPR, PCI DSS, or any other regulation.
3. Notify owners: Whenever an incident is detected, have an automated process in place to alert the data owners (and other stakeholders if needed).
4. Trigger workflows to fix compliance and security issues: Automate processes to address policy violations as soon as they occur.
5. Enforce data hygiene: Periodically review your data assets and associated permissions to prevent data sprawl and shadow data.

Find Out How Dig Security can Help

Data movement can get complicated, and public cloud providers do not offer sufficient tooling to understand how data flows between clouds and through unmanaged databases. Keeping track of your sensitive data assets across dozens of services running in hybrid and multi-cloud deployments requires a new breed of cloud DLP tooling – and Dig Security is leading the pack.

Dig unifies static and dynamic monitoring (DSPM and DDR) to provide a complete view of the sensitive data in your cloud account, including an up-to-date inventory and mapping of data flows. Our agentless solution will automatically detect new sensitive records, classify them, and identify the policies that should apply; it will then alert your security team, in real time, whenever a policy violation puts your crucial data assets at risk.

Learn more about how Dig Security works, or get in touch for a personalized demo.