As Anton just posted, the new version of the famous “How to Work With an MSSP to Improve Security” has just been published. I’m very happy to become a co-author (together with Anton and Mike Wonham) on this document, as it is usually one of our documents that I most frequently refer to clients during inquiry calls. After all, it’s very common to start a call about SIEM, UEBA, NTA or EDR and end it talking about MSS, after the client realizes that using those tools require people – a lot of people – on their side.
Among lots of exciting new content (this is indeed a looooong document :-)), a new guidance framework for those looking for (and eventually hiring) an MSSP:
You’ll notice that we added “joint content development” as part of the Operating phase. This is something we also added to the recently updated Use Cases document. After all, there’s no reason to believe the MSSP knows everything you want them to detect for you; so, how do you tell them that? If you hired an MSSP, do you know if you still have people on your side capable of working with them to develop content?
There is also an important reminder for organizations expecting to have the entire security monitoring process managed by the service provider:
“When customers perform triage, they will often find cases of false positives. Many organizations don’t report these back to the MSSP, only to complain later that they keep receiving the same false-positive alerts repeatedly! Although the MSSP is responsible for tuning the detection systems it manages, such tuning typically requires feedback from the customer. This feedback goes beyond a simple statement like, “This alert is a false positive.” Adding context about why the alert is a false positive will allow the MSSP to perform the appropriate tuning. It will also avoid cases where entire classes of alerts are disabled due to uncertainty around what type of activity is causing them”
I had countless conversations with organizations complaining about the false positives sent by the MSSP. But it’s impressive how many of them are not prepared to report back those events to the provider in a way that would allow them to tune their systems and avoid a similar occurrence in the future. This is a recurrent theme in this document: You MUST WORK WITH THE MSSP, not expect them to figure everything out alone.
We have this and far more in the doc; please read it and don’t forger to provide feedback: http://surveys.gartner.com/s/gtppaperfeedback
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.