Visualizing Privilege Through Node Graphs
The idea was both simple and complex: Visualize "TruePrivilege." TruePrivilege is the actual, effective privilege level achievable via both directly and indirectly granted privileges and permissions, across all linked identity domains. The key differentiator here is that most companies track direct privileges: those directly assigned to or inherited by an account through rules, policies, and other deliberate permission-granting. Indirect privileges are privileges that can be achieved without someone granting them in a policy, or perhaps through a misconfiguration. A very simple example would be a user that only has basic permissions on a system, but is allowed to execute certain scripts that happen to run with very high permissions, allowing the user to run certain processes, or even inject commands, at a higher privilege level than they are supposed to have.
And we wanted to map it across domains.
I'm not going to go in depth on the details and decisions made here. I did a fairly detailed walkthrough under the Attack Path Analysis portfolio item. What I will do is address basic steps and issues.
We started with Atomic design, so I'll show bits of that. That should give you an idea of how the design system finally worked itself out. This was separate from the BeyondTrust already-established desing system for the rest of the products, though I did work extensively with the design system team in componentizing certain items, and using them as a sort of collaborative QA for my design system work.
At the same time we worked on a number of different display options (hence why you will see 2 slightly different looking design systems here. We used a placeholder while simultaneously building the real thing). Those options included:
map filtering
node grouping for scaleability
Path simplification to reduce visual cognitive overload
Path subject/focus pivoting
Toolbars and side bars to accomplish things that the graph itself could not
floating panels and sidebars to add context to individual nodes
When the design system had mostly fallen into place, and basic and future interactivity had been defined, the more difficult question came up: What about scalability? These maps can get quite large, quite quickly, and while there were certain features design to assist, they only helped up to a certain point. So what to do beyond that?
Atomic Design - Building a New Design Language from Scratch
We started with what we needed the nodes and edges to represent: Accounts, identities, endpoints, policies, groups, etc., etc. and created icons for those, then we went on to design the nodes, define states, shapes, and define edges and their states.
A few of the stages of the design covering icons, shapes, states, colors, and the node labels.
It's a carousel and you can click to enlarge
Node and Path filtering
We knew that the graphs could get complicated quickly. I figured that, at least initially, users coming directly to the page would have 2 basic use cases:
Exploration: They weren't looking for some specific node or violation, they simply wanted to explore and answer questions like "What are the critical paths to privilege in my organization?"
They were looking for something specific. They knew what particular Identity, account, or asset they wanted to examine, and they wanted answers to questions such as: "Who in the organization can access this specific asset that contains secret or private business-critical information?" or "What assets can this account access that I didn't know about, and at what privilege level?"
We knew 2 other things right at the start: Users would be coming to this page from other areas of the product, and they would expect the filtered, pertinent view that followed their workflow and mental models of how this would work (iow, we needed to have the filters so that links from other pages could take the user directly to a pre-filtered view), and secondly, that users would ultimately what to be able to see things like choke points - a single node or path that many other paths pass through that, when it's issues are remediated, fixes a large number of critical or high privileged escalation paths. That is information that is very difficult to really see in tables, but becomes very obvious when viewed visually. We weren't quite there yet, but it was in the back of our minds, and we knew that the best way to show these crucial nodes and edges would be through graphs and filtering.
You gotta have panels!
We knew that we need4ed panels. And we ultimately figured that we needed multiple types:
A floating panel right on the graph itself, that had basic privilege severity and other issues, that could be accessed through something like right-clicking. Just a quick and dirty way to get the most context.
A detailed side panel. Something that not only showed more details about the node, but about the paths that passed through the nodee, and specifically WHERE in the path the security violation took place.
Identifying a path that allows a low or moderately privileged account to ultimately have high or the highest levels of privilege on an endpoint is one thing, but there could be many hops along that path. We had to show WHERE that path broke down. Where was that weakest link? Otherwise remediation is just a guessing game.
Again, a carousel, and you can click on an image to enlarge.
Node Grouping
Showing all nodes in a graph becomes near impossible at scale when there are thousands of nodes. Filtering aside, we can use grouping to simplify these paths as well. If a node, for example, links to over X amount (we picked 20 initially) of the same type of nodes (for example, a group might link to 100+ accounts), we can group these together by default, and then allow the user to expand and collapse each group as they desire. It reduces noise, complexity, and overload.
Simplifying paths
OK, that's great, but can we do the same thing for paths? Of course! There may be 5 different escalation paths to get from point A to point Z. We can collapse those into a single "summary" path, and then expand that at will via the right click menu or even a checkbox right on the node graph canvas.
Scaling Experiments
These were all noble gestures as far as attempting to solve scaling issues, and they were great when looking at smaller data sets. But still, they aren't enough when you're looking at thousands of nodes. For that we need to do some more scaling. These were some experiments that we were going through to figure out how to alleviate the problem….
First,. we played with different node types (spoiler: they didn't scale well):
From Macro to Micro, intuitively
As soon as we all finished telling each other "I told you so" we examined different ways of scaling. We talked about the idea of the mental model of "just being able to zoom in on something of interest" and from there I decided that the physical UI should just fit that mental model. Typically you just zoom in and out (like on google maps). It works, but you can get lost, and you still want to really narrow the data set that you're working with, so we needed more than just zooming.
Also with google, once you zoom in, you can "search in this area." It works to varying degrees, but we worked on the same concept - the ability to zoom in on a certain section or path, select it, and then isolate that path and all of it's branches moving away from the subject, or toward an ending node (in this case the subject, or center of the graph was a user account). This seemed to work well . When combined with filtering, grouping, and path simplifying, it really made larger scale graphs MUCH easier and more pain-free to handle and manipulate and actually investigate!
The Toolbar
Our last little experiment (did not ship) was the toolbar for handling various functions on the canvas. One issue that I discovered was that from point A to point Z there could be 20 different paths. Most of those paths over lap, and are just varying degrees from each other. For. example:
Path 1: A > B > C > D > E > Z
Path 2: A > B > C > Q > U > Z
Path 3: A > B > H > J > E > Z
It's easy to click on a map and select a single edge, between 2 nodes. But how do you select paths? My answer was a path selector that would list all of those paths out. Something that you could potentially filter on, and something where you could hover over a specific path name, and that path would be hilighted in the node graph in real time. Then, once you found the right path, click on it and start your investigation.
But people wanted to be able to see the canvas in a top-down (vertical) configuration, as well as a right to left (horizontal) configuration. And there were other features as well. Rather than having lots of icons and check boxes on the screen, why not use what Photoshop, Miro, and Figma use: A tool bar that lives on the canvas?
