Every type of visualisation or graph will contain graphic elements whose rendering is modified by variables. A circle, for example, has several variables, such as position, radius, fill and opacity, that affect the final visual outcome. One can think of these variables as controls that can be adjusted depending on a certain input. This way of thinking allows the creation of many combinations of visual elements.
For example, directed graphs (in the mathematical, not the visual context. So a graph in this context is defined as a network of vertices or nodes connected by (directed or un-directed) edges) are used heavily in security models because of their ability to represent complex network relationships between entities. These graphs consist of edges and vertices, visually often represented by the two essential elements of a line and a circle. Feedback on early TREsPASS explorations found that it is most visually effective to parameterise a maximum of three variables simultaneously. A line can be defined, for example, by its thickness, colour, and opacity. By applying a mapping from a derived security vocabulary (e.g. difficulty, time, and probability) to the visual vocabulary, it is possible to begin building the framework for visualisation. Thickness can be mapped to indicate difficulty, colour to indicate time, and opacity to indicate probability. Note that certain properties are more suitable for mapping to certain visual parameters. It does not make sense, for example, to map time to opacity because a lower opacity implies a weak link, whereas time only indicates the length to complete. More examples can be found in Bertin. All of these parameters combined lead to a very rich, yet simple visualisation that leaves no visual ‘stone’ un-turned. One can apply a similar approach to visualise information in a node.
There are often cases where the number of parameters that need to be visualised far outnumber the sensible variants to a particular visual element. In other cases, it may not be known what the total number of parameters is (as they may shift depending on user input). An example might be an entity, such as an attacker profile, for which the user has the freedom to pick and choose the parameters to assign. In such cases, it makes sense to develop a language that is extensible. An approach in which visual elements are stacked provides a solution to the problem, as it can be applied to a wide range of parameters.
First, it is important to establish a unified legend, where, for example, line thickness and colour are used to indicate levels of risk. Quite often parameters in security models can be mapped to a scale that ranges from low to high risk. This means that a visual element becomes a generalised module for visualising, allowing for adaptability and re-usability.
Hereunder a series of examples how the various parameters can be combined in various constellations.