It is meaningful to make a distinction between reading and writing memoty. Many applications need to read the memory of other processes. This behavior can be safely allowed for safe and less-safe processes. Writing memory is the action that actually needs severe control. The distinction between these two actions can make the rules safer and more easy-to-build.
Crashdump reporting applications like drwatson might need to read other apps memory but why would any normal app need the same?
Is there a meaningful reason for such implied need and no way to abuse read access to other processes?
Quite a few apps(e.g.,word.exe,IE…) need to access memory(for example, of explorer). My point is that it is better to distingwish these safe actions from really dangrous “writing memory” .
I gather Interprocess Memory Access alert to explorer.exe is triggered the moment an app show the Open or Save/Save as windows dialog so if such case involve a read access it might be practical to distinguish write memory access to create a more specific All application rule allowing these explorer.exe memory accesses.
Another app which whose memory is allowed to be accessed is ctfmon.exe featured in All application policy and possibly involved with user input.
Though unrestricted read memory access to any application won’t appear less dangerous o less prone to malicious use than memory write access.
The only risk of allowing reading memory is leakage, which can be somewhat further controlled by firewall. Mealwhile one doesnt need to allow reading memory of all applications.
Indeed it appears that interprocess memory access could be abused to grab a deal of things ranging from cleartext authentication/password to memory-unencrypted applications or data whatever purpose/actions those steps might further allow.
Of course Firewall filtering and Execution control can somewhat allow some degree of control on malicious activities carried, though it won’t hurt to be aware of such activities to have a better chance to identify some more malicious apps.