Bug in data flow contextualisation patterns

Construction patterns DFTPACS+fTI and DFFPACS+fFI detect, respectively, Data Flows to or from a Process, where the connection is available in a context. They add flowsFromIn and flowsToIn links indicating that the data can flow in that context/space.

This depends on the location(s) in which the Process is connected to a network subnet over which communication of the data can take place, determined by previous patterns CXPCPNC+cIC and SXPCPNC+cIS.

There are two problems with the current implementation:

Patterns DFTPACS+fTI and DFFPACS+fFI are flawed, because they do not include DataFlow-flowsVia-DataStep links. They could create flowsToIn or flowsFromIn relationships when in fact it is some other data that is able to flow.
Patterns CXPCPNC+cIC and SXPCPNC+cIS determine contexts in which, respectively, a client or service is connected to a subnet that carries the client-service connection, over which data may therefore be exchanged. But this doesn't mean data can always be exchanged between the two, because it only considers whether the connection can be made at one end.

What should happen is the following:

Determine in what contexts a service can receive messages on a service channel (i.e. network path) from a client.
Determine in what contexts a client can send messages on a service channel to a service.
For each client context, determine whether there are any service contexts where the service cannot receive the messages.

Steps (1) and (2) are found by patterns SSCLS+aTS and CSCLS+aFC, respectively, but at present these are not checked until later. Some adjustment of the sequencing is required to get this working properly.

The client can only exchange data with the service in a context where it can access at least one service channel representing a network path to the service. The service can only exchange data with the client in a context where it can access at least one service channel from the client. If data flows between the two, flowsToIn and flowsFromIn relationships can be added to indicate that data flow is possible in those contexts. This records the contexts where the flowing data is at risk should an attacker gain access to the corresponding process, and is used in data flow threats like DF.C.AC-iDFVTC.2.6 (data flow to a client leaks if the attacker controls the client in a context, if and only if the data flowsToIn that client context).

Step (3) is new. It covers the possibility that the client is in a location where it can exchange data with the service (so there may be a flowsToIn or flowsFromIn relationship), but the service could be in a location where it cannot exchange data. This means the client may need to wait until it can connect to the service to send or receive data. If an attacker takes control of the client in that context, the data would still be exposed to risk because data exchange would be possible in that context at least some of the time. However, any data that should be exchanged may need to be cached by the sender in that context while waiting for the service to become available.

New relationship types are required to capture this situation. The new relationships won't be used in threats, but only to work out when data may need to be cached. The new relationships could be called something like flowToCachedIn and flowFromCachedIn. The best way to find them may be by first adding relationships from a client channel to a context called something like mayBeDisconnectedIn, derived from an analysis of service channel accessibility on both client and server sides.

Conclusion. The following changes are needed:

[x] The context creation construction pattern sequence (81xx) should end with pattern HmNCPAC+p, and not include data exchange and data flow contextualisation patterns CXPCPNC+cIC, SXPCPNC+cIS, DFTPACS+fTI and DFFPACS+fFI.
[x] The client-service communication contextualisation sequence (83xx) should be moved up (to 82xx) so it follows the context creation sequence, but leaving out stolen client device reconnection patterns CSCLS-ii+PNC and CSCLS+ii+PNC.
[x] This sequence should be extended, adding relationships for interrupted service access from client contexts to channels if the client cannot connect or the service may be inaccessible in some service context.
[x] The sequence for inferring the presence of cached data should follow this, making use of this new relationship to address issue #109.
[x] A new sequence should be added after this, starting with the stolen client device reconnection patterns CSCLS-ii+PNC and CSCLS+ii+PNC, and then adding links from data flows to all contexts where they may be compromised.

Bugs in patterns not replaced should be fixed along the way, including those mentioned here and in issue #109.

Spyderisk / domain-network

Bug in data flow contextualisation patterns #121