How IT Documentation Relates to Incident Response

“Dear Network User,” the email begins. “We regret to inform you that your MyCompany account has been suspended. Please follow the link below to update your account.” It seems legitimate, your customer thinks. After all, “MyCompany” is the name of their organization. They click the link and—just like that—they’ve opened the door for malware, allowing it to begin infiltrating the entire network.

As a managed services provider (MSP), it’s your responsibility to immediately jump into action. That means turning to your cybersecurity IT incident response plan to guide you through.

What is an incident response plan?

An IT incident response plan is a documented process for dealing with a cyberattack. With the right plan in place, MSPs can quickly identify where a breach occurred, what systems were affected, and how they should respond to eradicate the malware.

So why do you need an incident response plan? While a security-savvy company will rely on preventative practices—updating their antivirus software, putting appropriate patches in place, or running daily backups—to protect against a cyberattack, there is always a chance of an attack slipping through the cracks.

According to recent reports, the number of phishing attacks rose in the third quarter of 2019 to a level not seen since late 2016. What’s more, a 2019 report found that 43% of all cyberattacks are targeted at small businesses. These startling statistics make a strong case in favor of adopting a robust incident response plan that helps ensure MSPs know exactly how to proceed if their customers fall victim to a cyberattack.

How to create an incident response plan

The number of incident response steps included in an incident response plan can vary from company to company, but typically these plans resemble some form of the following:

1. Preparation: This introductory phase sets the scene for all the steps to follow. During the preparation phase, MSPs work alongside each of their customers to put a robust incident response plan in writing. Together, they set expectations, define incident response roles and responsibilities, and identify business-critical services, applications, and data.
2. Identification: Once an incident is detected, MSPs will usually be made aware of it via an alarm from a threat monitoring solution or log data. From there, MSPs must work with their customers to understand and classify it. That means asking questions like, “Is this a first-time occurrence or has this incident occurred before?” and “When did the event happen, how was it discovered, and by whom?”
3. Containment: Once MSPs understand the issue, it’s time to quarantine any affected systems. The goal is to protect the infrastructure from further infection while also working to keep critical systems (identified in the preparation phase) up and running. Once contained, it’s important for MSPs to spend time analyzing the incident. That means identifying the entry point, who the attacker was, which accounts were compromised, what data was accessed, and so on.
4. Eradication: After analyzing what happened and why, it’s time for MSPs to start working on removing the threat from the computer or network. This might involve running an antivirus program, deleting software, or adding a critical patch.
5. Recovery: Once you remove the problem, it’s time to restore systems to full business continuity. That means working from backups or rebuilding a full system or network.
6. Review: During this final stage, MSPs work with their customers to discuss and document answers to questions surrounding what happened, what actions were taken, what went well, and what could be improved.

IT documentation—a crucial component of incident response

Having a secure, standard system for documenting all breach-related data (the who, what, when, where, and how) during an incident response process is crucial. These documentation systems empower MSPs and their customers to:

Better prepare for the future: By reviewing notes pertaining to what went wrong—and what went right—MSPs are armed with the insights they need to adjust their incident response plan accordingly. In most cases, certain steps are updated to better prepare for future attacks, while steps that proved their worth remain.

Remain compliant: Many MSPs deal with customers who have to comply with strict industry regulations. For example, any company that deals with the personal data of European Union residents must comply with the General Data Protection Regulation (GDPR) requirements. According to the GDPR, companies may be required to report a breach [if it is likely to put EU citizens’ personal data at risk. As part of this reporting, companies must detail the nature of the breach, the likely consequences of the breach, and the measures taken or proposed to be taken to address the breach, among other key factors. Having this data already well documented will help facilitate the entire reporting process.

Prosecute if appropriate: Some threats may require the involvement of law enforcement to prosecute the bad actors involved. If this is the case, officials will want access to well-documented details surrounding the attack—including how it was handled. These documents will become even more critical if the case is taken to court and attackers are brought to trial.

Putting an incident response plan into play

Customer security and privacy is a top priority for any MSP. Through administrative, operational, and technical security controls, MSPs strive to protect their customers’ data and keep cyberattackers at bay. Robust incident response plans play an integral part in this process, empowering MSPs with a step-by-step guide to identifying, containing, and resolving threats to maintain network stability.

A critical element in any incident response plan is thorough IT documentation. Breach-related insights that are comprehensively chronicled allow MSPs and their customers to learn from past mistakes, comply with government-mandated standards and, in some cases, even bring their attackers to justice. Any strong incident response plan will require robust documentation, and a tool like N‑able^® Passportal can help your technicians work efficiently and unlock previously trapped client knowledge.