These threats are both 'surfacing' threats (to different degrees) and both cause a loss of control at a device. However,
H.M.HsAC.0 causes the behaviour domain#LocalLossOfControl, when it should be domain#LossOfControl
Co.M.CoPDS.0 causes the behaviour domain#LossOfControl, when it should be domain#LocalLossOfControl
The behaviour domain#LossOfControl is associated with the TWA domain#LocalControl which does not cause any threats. It is used as the 'visible' manifestation of loss of control in a host. It is supposed to reflect the worst-case loss of control in any context asset associated with the host. This provides an outcome for which users can specify an impact level, if needed (which isn't likely as hosts are 'secondary' assets, but it should nevertheless be possible without delving into inferred context assets).
The real loss of control is represented by domain#LocalLossOfControl, associated with TWA domain#Control which does cause threats.
Threat H.M.HsAC.0 is caused by domain#LocalLossOfControl at a 'sufficient' node of type access context, so its likelihood matches the worst-case loss of control in any context. It is a pure 'surfacing' threat, whose only purpose is to set the visible domain#LossOfControl such that it reflects the worst-case context. This means it should cause domain#LossOfControl, not domain#LocalLossOfControl.
Threat Co.M.CoPDS.0 is also in some respects providing a 'surfacing' capability by propagating between an issue with control inputs at an IoT actuator device and a loss of control in the device. However, it is not a 'pure' surfacing threat, because forged control input should also have effects. This threat should therefore cause domain#LocalLossOfControl, not domain#LossOfControl. This is then surfaced by H.M.HsAC.0, and provides one case where users may want to specify the impact level (since an IoT device is not a 'secondary' asset).
The way this is supposed to work is summarised by the following diagram:
mike1813
commented
6 months ago
These threats are both 'surfacing' threats (to different degrees) and both cause a loss of control at a device. However,
domain#LocalLossOfControl, when it should bedomain#LossOfControldomain#LossOfControl, when it should bedomain#LocalLossOfControlThe behaviour
domain#LossOfControlis associated with the TWAdomain#LocalControlwhich does not cause any threats. It is used as the 'visible' manifestation of loss of control in a host. It is supposed to reflect the worst-case loss of control in any context asset associated with the host. This provides an outcome for which users can specify an impact level, if needed (which isn't likely as hosts are 'secondary' assets, but it should nevertheless be possible without delving into inferred context assets).The real loss of control is represented by
domain#LocalLossOfControl, associated with TWAdomain#Controlwhich does cause threats.Threat H.M.HsAC.0 is caused by
domain#LocalLossOfControlat a 'sufficient' node of type access context, so its likelihood matches the worst-case loss of control in any context. It is a pure 'surfacing' threat, whose only purpose is to set the visibledomain#LossOfControlsuch that it reflects the worst-case context. This means it should causedomain#LossOfControl, notdomain#LocalLossOfControl.Threat Co.M.CoPDS.0 is also in some respects providing a 'surfacing' capability by propagating between an issue with control inputs at an IoT actuator device and a loss of control in the device. However, it is not a 'pure' surfacing threat, because forged control input should also have effects. This threat should therefore cause
domain#LocalLossOfControl, notdomain#LossOfControl. This is then surfaced by H.M.HsAC.0, and provides one case where users may want to specify the impact level (since an IoT device is not a 'secondary' asset).The way this is supposed to work is summarised by the following diagram: