Remote Access Modelling Errors are Unclear

[mike1813]

The remote access model was added some time ago (w.e.f. v5e2-4-15). It includes several modelling error threats to detect:

• cases where an interactive process has no (local or remote) interactive user
• cases where data is sent to a relay but not forwarded

In both cases, the threat patterns detect a deficiency in the output of complex construction sequences, and in both cases there are several ways the deficiency may have been caused. For example, absence of an interactive user could mean that:

• the user was accidentally omitted from the model
• the user was included, but their interaction with the process was not
• the interaction should be remote, and no remote access client was included
• the communication chain is incomplete between a remote access client and the process
• the communication chain would require graphical access from a (text only) remote terminal or command shell
• the process is not interactive, and should not be of the chosen (interactive) type

The only way to fix this is to replace each modelling error threat with several, each of which detects a specific cause. However, with the current remote access inference chain this cannot be done, because errors can mask each other.

For example, suppose the model says the user is accessing (say) a Web Browser on one host via a remote desktop on another, but they access the second host using a remote terminal login from a third host. The inference patterns detecting remote access will not work because text interaction is insufficient to access a graphical application like a browser. No chain of links from the remote terminal to the browser is generated, and hence no relationship from the user to the browser is generated.

The problem is that we can't then create a modelling error threat pattern encompassing both the cause (use of a remote terminal instead of a graphical remote access client), and the effect (inability of the user to access the browser). We can detect there is no user, but not which user was supposed to have access, nor why that isn't possible.

The only way to fix this is by a further refinement of the remote access construction sequences so they create relationships between the remote access clients and services and the target process, and separately infer what can be accessed interactively by the user. That way we will be able to create modelling error threats for a browser with no user where there is or is not such a remote access chain, and so inform the user if the problem is in the way such a chain was defined, versus having no chain or no user.

[mike1813]

It would make sense to fix this along with other changes to improve the model of user interactions with data, see issue #107.

[mike1813]

Not done as part of the #107 fixes.