mike1813
commented
1 year ago Threat patterns reviewed.
There are several cases where the 'controls' relationship is redundant and merely complicates the pattern unnecessarily, in which the controls link has been removed.
There are cases where the 'controls' relationship is used to specify that a client-process relationship is/isn't from a transparent proxy, and in a few cases the pattern would also pick up or exclude OAuth-style authentication services. Here the Service-controls-Client is now replaced by Client-proxyAuthN-Service.
The review also revealed one case of Process-controls-Process where the pattern is wrong (see #61).
If one Process acting as a Client initiates communication with another acting as a Service, either for data transfer (Client-uses-Service) or for client authentication/authorization (Client-usesForAuth-Service), then a relationship asset is (a ClientChannel) inferred to exist. This is subject to various threats covering ways in which the Client or Service could be impersonated or accessed without authorization, and to threats covering the effects on the Client should the Service be compromised or vice versa.
These threats don't normally refer to the 'uses' or 'usesForAuth' relationship. Instead their matching patterns include the ClientChannel, whose relationships to the two communicating processes define which process is acting as a Client and which a Service.
However, some Services do not authenticate the Client. This happens if the Service delegates to a separate OAuth/OIDC service, or if the Service is a transparent proxy that forwards Client authentication credentials to a back-end service, leaving it to handle authentication. In either case, this is captured in system models by a 'controls' relationship to the Service from the service handling authentication. In such cases, an extra threat is used to model the dependence of the Client-Service relationship on the relationship of the Client to the process handling authentication.
There are also some threats modelling the ways in which requests are forwarded by proxies (before or after authentication). These degrade trustworthiness attributes in ClientChannels to back-end services, indicating that untrustworthy agents can send requests. These are then used as threat causes in further threats modelling attacker access to the back-end service host, in cases involving the use of back doors or where the service is a remote access service.
To make this work, these threats have matching patterns containing links whose presence indicates that there is a separate authenticator. This is used in threat patterns:
In the first case the prohibited link is one inferred from the presence of a second controlling service. Its link type depends on whether the Service is forwarding credentials as a transparent proxy (so the controlling service is also one used by the proxy), or redirecting clients to a separate authenticator.
However, threats modelling exploitation of forwarding or redirection often refer to the original 'controls' link. This means those threats are not sensitive to the scenario, and may sometimes apply when they should not (or vice versa). This will become more of a problem with the introduction of an OIDC Authorization Flow model, as this will lead to more distinct cases that could give rise to false alarms.