Assuming you have a TIE server, I would personally do the following:
Set RP to High (also make sure to run the McAfee test file to ensure your traffic is getting out to the cloud for RP Dynamic). As long as you don't enable offline scanning, it should be fine.
DAC at Unknown
Block at Might Be Malicious
Clean at Most Likely Malicious.
I would block for all the memory injection rules at a minimum. If you don't see too many false positives, also the writing to and deleting ransomware rules.
Also, to help mitigate false positives, I would enable JTI rule 250.
This is a very secure configuration. It will take some effort around trusting files in TIE, but if you want to really secure things, this will do it. A couple of processes might need exclusions in the DAC exclusion list, such as Explorer, IE, etc. This will limit containment if an untrusted DLL is loaded. So you lose a bit of coverage there, but you'll be less likely to run into issue because of DLLs dropping the process reputation of those things and them getting contained.
I disagree with setting DAC to unknown. In most enterprises, you have thousands over thousands unknown executables. The ones from inhouse-programmed applications are mostly those who have the most problems with a containment. Therefore, leave DAC to "Might be Malicious" if you want to stay away from a lot of extra work. Setting DAC to unknown would IMHO only be useful if you only have very few unknown executables in your environment / on your ATP-clients. And I assume that's not the case.
Further you can set every DAC Rule to Report and Block.
Let me counterpoint you there a bit.
JTI rule 250 will mitigate much the "thousands" of unknown executations that might exist. Focus on cert based exclusions, so you allow TIE to learn the environment and trust things by cert. Those that are not signed, you can work with vendors and get them signed as they release new versions (often times just asking will get a yes). Beyond all of this though, if a file is contained, if it doesn't do anything blocked by a DAC rule, it works just fine.
If you have developers, lets say, who are doing regular builds that get contained, you just create needed exclusions for those locations. This isn't much different than tuning AV exclusions across an environment.
Yes, there is a lift to get to this point, but once you do, what happens for any malware that starts with a memory injection into a trusted process? It is dead on arrival. What happens to ransomware? It might hurt one system a bit, but that is mitigated by the DAC rules, and once ATP drops that reputation to, say, Most Likely Malicious, it gets killed. You definitely need to be selective on the rules you block with, but if the rule isn't blocking, it doesn't much matter.
If you don't have ATD, I don't think you'll ever get a file at Might be Malicious either. If you do, you might want to just block them.
To help further. Do we talk about:
Since starting 2020 the ATP Module is free with some ENS-Suites and people start using it.
Our end TARGET BLOCK UNKNOWN does NOT work until now 04/2020 100%. We have gone through the FULL process since 4 years now from A-Z. Framework Assembly, Delphi Code blocked. The Cert ist fine and a part of it. Esp. nice of someone steals your Code signing cert or a Cert authorization gets hacked (Like it happened several times > Yes we have Cert Revocation we know...)
To be honest to get ATP running on PREMISE you need to TRAIN AND FEED the TIE and in the start do a lot of manual approval until it works in a 1'000 client+ box. You can have 300'000 EXE and DLL also in a 10 man CAD/CAR engineering with 10 clients also!
We have also made own tools (Coded) to auto submit EXE and DLL automatic to the Sandbox to get the process fully running.
Once you have this work behind you it will almost run automated with no False/Positive.
Now above is ALL for the ONPREMISE with TIE + ATD-SANDBOX for USD 200'000.-
I think most forum questions will be coming UP with JUST the ATP-MODULE from ENS 10.7 APRIl 2010 and the GTI OPTION in DAC,
We are just trying that today internal on some clients. Just to see how that would work and how much traffic to GTI this will make. Also the Latency for the start of EXE if he has to do the lookup etc.etc.
Our W10 client connected to EPO 5.9.1 with latest Agent and
ALL GTI + Mcafee Category and IP open for Mcafee Security for Exchange GTI
Currently THINKS he is OFFLINE > If we enable the Checkbox
Enable offline scanning (Might result in increased false positives)
Then we see first results asap the REAL protect Test pattern etc.
Second we see a false/Positive in second file > C:\Windows\System32\conhost.exe (Bravo 😉
A long way to get THAT running without TIE and ATD in place i can guess?
Greeting from Switzerland, Mcafee Partner