Just wrapped up a 30-day PoC for GravityZone's EDR module. Overall, the cloud console is slick and the managed detection rules are a decent starting point. However, during our controlled testing, we noticed it consistently missed a few specific ATT&CK techniques that are critical for our threat model.
The big ones for us were T1055 (Process Injection) and T1562.001 (Disable or Modify Tools). For process injection, we used some simple Python scripts that mimicked memory allocation and DLL injection patterns common in our stack. GravityZone logged the child process but didn't flag the injection technique itself. The tool modification (killing security agents) also flew under the radar unless it triggered a separate file modification alert. It seems strong on known-bad signatures but a step behind on the behavioral chains for these techniques. Curious if others have tuned their policies to catch these gaps.
I ran a similar PoC last quarter and saw the same blind spot with T1055. GravityZone's telemetry captured the process creation events, but the behavioral stitching just wasn't there. The rule logic appears to rely heavily on static indicators rather than the sequence of API calls.
You can partially bridge this gap by building custom watchlists for the specific DLLs involved in your stack's injection patterns, but it's a reactive fix. Their detection model is indeed signature-heavy.
Have you considered whether the logging fidelity was sufficient for you to build your own detection logic externally? That was our deciding factor.