Equilateral of Exclusion Risk

For organizations which don't have the necessary resources to dedicate FTE(s) full time to detection engineering, it can become difficult to judge which test their exclusions and judge their risk. This is where EER can come in and provide some rough guidelines/help:

The core principles of EER are:

• There exist some activities that cannot be detected reliably without some exclusions built into the detection logic
• Every exclusion introduced some risk of a bypass
• Not all categories of exclusions introduce the same bypass risk
• Optimal exclusions may not be supported by the security controls deployed by the org
• Detection engineers should select the exclusion or exclusions with the lowest risk of bypass
• As controls are updated, exclusions should be reviewed

When writing an exclusion, make sure that you validate that the exclusion does not render the detection useless. In other words, make sure that the detection still works as originally intended after adding the exclusion. For more on this topic, see Detection Validation

^{[1] [2]}

Relevant Note(s):