The following issue was discovered when working on #64, #65, and #47.
The IDPS asset uses two important defences:
effectiveness, which determines how well the IDPS performs its task of restricting malicious activity from occurring on the associated Applications.
disabled, which it inherits from the Application asset which it expands, that is used to represent whether or not an Application is present. The lack of Application in the model is seen as reducing the ability of an attacker to launch attacks as a particular attack vector is not available to them.
However, in the case of an IDPS its absence should actually make it more likely for the attacker to succeed. Given the current MAL framework that lacks a not operator we cannot have a defence lead to enabling an attack step. As such, the current behaviour of the disabled defence on IDPS assets is illogical and should generally be avoided.
If possible the disabled defence should be hidden in visualisation tools, this is why it was tagged with @Override @hidden in b676fe78e5cd18fcd8cf680ac68c3209ee101866.
No functional workaround was discovered in the discussions around it and the decision was made to defer a proper solution to a later time.
The following issue was discovered when working on #64, #65, and #47.
The
IDPSasset uses two important defences:effectiveness, which determines how well the IDPS performs its task of restricting malicious activity from occurring on the associatedApplications.disabled, which it inherits from theApplicationasset which it expands, that is used to represent whether or not anApplicationis present. The lack ofApplicationin the model is seen as reducing the ability of an attacker to launch attacks as a particular attack vector is not available to them.However, in the case of an
IDPSits absence should actually make it more likely for the attacker to succeed. Given the current MAL framework that lacks a not operator we cannot have a defence lead to enabling an attack step. As such, the current behaviour of thedisableddefence onIDPSassets is illogical and should generally be avoided.If possible the
disableddefence should be hidden in visualisation tools, this is why it was tagged with@Override @hiddenin b676fe78e5cd18fcd8cf680ac68c3209ee101866.No functional workaround was discovered in the discussions around it and the decision was made to defer a proper solution to a later time.