Bug in CC.L.CSHSAC.1

[mike1813]

Threat CC.L.CSHSAC.1 represents the effect on the client-service trust relationship if the service has been compromised (Loss of Service TW). The pattern correctly selects only relationships on which the service can be accessed in the context in which it is compromised. This ensures that if a service runs on a mobile devices which is compromised in a public space, this only affects relationships with clients accessing the service when the service host is in that space, and not other clients that only have access in other spaces.

However, this means the pattern only detects direct client-service relationships. Clearly, an indirect relationship, in which a client accesses the service via a transparent proxy, should also be affected. In future, this would also apply to authorization relationships, where the client passes tokens to an intermediary which uses them to access the service (one of the envisaged extensions to the OAuth/OIDC model).

It is arguable that any compromise will persist, so a service compromised in a public space would still be compromised when its host was taken to a private space. However, at least for now we don't want to make this assumption.

Given that, the simplest solution is to add indirect client-service relationships to the threat pattern as an optional non-unique nodes, to which the threat effect also applies.

[mike1813]

Further investigation reveals this change may not be necessary. Threats caused by low Service TW are:

• CC.AX.CCCS.1.3: access to compromised service prevented
• DF.Auth.CCDF-fSC.1.3: malicious alteration of data flowing through a compromised intermediary service to or via its client
• DF.Auth.CCDFFS.1.3: malicious alteration of data flowing from a compromised service to or via its client
• DF.C.CCDFTS.1.3: leaking of data flowing to a compromised service from or via its client
• DF.C.CCDFC-tS.1.3: leaking of data flowing through a compromised intermediary service from or via its client

These affect all client channels, but can be limited to direct channels since loss of accessibility (AX) propagates via CC.AX.CCCvCCS.0, and threats to data flows should apply at the point where the data leaves/reaches the compromised service.

There is still an issue because insider attack causing Loss of Service TW (CC.L.CSCCHuoSt.1) only applies if the client is not managed by the same insider as the service. Such threats may affect indirect channels but not direct channels. However, there will be a point in any transparent proxy chain where the proxy client is managed by someone else, so this threat will still affect at least one direct connection in the chain.

This is not necessarily true for employer-induced insider attack (CC.L.CSCCHuSt.1), which only applies if the client has a different operator (not the malicious employer). However, in that case different proxies in the chain may have different managers, so it is possible that the boundary proxy will not be affected.

A solution is to restrict CC.L.CSCCHuoSt.1 and CC.L.CSCCHuSt.1 to direct connections, and add a variant of CC.L.CSCCHuSt.1 that applies if the service is accessed via a proxy and the ultimate client has a different manager/operator.

[mike1813]

This is a tricky one. Where a client accesses a service via at least one transparent proxy, there will be multiple direct connections per indirect connection. To minimise the number of threats, we should ideally restrict threats to end-to-end connections where possible.

To do that, we should make the change in CC.L.CSHSAC.1, leave CC.L.CSCCHuoSt.1 and CC.L.CSCCHuSt.1 as they are, and make threats over indirect connections depend only on the end-to-end connection. However, this isn't clear cut, because sometiems the same direct connection is used by multiple end-to-end relationships.

On balance, making threats depend only on direct connections seems the best solution because it improves transparency. If threats depended on end-to-end connections (relying on propagation from direct connections up to the end-to-end connection) users will see threats caused by a compromised service when really the compromise may be at some intermediate transparent proxy.

[mike1813]

Analysed in a broader context in #68, and concluded that no change is needed to CC.L.CSHSAC.1. Other changes are needed, but are now covered by #68, so this issue can be closed.

[mike1813]

Turns out this conclusion is not quite correct. There is a threat caused by Service TW that should affect end-to-end channels, including the threat of denial of service which could clearly target an indirect channel independently of the direct channels. The easiest way to see this is by considering that every direct channel may be used by more than one indirect channel.

Conclusion:

• CC.L.CSHSAC.1 should after all include the optional indirect channels affected by access to a compromised service.
• CC.L.CSCCHuoSt.1 and CC.L.CSCCHuSt.1 should affect indirect or direct channels, and this may lead to direct channels being unaffected even though the indirect channel is affected.