A technical look at how Netskope One Data Lineage reconstructs a file’s journey and closes visibility gaps with endpoint events.
It almost feels like a Shrödinger riddle: When a user downloads a financial report, renames it (e.g. holiday_photo.jpg), edits it, and uploads it to personal cloud storage, is it still the same file? Arguably not, but the data still requires consistent governance. The challenge of course is consistent visibility. Network-based controls would see both ends of the sequence (the download and the upload), but they couldn’t tell if the two events involved the same (albeit edited) file because, by the time it resurfaces, both the name and the content are changed. Unless something was watching the handover on the device, nothing ties these two files together.
This post looks at how Netskope One Data Lineage reconnects a file’s journey when everything about the file changes along the way, and what happens when endpoint visibility closes that blind spot.
Why files don’t hold still
A file has no stable identity as it moves between apps, devices, and destinations. Application IDs don’t travel with it, since SharePoint and Google Drive each assign their own identifiers, and neither survives a download and re-upload. Content hashes change after an edit (and sometimes even without one, since some applications alter a file’s bytes on upload regardless of what the user changed). Filenames drift for routine reasons too, so Q3 Forecast.xlsx becomes Q3 Forecast (2).xlsx or Copy of Q3 Forecast.xlsx.
Without a stable key, lineage can’t be a simple lookup, so tracking data in this way has to combine evidence from application, network, and endpoint activity to figure out which events belong to the same file.
The image below shows a data lineage graph, where nodes represent a file and its location, and the lines connecting the nodes are the activity which caused a change or transformation. The whole graph shows a file family and the right side of the image shows a timeline view.
How lineage weighs evidence
Building such a graph as this requires evidence, and there are a number of ways to collect this. Netskope One Data Lineage ranks evidence by strength, and always uses the strongest signal available:
- A single event can identify both sides, i.e. source and destination. A download links the cloud source to the device; an upload links the device to the destination.
- A shared identifier is next-best. Events with the same application-assigned object ID clearly refer to the same file, within that application.
- Matching content can connect renamed files, but only within the same location, or an explicitly grouped set of applications. This guards against linking two unrelated copies of a common template.
- Name, location, and time can support a connection when nothing stronger is available, but only when the events happen in the same location and close together in time.
While a more complete picture seems to inherently increase the value of the visualisation, a graph that looks complete isn’t useful if some of its connections are guesses. In my opening scenario, the download and the upload were both visible, but the ID, hash, and filename no longer matched by the time the file resurfaced. If you prioritise forcing a connection (and loosen the matching rules to be able to do so) you introduce false links.
For this reason there are things Netskope One Data Lineage deliberately won’t infer:
- Matching content alone isn’t proof of movement. Two people can independently send the same template or report (a hash confirms identical content, not that the file passed between them).
- Uncertain links stay marked as uncertain. Related activity may surface as a possible connection, but it’s kept visually distinct from proven lineage, so the investigator makes the final call.
Covering the blindspot from three vantage points
In our scenario, the issue is that the evidence connecting the two events was never captured in the first place, because the rename and the edit happened on a laptop with nothing crossing the network during either step. No network-based vantage point observed them, so there’s nothing in the data to reason from.
Covering that blind spot means extending observation to a vantage point that was actually present when it happened, the endpoint.
Netskope builds lineage from three complementary and additive sources. Inline sees network activity, files moving between users, applications, and destinations. API connectors see activity inside SaaS applications, (things like edits, shares, moves, and permission changes). The endpoint sees device activity: files being created, edited, renamed, copied, deleted, or transferred via USB, Bluetooth, or network shares.
Endpoint events capture what happens to a file on the device itself, how it arrived, what happened to it, and how it left. Downloads, local creation, edits, renames, copies, deletions, and transfers through browsers, USB drives, network shares, or Bluetooth all get recorded. Each event also logs the user, location, and process involved, tying together network events that would otherwise look separate.
Applied to the opening scenario, inline tools see the download and the upload but can’t link them, since both the name and the content changed in between. And so the endpoint covers that blind spot, because it records the renaming and the edit directly, creating a continuous, proven chain.
Why local edits don’t get their own graph nodes
The graph below again shows where data moved and the timeline shows what happened at each location. Creating, copying, uploading, downloading, or sending a file creates a new graph node. Editing or renaming that same file doesn’t. It stays on that node’s timeline instead. This keeps routine activity from cluttering the graph while preserving the full sequence for investigation.
Endpoint events are currently available in beta for incident-triggered lineage. For more on how lineage fits into a broader data security strategy, see Data Lineage: Digital Breadcrumb Trails for Data Security.
To learn more about how Netskope can help, set up a demo or discussion with our experts.
