In my last blog posting, I talked about why you should consider moving to an MDR provider. In this post, I want to discuss what you should be looking for in an MDR provider. There are several factors that should be considered if you are going to have a successful partnership with an MDR provider. Leading research and advisory companies (and others) have written about such too, but I don’t charge vendors to say nice things about them. 😀
A major point of consideration should be whether the MDR provider has integration with your own existing (already deployed) ED&R solution? Or do you have to use the MDR vendor’s own ED&R client? If the MDR vendor does have integration with your existing ED&R solution, is that integration only (one way) the ability to ingest your ED&R product’s logs? Or, is that integration (two-way) via an API(s) that allows not only for the collection of log data, but also response capabilities? These are very important considerations if you have already deployed an ED&R solution. If you happen to be a greenfield opportunity for ED&R deployment, then never mind.
Forrester states (“Accelerate Detect and Response Capabilities with MDR”) that “Vendors who build their MDR tool sets are able to evolve their technology at their own pace, eliminating the need to wait on a partner.” First, let’s note that this Forrester research was conducted on behalf of Secureworks - which just happens to have its own proprietary ED&R client, Red Cloak. Second, I disagree with this Forrester recommendation because it means a rip & replace of your existing ED&R deployment (assuming that you have already done so). Third, I disagree with this Forrester recommendation because Secureworks is a services company, not a product company. I really doubt that Secureworks has more expertise about OS operations than, for example, Carbon Black, or that Secureworks could build a better product faster than, for example, Carbon Black.
Now, with all of that data coming from hundreds / thousands / more endpoints, you want to thoroughly understand the MDR vendor’s ability to provide timely, accurate, and meaningful analytics. And, you certainly should expect that such analytics capabilities are based on artificial intelligence / machine learning, and not (fallible) human analysts. Those human analysts may or may not be skilled or trained, extremely tired at 02:00 on a Sunday, thinking about how nice her upcoming vacation is going to be, etc.
Assuming that you are satisfied with the MDR vendor's analytical capabilities, then your next consideration should be the MDR’s availability of play or run books off-the-shelf (e.g., already built and tested) that can be customized for your environment. During an incident is no time to try and develop a play book. After all, remember what the “r” in MDR and ED&R stands for.
Incident Response Experience
Finally, you might have been fortunate in your career to date, and have little incident response experience. (Or, you might have many emotional scars from such?) So, you will want to evaluate the number of experienced incident response personnel with significant expertise that are available at any time - particularly weekends and holidays. You may very well need to call upon such expertise when that near real-time monitoring detects malicious behavior. And, that malicious behavior may very well only be detected now that you are using an MDR provider. You may very well have missed such previously.
If you’re interested in finding out more about sophisticated near real-time detection capabilities, then contact us.