mike1813
commented
11 months ago As a first step, we can fix the overload threats affecting the test case created for issue #95, and other such threats:
- [x] I.O.DDoH.3: distributed DoS attack from the Internet, should depend on the target Interface being In Service.
- [x] I.O.IoH.3: DoS attack from the Internet, should depend on the target Interface being In Service.
- [x] I.O.RoH.3: DoS attacks from another remote network between the target and the Internet, should depend on the target Interface being In Service.
- [x] I.O.LoH.3: DoS attack from an adjacent network, should depend on the target Interface being In Service.
- [x] I.O.HIoH.3.2: DoS attacks by someone with control of an adjacent subnet.
- [x] P.O.HP-iT.5: software bug in a Process causes it to become overloaded, should depend on the Process being In Service.
- [x] P.O.PpDP.6: overload in a Process as a side-effect from the use of homomorphic encryption, should depend on the Process being In Service.
- [x] DB.O.DBsDP.6: overload in a DB process as a side-effect from the use of homomorphic encryption, should depend on the Process being In Service.
- [x] DB.O.DBsDRSDS.6.1: overload in a DB process caused by inefficient encryption schema in the stored data, should depend on the DB process being In Service.
In addition:
- [ ] I.O.HIoH.3.1: DoS attack by someone with access to an adjacent subnet, should be deleted (it duplicates I.O.LoH.3).
The following have been checked and should not depend on the Host being In Service:
- H.O.CVHHHoDC.0: overload of a Host due to an overload in a Virtual Host provisioned on it, need not depend on the target being In Service because if it was not, the Virtual Host would not be In Service.
- H.O.HP-iT.0: Overload of a Host due to an overload in a hosted Process: same argument - the Process can't be In Service if the Host is not.
- P.O.CCCS.3: Overload of a Service by a Client: already depends on the Client-Service relationship being In Service.
- P.O.CCDFSFS.0 and P.O.CCDFSTS.0: Overload of a Service by an excessive data flow, also depends on the Client-Service relationship being In Service.
- P.O.DDoS.3 and P.O.DoS.3: Overload of a Service by DDoS or DoS attacks from a subnet, depends on an attack path being in Service which ultimately depends on the Service being In Service.
- P.O.PILSsSC.0: overload of a Service listening on an overloaded Interface, depends on the Client-Service communication channel via the Interface being In Service, which also depends on the Process being In Service.
Normal operations that have the potential to increase risks are modelled as threats. For example, a Host becomes more exposed to other threats when switched on, so turning on a Host is represented as a threat leading to the behaviour 'In Service'. This or the associated TWA is then used as a cause in other threats that would not apply to the Host were it still switched off. To prevent those other threats, one can use a (temporary) disablement control strategy to block the threat cause representing the Host being switched on.
It would be helpful if some of these normal operation threats were 'no cause' threats, as described in #95. A test case created for that has revealed that some threats don't depend on the In Service behaviour when they should. Enabling the disabledment CSG doesn't block all threat paths.
For example, I.O.IoH.3 represents a DoS attack from the Internet on a host interface leading to overload and indirectly loss of availability in communications with the host. This does not depend on the Interface being 'In Service', presumably (but if so, wrongly) because if the Interface (or equivalently, its Host) were disabled it would not prevent the resulting loss of availability.
This presumption is incorrect on two grounds. Firstly, the DoS attack leads to overload, not directly to loss of availability. Clearly, if either the Host or the targeted Interface was disabled, it could not be overloaded. Secondly, the loss of availability due to an overload does not matter if the Host was unavailable due to the side effects of a disablement control strategy. The threat path leading to loss of availability due to the DoS attack is nonsensical - the fact that it happens for other reasons doesn't make this reason valid.
The test case before host disablement is Issue 95 Test - No Controls - Asserted.nq.gz.
The same test case after host disablement is Issue 95 Test - Disabled Host - Asserted.nq.gz.
The same issue may be present in assets other than Hosts.
All threats should be reviewed to determine whether they should depend on any involved asset being In Service, and this should be added as a cause where it has been wrongly omitted. This will take some time, so this issue should be kept open, but changes merged into the main development branch (currently '6a') as and when they can be implemented.