Bug in threat for service access using a stolen device

[mike1813]

The threat for this is CC.AuC.CACHLSS.2. At present, the only control strategy is 'continous authentication'.

This is incorrect. A stolen device would suffice if the credentials needed are stored in the client configuration or in a credential store. This would not be true if:

• The client uses a strong password supplied by the legitimate user, not stored on the device.
• The client uses a stored credential protected by a password from the legitimate user that is provided at the point of use.
• The client uses a second authentication factor.
• The malicious user of the client device can be detected via biometrics, as in 'continous authentication'.

Fixing this is not just a case of adding some control strategies (although that would suffice in some cases). There is also a need to overhaul and possibly refactor some control strategies so the provision of a password by the legitimate user only appears where it should appear.

[mike1813]

Ideally, this would be fixed by altering the threat paths leading from device theft, so it becomes unnecessary to distinguish between control of a (client) process due to device theft and control of a process by other means.

If successful, that would mean CC.AuC.CACHLSS.2 could be removed, leaving existing control strategies able to block access by the usual means (not requiring theft of the device).

[mike1813]

Actually, it turns out that the threat for connection to a service from a hacked client (CC.AuC.CACHcLSS.1) suffers from the same problem. It doesn't consider whether the hacker would have access to credentials.

Presumably this wasn't fixed (in either threat) because the control strategies don't support that.