Obviously it would depend on the situation, but in this case we could probably use a metric of something like mean-time-to-discovery which is probably a useful

Obviously it would depend on the situation, but in this case we could probably use a metric of something like mean-time-to-discovery which is probably a useful metric for evaluating intrusion detection. Making simplifying assumptions, we can just model this as a probability to discover per unit-time with percentage improvements reducing mean-time-to-discovery. In this case we have ~8 months to discovery or ~240 days. We then need to determine what we deem adequate for intrusion detection. I contend that a competent intrusion extracts the vast majority of its value within 1 week. This is consistent with the results in the Verizon Data Breach Report from 2019 [1]. Given this, we would logically want to detect an intrusion in less than this time otherwise the vast majority of the damage has already been done. By this metric, 1 week or 7 days versus 240 days would require a 35x or 3,500% improvement in detection by FireEye to be able to detect the intrusion and materially impact the value gained from the intrusion. In addition, this is not materially different than the standard in the industry as seen in the other graphs on that same page which shows that detection normally takes on the order of months which is far longer than the standard for exfiltration which is days to weeks. I do not contend that all software everywhere must be made secure against all attackers. However, it must be evaluated against actual expected attacks with a proper understanding as to what it can actually defend against otherwise it is impossible to make an accurate cost-benefit analysis. It is up to the creator/user/people to make an evaluation if the benefits outweigh the risks. That is how you define adequacy. [1] https://www.nist.gov/system/files/documents/2019/10/16/1-2-dbir-widup.pdf https://www.nist.gov/system/files/documents/2019/10/16/1-2-d... Page 10