mike1813
commented
11 months ago This change is sensible because it reduces the amount of repetition and interdependency between distant parts of the construction sequence. However, it leads to a big increase in the number of patterns unless some of the inferred relationships are organised in a better inheritance hierarchy. Specifically:
- current 'proxyAuthN' is used in threats for adjacent relationships between transparent proxies and back-end services, but also as construction state between non-adjacent processes in a transparent proxy chain.
- current 'usesViaAuthenticatingProxy' is often used in situations where uses or 'usesViaProxy' (the corresponding relationship for transparent proxies) would also be valid, or vice versa.
- current 'usesAsProxy' is often used in situations where uses or 'proxyAuthN' (the corresponding relationship for transparent proxies) would also be valid, or vice versa.
Note that 'proxyAuthN' is already a subtype of 'noAuthN', because when used between a client and an adjacent service, it means there is no mutual authentication as that is handled by some other service or client.
The best solution is to introduce a pair of relationship type inheritance trees.
- make 'usesViaProxy' a base type, replacing it by a new 'usesViaTransparentProxy' which (along with 'usesViaAuthenticatingProxy') should be subtypes of 'usesViaProxy'
- make 'usesAsProxy' a base type, replacing it by a new 'usesAsAuthenticatingProxy' which should be a subtype
- introduce a new 'usesAsTransparentProxy' as a further subtype of 'usesAsProxy'
- make 'proxyAuthN' a subtype of 'usesAsTransparentProxy' as well as of 'noAuthN'.
Then change construction and threat patterns as follows:
- where duplicate construction patterns are needed because their matching patterns could involve transparent or authenticating proxies, replace them with one pattern using base types 'usesViaProxy' or 'usesAsProxy'
- where transparent proxy relationships should not involve mutual authentication, construct 'proxyAuthN' as now, but where that depends on other factors (e.g., between a client and first proxy) use 'usesAsTransparentProxy'
- where 'usesAsTransparentProxy' is used, add 'proxyAuthN' in a later construction pattern if those other factors are present
- where duplicate threats are needed because the threat applies to transparent or authenticating proxies, use the base types to remove the duplication.
This should mean some of these relationships are no longer used in threats and could be removed as construction state at the end of validation.
The patterns for remote access to a host device using terminal or remote desktop clients must necessarily handled cases where access to a remote login or remote desktop service is mediated by a proxy.
However, for various reasons the remote access construction pattern sequence comes before the proxy inference patterns. For this reason, the remote access sequence includes a lot of patterns that infer the possibility of remote access via a proxy.
This is daft. The possibility of remote access via a proxy is precisely what the proxy inference patterns do. They should be processed first, creating indirect access links that should then be used in the remote access patterns.