Control applicability bugs

[mike1813]

In debugging issues with data flow threats, it became apparent that some are missed or found inappropriately because controls are missing. In many cases this is due to a bug in the CASetting, which specifies the control cannot be asserted when it should be possible.

Action: review all CASettings and identify potential errors, which should be listed below:

• [x] AccessControl: should be assertible at every InteractiveHost or ShellHost.
• [x] ContinuousAuthN: should be assertible at a workstation.
• [x] DeviceCertification: may need be assertible at a Smartwatch, and at neither or both of Tablet and Smartphone assets.
• [x] DisableNetworkProvision: should be assertible at a CoreRouter, but not a Pod or Container.
• [x] FormalVerification: should only apply to simple/trivial hosts plus Container, and simple/trivial processes plus TextEditor and WebApp.
• [x] HostEncryption: may need to be non-assertible at a HealthSensor (same as a regular Sensor).
• [x] IgnoreInteractiveProcess: should be deleted - it no longer addresses any modelling error threat.
• [x] LoadMonitoring: should no longer apply to any process.
• [x] LowPriority: should be assertible at any non-trivial Process.
• [x] OneTimeKeyVerifier: should be assertible at any ServiceProxy.
• [x] OutOfBandKeyVerifier: should be assertible at any ServiceProxy.
• [x] PasswordReset: should be assertible at any ServiceProxy.
• [x] ProcessMonitoring: should be assertible at any ServiceProxy or RemoteAccessService.
• [x] RemoteWiping: may need to be assertible at Notebook and MobileClient.
• [x] SecureBIOS: should be assertible at a MobileClient (meaning, Notebook, Tablet or Smartphone).
• [x] SecureExecution: should be assertible at a DataService.
• [x] SharedKeyVerifier: should be assertible at a Container.
• [x] SuspendVulnerableService: should be assertible at a WebClient, which is an HTTP(S) client, but may also be a service.
• [x] XSSSanitisation: should apply only to web-accessible services, i.e., it should be assertible at an EmailService or ServiceProxy, but not to any InteractiveProcess, ConsoleProcess, TextEditor or WebApp.

Action: investigate whether these may be inappropriate, and make adjustments as necessary.

[mike1813]

Some changes to the above.

• [x] DisableNetworkProvision: should be assertible at a Container.
• [x] LowPriority: surely should not be assertible at Interactive Processes including Editor processes. NOT DONE - this can be dropped here, and addressed under a separate issue (see below).
• [x] XSSSanitisation: should not be assertible at a DB, DataService or DesktopService as these should not be directly accessible from a browser.
• [x] XSSSanitisation: should not be assertible for client processes such as AuthClient or RemoteDesktop.

DisableNetworkProvision should not be assertible at a Pod, since this is not a host but a composition of Containers providing data storage and network connectivity in a host-like way. However, a Container could run a virtual router to provide a network, and this functionality certainly could be disabled, so the control should apply to a Container.

The change in assertibility of the LowPriority control clashes with a workaround introduced to handle unrealistic secondary effect cascades that start with a process overload. This is discussed in #77.

[mike1813]

Now addressed in branch 65.