There’s a bewildering number of security products today that aim to protect an enterprise’s data. So why is it that confidential data still ends up leaving with employees when they quit to join a competitor, or accidentally shared with the wrong person, or pasted into ChatGPT? The problem is partly that data security capabilities are spread across multiple products: Data Loss Prevention (DLP), Insider Risk Management (IRM), Cloud Access Security Broker (CASB), Data Security Posture Management (DSPM) and they all see only part of the picture.

But the problem is bigger than that. It’s so challenging to protect data because:

• It’s hard to classify data — whether you rely on basic RegEx or sophisticated machine learning, many types of data can’t be accurately classified looking at the content alone.
• Behavioral analysis doesn’t consider data type — an unusual volume of data downloaded/uploaded is meaningless without knowing what kind of data it is.
• Data flows across assets — data doesn’t stay in the cloud or on a device or in an app, it moves between them.
• Real-time prevention is impractical or non-existent — due to false positives, you don’t feel confident turning on prevention features, or the product lacks them altogether.

Introduction to Data Detection and Response (DDR)

Enter data Detection and Response (DDR), a new generation of data security technology that’s designed to address the long-standing challenges with protecting data. There are several foundational principles of a data detection and response approach.

Classify data based on its lineage, not just content

The biggest change in malware protection in recent years was the move from signature-based detection to behavioral-based detection with Endpoint Detection and Response (EDR). A similar change is happening in data security for the same reason: content alone is not a good predictor or indicator of what type of data it is. Consider the example of a spreadsheet with names and email addresses. Is this a list of customers, and therefore highly sensitive? Or is it publicly available contact information, or even an employee’s personal file such as a school contact list?

In addition to inspecting the content, you also need to analyze the events surrounding the data as it’s edited, shared, copied, and combined with other data. That spreadsheet containing names and email addresses? Once you know that data originated in Salesforce, it’s easier to classify it because data in that format from Salesforce is likely to be customer data. Likewise, as data moves throughout the organization there are telltale signs that indicate what kind of data it is: board slides are kept in the board meeting folder on SharePoint, and finance employees compile financial results. Analyzing these events and tracking them across time for each and every piece of data is called data lineage and it’s one of the foundations of DDR.

Focus on data in motion, when it’s most at risk

We’ve always been told that the first step to protecting data is to scan all of it at rest. This is based on two faulty assumptions: 1) you can accurately classify data by looking at its content alone, and 2) static data that’s untouched for months or years is the data to prioritize. A Data Detection and Response approach recognizes that it’s more effective to classify data based on its content and context. DDR uses dynamic monitoring of data flows to assemble a live data lineage, classifying the data much more accurately than scanning its content alone. The other important distinction is scanning data when it’s in motion, not when it’s at rest.

Data sitting on a file server, or in a Google Drive folder, or in a Snowflake database untouched for months or even years doesn’t have much insider risk until an employee  does something with it. So why bother scanning it? Scanning and analyzing large amounts of content is computationally (and therefore financially) expensive. It’s also not the data to worry about. When an employee accesses that data on the file server, or tries to share the Google Drive folder, or exports data from Snowflake, that’s when the risk to data increases. Data Detection and Response relies on real-time monitoring, detection of risks, and response to better protect data.

{{promo}}

Follow data everywhere, across all assets

In today’s dynamic workplace, data is the lifeblood of an organization. The way people work naturally means that the most important data often flows from person to person and from application to application. It doesn’t stay locked away in OneDrive, Salesforce, or Amazon Web Services. It leaves the cloud for endpoints. It leaves endpoints for the cloud and email. It’s not realistic to stop employees from collaborating with data, or moving it to new places and systems to make better use of it. Data Detection and Response follows data across all these different assets, in your company and also your extended enterprise, so productivity can safely happen.

Take action in real time to stop exfiltration

It’s not enough to be alerted to a risk in progress. By the time a security analyst can get to that alert, it’s often too late and confidential data has left your company. You need to automatically take real-time action to protect data. Some data security products have real-time protection capabilities but companies don’t use them because the systems have so many false positives, turning on blocking would stop employees from doing everyday work. In other cases, the way products are designed they aren’t architected to be able to take action. A key element of Data Detection and Response is real-time action to stop data exfiltration.

The moment when an employee attempts to paste a Zoom transcript of a confidential internal meeting into ChatGPT, or AirDrop a ZIP file containing product design files to a personal laptop, or upload a list of all customers from Salesforce to a personal Dropbox, DDR takes action to stop data from leaving. Depending on the type of data and the risk involved, you may want to allow employees to override this enforcement action and continue. There are always edge cases or approved business exceptions, such as when the client requires you to upload the files to their Dropbox account, and part of DDR is giving a range of options to enable work.

‍