It may seem like a lifetime ago, but it was only last year that UCaaS MSPs were talking about the 3CX hack and wondering if they were going to produce an incident report plan. Over the past 12 months, we’ve had major attacks on infrastructure worldwide, along with new threat actors coming to the fore.
According to the CrowdStrike 2024 Global Threat Report, we saw:
- A 75% increase in cloud intrusions
- A 76% spike in data theft victims named on the dark web
- That 75% of attacks were malware-free
And we could hardly forget the CrowdStrike-Azure issue that saw finance, airlines, and numerous other industries grind to a halt due to a looping blue screen of death.
This has led to a greater awareness of the need to build a comprehensive plan for a cybersecurity incident and to encourage your customers to do the same.
Why Build a Cybersecurity Incident Plan?
Every piece of technology is interconnected, and at Wildix, we help to connect all that technology up through our APIs, websockets and iframes. So when our partners build a system, it often connects up all the pieces of technology they use, whether it’s a CRM, a helpdesk, door systems or cameras. It puts the “unified” into “unified communications.”
There are huge advantages to this approach, of course, involving markedly increased levels of efficiency and flexibility. But, of course, if something does happen, it’s a point of vulnerability. If communications go down, everything could go down.
The risks are worth it, of course, and over the past two decades, we’ve not had a breach yet.
But other companies have, and while we have rigorous protocols and a heavy emphasis on security, there is always the risk of a malicious actor finding some loophole. That’s why we have cybersecurity incident response plans, just in case.
It’s now not a question of “if” you’ll get attacked but “when.” And that’s why every MSP needs an incident plan and should help build them for their clients.
Building an Incident Response Plan
At a very basic level, a cybersecurity incident response plan must include:
- Key contacts
- Escalation criteria
- Basic process covering the full incident life-cycle
- Conference numbers for urgent calls
- Basic guidance on legal or regulatory requirements
Key contacts
These should include all stakeholders required to manage the response to the cybersecurity incident. Remember that it’s not just senior management but potentially legal, HR, insurance and whoever is managing your PR. Don’t rely on a single contact method — if your communications system is hacked, for example, you’ll need cellphone numbers for each person.
Remember to keep it updated as people join and leave the organization. It’s easy to create the document and then forget about it, but it must be reviewed every six months.
Escalation criteria
The severity of the issue will determine how far you need to escalate the issue and when. A low-priority data breach, for example, might be handled primarily by IT and then reported once it’s dealt with to C‑level (a CTO or perhaps even the CEO, depending on the nature of the organization). A high risk, high impact issue may need full escalation to all team members.
Each incident should be classified quicky to ensure appropriate parties are informed as soon as possible. Some companies like to use a matrix of different categories with examples of teach type. A DDoS attack, for example, is usually less severe than a data breach and should generally be treated as such.
The definition of a critical incident, for example might include:
- More than 80% of employees unable to work.
- Major systems offline
- Major breach of personal data or financial records
- Risk of losses exceeding 10% of annual income
- Likelihood of reputational damage
Any combination of these could lead to an incident being labled as a critical one (rather than high, medium or low). However, how you define what constitutes any level of attack will depend on your organization.
Basic processes
A basic process should be followed. In most cases, you’ll need to define who needs to do what using a RACI framework:
- Responsible (who is responsible for ensuring something is done)
- Accountable (who delegates tasks and ensures the responsible people are doing them)
- Consulted (who’s opinions, thoughts and authorization do you need)
- Informed (who should be made aware of what’s going on)
One person or section can have multiple roles for each section (so someone can be accountable and responsible for a task). Remember to include third parties if needed (such as third-party businesses reliant on your services or third-party investors).
When you build this framework, it needs to cover the basic principles of most cyber incidents. This might be:
- Incident identification
- Reporting
- Capturing the incident
- Assigning incidents
- Investigation
- Containment
- Eradication
- Recovery
- Review
- Lessons learned
By having this sort of framework available, it becomes easier to manage incidents as they arise and understand who needs to do what. This is a very basic overview, of course, but if a plan becomes too detailed or complex, it can run into hurdles when something isn’t applicable or not planned for.
Conference numbers
One of the biggest challenges during a cyber incident is communication. All stakeholders will want to be informed as soon as possible, but IT and tech will need time to complete their assessments and ensure they have a reasonably full understanding of the incident.
With this in mind, there must be a number of communications options available. The company communications system should be the first port of call for a conference call, but a free backup may be an option if the communications system is under attack.
Basic guidance on legal or regulatory requirements
Most organizations will need to fulfill some sort of regulatory requirements after a cyber incident, especially if it involves the loss of data. Those in the UK or the EU may need to report incidents as a GDPR breach, and in the US, some companies may need to report material cyber incidents under CIRCIA or under recent SEC guidelines.
Regulatory and legal guidelines will help companies quickly identify their obligations and ensure reporting happens as legally mandated without having to worry about finding out during an already stressful incident.
Breaking It Down: Cybersecurity Incident Plans
Ultimately, no business is truly safe from cybersecurity incidents, even if it takes every available step to reduce risk. No one can predict where the next breach might come from, which is why it pays to ensure that a suitable plan is in place. By creating a cybersecurity incident plan, MSPs can help their clients stay safe and be informed should anything critical happen, even if it’s out of their immediate control.
For more insights on cybersecurity for MSPs, subscribe to receive our magazine for free!