## 2 Related Work  
### Endpoint Detection and Response Systems  
The term endpoint detection and response (EDR), also known as endpoint threat detection and response (ETDR), was coined by [PERSON] [3] back in 2013. As the name implies, this is an endpoint security mechanism that does not cover the networking. EDRs collect data from endpoints and send them for storage and processing in a centralized database. There, the collected events, binaries, etc., will be correlated in real-time to detect and analyze suspicious activities on the monitored hosts. Thus, EDRs boost the capabilities of SOCs as they discover and alert both the user and the emergency response teams of emerging cyber threats.  
EDRs are heavily rule-based; nevertheless, machine learning or AI methods have gradually found their way into these systems to facilitate finding new patterns and correlations. An EDR extends antivirus capabilities as an EDR will trigger an alert once it detects anomalous behavior. Therefore, an EDR may detect unknown threats and prevent them before they become harmful due to the behavior and not just merely the signatures. While behavioral patterns may sound ideal for detecting malicious acts, this also implies many false positives, that is, benign user actions considered malicious, as EDRs prioritizeprecision over recall. Therefore, SOCs have to deal with sheer amounts of noise as many of the received alerts are false [4]. This is the reason why [PERSON] et al. recently introduced Tactical Provenance Graphs (TPG) [5]. They reason about the causal dependencies between the threat alerts of an EDR and improve the visualization of multistage attacks. Moreover, their system, RapSheet, has a different scoring system that significantly reduces the false positive rate. Finally, an EDR can perform remediation or removal tasks for specific threats.  
Despite the significant boost in security that EDRs bring, the overall security of the organization highly depends on the human factor. In the case of the blue teams, the results against an attack are expected to greatly vary between fully trained teams in Incident Response and teams that solely respond to specific detected threats and are dependent on the output of a single security tool. However, both teams are expected to be triggered by, and later investigated for, the telemetry from EDRs. Since the experience and the capacity of the blue team depends on multiple factors which are beyond the scope of our work, in this study, we focus on the telemetry of the EDRs, the significance that they label events, and whether they blocked some actions.  
Nevertheless, we highlight that not all EDRs allow the same amount of customization nor implementation of the same policies. Moreover, blue teams cannot have the experience in all EDRs to configure them appropriately as each team will specialize in a limited set of solutions due to familiarity with a platform, marketing, or even customer policies. Moreover, not all blue teams face the same threats, which may significantly bias the prioritization of rules that blue teams would include in an installation, let alone the client needs. The above constitute diverse factors that cannot be studied in the context of this work. On the contrary, we should expect that a baseline security when opting in for all possible security measures should be more or less the same across most EDRs. Moreover, one would expect that, even if the EDR failed to block an attack, it should have at least logged the actions so that one can later process it. However, our experiments show that often this is not the case.