<t>IMO companies that want to plan to mitigate a risk like this (where the same update was pushed to all agents, even those where a slower ring was chosen), just need to split their fleet with more than one vendor.<br/>
<br/>
EDR Vendor A and ERD Vendor B are rolled out 50/50, with some reporting platform for ensuring visibility into both of them, or centralising events into one SIEM.<br/>
<br/>
This is an example for EDR - of course if you deploy any sort of agent that runs as SYSTEM or administrator - the same approach needs to be taken.<br/>
<br/>
Servers performing backups should not be able to communicate to the internet in any way, all their updates for agents / OS should be staged by a middlebox server (think WSUS caching but for your EDR as well). If those servers run Windows, then they should be domain joined to a 'red forest', which is not the same as your production AD. So an attacker in the production AD has no privileges over the domain that the backup servers are within. Similar mitigations need to be thought out for hypervisors and how admins authenticate to them.<br/>
<br/>
On the Bitlocker recovery keys topic, ADDS should not the only place they are stored. Having them offloaded into a secrets management system by a daily script, or using an RMM that captures Bitlocker recovery keys are ways of ensuring they are available in an AD disaster.</t>
