We unfortunately are not afforded the opportunity of knowing what attacks we are going to experience.
You cite the very reason that Microsoft created SRP and how security policymakers recommend it to be used; when the attack context is not known, then it is common sense and expedient to block by default, even blocking globally. Back then Microsoft stated it was not possible to intercept it all, analyze it all, classify it all in order to separate benign from malicious actions. Breakages will happen, they are few and far between and easily fixed with allow exceptions. Other security policymakers within the IT security industry embraced these simple concepts. They showed enterprises how default-deny as a matter of course is one of the best protection models, and the rest is history. SRP was widely adopted and now is a part of the enterprise security paradigm in all of its forms.
In my opinion, the best way to handle this rule is to include context, so that it is blocked when it needs to be blocked, and auto allowed when it needs to be allowed. For example, if a non-risky whitelisted app launches a cmd script, should it be blocked or not?
Emsisoft incorporated this type of context-based security in its behavior blocker back during its Mamutu era. If an admin entered a script within a console or executed it from a script file, then it would not be blocked. If the same script were launched by a suspicious or known malicious process, then it would be blocked. This is on top of the behavior blocker parsing the command line, analyzing it, and blocking it if the admin did not know they were executing a malicious script.
Context, within your meaning of the word, has been used by all the security software vendors for well over a decade. Solving this problem:
1. Malware uses PowerShell
2. Your utility to tweak Microsoft Defender uses PowerShell
primarily improves usability, albeit marginally. It also improves security if it takes decision-making away from the user, based upon the presumption that the contextual analysis is correct.
Simply blocking "unsigned processes, unknown signers", etc, is NOT zero trust. Sure, OSA will harden the system to a certain extent, but it is far from zero trust.
"Zero Trust" is a protection model that assumes the network segment and everything connected to it is always at risk to internal and external threats. It is a protection strategy that has nothing to do with whether or not a security software uses context within your meaning of that word.
