When a marking is applied to a resource (dataset, data connection, project, etc.) all the child resources inherit the security marking automatically. Conversely, when the propagation of a marking is stopped downstream resources become visible.
It would be very useful if in one-click users/admins could map and identify:
the parent resource(s) where the marking is applied
the resource(s) where stop propagating takes place
the data connections were exports of marked data for a given security marking is enabled
markings that are combined and the respective projects
This information in the Access Graph App would help monitoring and improve marking auditability. The benefits are:
1- Often users protect raw datasets and not the data sources. In turn, any editor in the project can create a batch sync and bypass the marking. This would provide us a tool to quickly identify these scenarios.
2-3. Enable the different marking membership groups to keep track where the marking has been applied, removed, and marked data is being exported in data connections without having to unfold large data lineages and finding needles in a haystack. In addition, with the current setup there’s room for a scenario wherein one member of the remove marking group approves a security change in a PR without others knowing nor being able to easily spot it.
4- With the project constrains it is possible to block joining datasets with certain markings. This is typically used to prevent users from accidentally joining data that should not be joined and is relevant in situations where users might need access to multiple markings though specific combinations of marked data should not be allowed. The above hinges on the fact that the project is well-orchestrated and users know in advance that specific markings cannot be combined, and add the project constrains before any work takes place. However, a scenario where engineers unawarely join marked data and later on officers realize there’s an issue is equally likely. When amendments are needed, it would be great to trace which markings are being combined and in which projects.
This feature would also cover for the fact that it is only possible to prevent combining different marked data at a project level - not at platform level. With this feature, users can easily trace markings and understand whether a breach might be inadvertently taking place.
Hope the diagrams help and there’s enough food-for-thought.
Your drawings are excellent. The view where you can see datasets within the boundaries of projects would be super nice.
A lot of this functionality is available in monocle today where you can expand a big lineage and see which resources have markings. This allows you to see where a marking is introduced and if it has been removed.
You mention that it is painful to expand a monocle graph to find the needle in a haystack. I commiserate with you, but I am not seeing a better solution. How would we show you all the resources and where the marking has been added/removed without a big graph?
Yes, the platform provides the tools to set up projects and resources in the desired way if everyone is diligent in setting them up. However we do not provide good tooling in auditing that the platform continues to conform to the desired setup. What auditing functionality is highest on your wish list?
I wanted to clarify that this isn’t entirely accurate. Monocle is limited to 500 items, and beyond that, users need to manually unfold individual datasets in the data lineage. This can become quite cumbersome, especially in large projects with numerous central data assets across the organization.
I agree with this perspective. That said, the issue you’re raising is somewhat similar to how we display all of a user’s projects in the access graph. Personally, I’d intuitively look for this kind of information there, as the access graph feels more interactive and user-friendly. However, it’s also clear that this view needs to be complemented by the details available in the project catalog or portfolio tabs.
All of the requirements outlined above are particularly relevant in situations where: 1) markings need to be decommissioned, and 2) application owners are unaware of where a marking was removed and have forgotten to set the “re-approval” flag in the code repositories, 3) the lifecycle of sensitive information - and its derivatives - needs to be audited and monitored for legal/compliance reasons. Unfortunately, in the absence of native support, people often resort to tracking this information manually in Excel sheets just to monitor their markings. In some cases, members of the removal marking group were unaware that certain data assets had been unmarked because they did not communicate among themselves. This lack of visibility leads to confusion, and a urge to build and automate this information outside of the Foundry platform.
