The Curse of A Black MSSP

I think I accidentaly discoverd a new curse, The Curse of a Black MSSP. In recent weeks I’ve spoken to several organizations who has fallen to this particular affliction. They all …

  • have relatively stringent security requirements including that for 24/7 security monitoring
  • do not have internal resources even remotely close to sufficient for their requirements (such as no people, no money, no tools, no processes)
  • despite the above, they will not use an MSSP or MDR.

When asked about this situation, they told me that “all MSSPs are shit” and that “our management (!) will not let us use one.” Now, understand that a much more typical situation would be for the CIO to push the MSSP route and for the valiant technical security team to push back and lose

Once I joked that “MSSP is by far the best way to do securty monitoring once you realized you can use no other way.” (please tell me this is actually funny). So, what other choices do they have? If they had people, they could have used open source tools. If they had tools with more automation (SOAR perhaps), they could have managed with fewer people. But having neither of the above AND having security requirements will typically push you into the MSSP sweet spot.

Yet, a horrible MSSP experience perhaps scarred them for life, and now they are stuck in limbo…. instead of enjoying a quiet mediocrity of MSSP monitoring.



How to help them? By giving them tools and methods to separate shitty MSSPs from merely mediocre ones (with perhaps one or two MDRs with real threat detection excellence thrown in).

So, how did you test your MSSP, before and after contract signing? How do you tell the experts-for-hire from the clowns?

BTW, we are updating our super-popular “How to Work With an MSSP to Improve Security” somewhere late in Q4 2017.

Possibly related blog posts: