Blog post

How To Exit an MSSP Relationship?

By Anton Chuvakin | December 12, 2014 | 0 Comments

securityMSSP

Let me touch a painful question: when to leave your managed security services provider? While we have the research on cloud exit criteria (see “Devising a Cloud Exit Strategy: Proper Planning Prevents Poor Performance”), wouldn’t be nice to have a clear, agreed-upon list of factors for when to leave your MSSP?

For example, our cloud exit document has such gems as “change of internal leadership, strategy or corporate direction”, “lack of support”, “repeated or prolonged outages” and even “data, security or privacy breach” – do you think these apply to MSSP relationships as well?

And then there is that elephant in the room…

elephant

(source)

FAILURE TO DETECT AN INTRUSION. Or, an extra-idiotic version of the same: failure to detect a basic, noisy pentest that uses commodity tools and no pretenses of stealth?

[BTW, this is only an MSSP failure if the MSSP was given access to necessary log data; if not, it is a client failure]

Not enough? How about systematically failing to detect attacks before the in-house team (that… ahem …outsourced attack detection to said MSSP) actually sees them?

Still not enough? How about gross failures on system change SLA (e.g. days instead of hours), failure to detect attacks, failure to refine rules leading to excessive alerting and failure to keep client’s regulated data safe?

In any case, when signing a contract, think “how can you terminate?” When onboarding a provider, think “how can you off-board?” A detailed departure plan is a must for any provider relationship, but MSSP case also has unique twists…

Any thoughts? Have you left your MSSP in the dust over these or other reasons? Have your switched providers or brought the processes in-house? What would it take you to leave?

Blog posts related to this research on MSSP usage:

Comments are closed