Client-Service Relationship Bug

Trust relationships between processes are represented by inferred AuthChannel assets. Where the service authenticates the client (if it chooses to do so), the ClientChannel subclass is used.

The construction sequence first creates ClientChannels where there is direct client-service communition. Client-service network paths are then found and represented by inferred ServiceChannel assets, representing the means of communication (which may be compromised, so must exist as a target for certain threats). Then ClientChannels are created where a client communicates with a service indirectly, via intermediaries, and an authentication or access token is passed through so the service can decide whether to accept the (indirect) connection. No associated ServiceChannel assets are created in that case. Finally, AuthChannels are created where data flows between the client and service, and the data on the service end is protected by keys from a vault, meaning that access tokens (but not authentication tokens) must be exchanged. No ServiceChannel assets are created in this case either.

For this to work, three types of relationship links are used:

Those representing direct client-service connections, subtypes of 'Client-accessesService-Service'.
Those representing possible indirect authentication relationships, represented by subtypes of 'usesIndirectly', and created iteratively from Client-accessesService-Service-accessesService-Service patterns where the second service controls client access.
An 'indirectAuthZ' link representing the use of keys from a common OAuth-style token service, and hence the use of an access token passed from the (authorized) client enabling access to keys by the service.

The three construction patterns look for these types of relationships. However, there are some complications for ClientChannel creation. Firstly, a direct 'Client-accessesService-Service' link doesn't always mean there is a direct client-service connection. In some situations, a reverse proxy is inferred to exist between the Client and Service, e.g., if the Service is hosted by a DataCentre and access is via an inferred K8S IngressProxy. Secondly, usesIndirectly links represent all possible client-service communications via chains of intermediaries, which may be reverse proxies, an authorization deputy, or just any service that receives requests from clients and uses other services. We need a restriction to cases where there is a need for client-service communication.

In practice, therefore:

The first ClientChannel construction pattern looks for a direct 'Client-accessesService-Service' link where there is no inferred 'Client-usesIndirectly-Service' link (direct communication between the Client and Service).
The second ClientChannel construction pattern looks for an inferred 'Client-usesIndirectly-Service' link and a 'Client-accessesService-Service' link.

The second pattern is triggered if either:

there is an asserted 'Client-accessesService-Service', but access is via an inferred reverse proxy, e.g., at a DataCentre, causing there to also be an indirect 'Client-usesIndirectly-Service' link
there is a potential indirect communication path represented by a 'Client-usesIndirectly-Service' link, and there is an asserted 'Client-accessesService-Service'
there is a potential indirect communication path represented by a 'Client-usesIndirectly-Service' link, and there is an inferred 'Client-accessesService-Service' representing a need to communicate with an onboard IoT service, or a OAuth-style token service
there is a potential indirect communication path represented by a 'Client-usesIndirectly-Service' link, and there is an inferred 'Client-accessesService-Service' added because there is a data flow between the Client and Service.

Unfortunately, because 'usesIndirectly' covers three separate situations, this doesn't always produce the desired outcome. It is possible for there to be a direct Client-uses-Service relationship, where the client also uses a second service that (directly or indirectly) uses the first. In this situation, a Client-usesIndirectly-Service relationship will be inferred, suppressing creation of a direct ClientChannel. Subsequently, the Client-Service network path (ServiceChannel) inference does not occur, and the whole relationship gets missed.

To fix this, a refinement in the relationship type hierarchy is needed, such that 'Client-usesIndirectly-Service' does not inhibit creation of a direct ClientChannel (and ServiceChannel), nor lead to an indirect ClientChannel, but does still create the possibility of an AuthChannel if a token exchange is needed to enable an encrypted data flow.

Spyderisk / domain-network

Client-Service Relationship Bug #128