Everything’s moving along quite nicely: your customer is happy with the service you are providing, there have been no significant service interruptions, costs have remained in line with inflation, and so on. The relationship between the MSP and customer is all sweetness and light, and the next contract renewal should just go through on the nod.
And then, everything changes. You experience a security breach…
The Log4Shell vulnerability has shown how a security issue can remain unknown for some time and then be brought into sharp focus in virtually no time at all. Here in the UK, we have just seen the tax office (HMRC) admit to 17 data breaches in just a little over 15 months. We often see news headlines about companies that tried to hide a security breach, only for it to come out later and become a bigger issue than it would have been in the first place.
MSPs must demonstrate they have the tools to both prevent and mitigate damage
Many countries have laws that cover the need for disclosure around certain types of security breach. And for an MSP, it is important that plans are in place to deal with any security breach – and not just at a technical level. Prevention is better than a cure, and steps must be taken to demonstrate that you have the tools in place to prevent a breach from happening in the first place. However, it is better these days to assume that a breach will happen – and know how you are going to deal with it.
To begin with, you must be able to realize that the breach has happened. Obviously, it is better if as the MSP, you can do this. Sometimes, it will be reported to you via a customer – in most cases an unhappy customer. The first line contacts must not try and brush off the customer in any way – it is imperative that any idea of a security breach is taken seriously. First line staff should be instructed to elevate any reported security breach directly to specialist staff who can then deal with the customer and look deeper into the problem.
Next, you must determine whether the breach can be dealt with directly and immediately via technical measures. Even if this is a temporary measure, then it must be put in place to stop the problem from getting any worse. Even if this means throttling or stopping certain services, it needs to be done.
Next is the analysis of the magnitude of the breach. Is this something that is impacting one customer only? If so, then dealing directly with them while checking that there are no other instances of the breach can provide better focus. However, if it is impacting more than one customer, is it an ongoing threat – and if so, what should be done about it?
Communication is key to breach remediation and recovery
Customers not already impacted by a breach but who could be, must be informed quickly and know about the options that are available to them to prevent and mitigate damage. This may include stopping the use of the services, switching to alternative instances of the service on a different platform, altering how access to the services is provided (e.g. via dedicated tunnels), and so on.
Customers already impacted should be told what has happened, what the impact has been as far as you are aware, and what steps they need to take to mitigate any damage. You also need to keep all customers fully updated on the steps that you have and are taking to not only remediate the security issue but also to restore systems – at both a technical and business level.
Each customer will need to be helped in making the right choice. For large MSPs, this may not be easy – dedicating account managers to each customer may spread things too thin to be meaningful. Therefore, a comprehensive area on the website that details what the options are and what each choice means to a customer, will be necessary.
You may have to go further in helping customers. Even where the base issue is down to the customer (e.g. theft of customer details due to poor security around a database), you cannot finger point. Help them to understand what their business and legal requirements are – i.e. how they will need to inform everyone impacted; and, how they may need to offer their own customers tools to manage possible identity theft or misuse of user IDs/passwords. Help them to establish a means of forcing password changes if this is necessary.
If the security breach is deemed to fall under legal disclosure terms, then do this as quickly as possible. Again, do not try and wriggle out from any responsibility. State the case clearly and concisely, and provide information on the steps you have taken and will be taking to mitigate any damage and prevent further issues.
Maintaining trust means having security (and other) policies in place
Managing a security breach requires that a set of policies has been laid out in advance which can then be followed in a logical manner. Having this in place helps you eliminate the possibility of being accused of trying to hide things. It also maintains a level of trust between your company and the customer.
A security breach is never good news, and there will be a hit to customer perception if it is only your company that experiences such a breach. However, many security breaches these days, such as the Log4Shell issue, are far more widespread. Policies that deal with widespread issues can also work with more focused ones. If you don’t already have such policies in place, get working on a set now.
Photo: NeydtStock / Shutterstock
