Even with robust cyberdefenses, your network is still susceptible to hackers, social engineers, ransomware, and other digital hazards. Given the rapid development of technology, there are bound to be some holes and flaws that malicious actors can utilize to stage an attack or gain access to your system. For cases like these, developing a comprehensive incident recovery process is your best response.
A Multi-Staged Approach the Incident Recovery
The incident recovery process is a crucial component of any cyberdefense plan. Used to designate specific roles, establish staff hierarchy, and prioritize tasks in the wake of a serious cyberattack or data breach, this is a multi-staged process that requires the cooperation and dedication of your entire IT staff.
To develop and coordinate your incident recovery plan, you’ll need to be familiar with the standard phases:
- Incident response planning begins with the initial preparation phase
- Threats, attacks, and malicious actors are identified in the second phase
- Threat containment and control comprise the third stage
- Cyberattacks and threats are eradicated in the fourth stage
- The recovery phase of incident response occurs in the fifth stage
- For many, the sixth stage, used for follow-up and review, marks the end of the process
Although we recommend six stages, there are some optional stages you can add to your plan if needed.
The Benefits of Following an Incident Recovery Process
While remediation standards of the past weren’t as comprehensive as the methods used today, they seldom resulted in a permanent solution. If anything, the stopgap methods and temporary fixes used in the earliest days of cybersecurity only motivated hackers to try new and more sophisticated tricks.
Given the modern reliance on IT today, a standardized incident recovery plan has many benefits.
- Identifying trouble areas, weak points, and security gaps in your current cyberdefense
- Clarifying employee roles and responsibilities before an incident occurs
- Educating your staff on common threats and online hazards
- Establishing lines of communication, including backups in the case of widespread system failure
- Detecting certain incidents and events in real-time
- Predicting and preparing for future threats
- Ensuring the security of consumer data during an active incident
- Easing the concerns of key stakeholders
Although RSI Security recommends six stages, there are some optional additions you can use if needed.
The Standard Process
Although a standardized incident recovery process will suffice for most scenarios, the process of recovering from an IT security incident is very fluid. The six steps presented below do provide a complete guide to incident recovery, but feel free to add or subtract phases as needed.
Stage 1: Preparation
It’s important to remember that the incident recovery process is an ongoing cycle. Since your IT team is constantly responding to new and emerging threats, you’ll revisit this—and every other step—on a continuous basis. Nonetheless, the preparation phase remains one of the most important steps in your incident recovery plan.
Start by identifying the affected assets and ensuring that all of your organization’s resources are in order. This generally includes:
- Communications systems – Ensure that any internal messaging systems are functional and that your IT staff can communicate with each other in real-time. Audit logs, cryptographic hashes, and lists of commonly used ports are also helpful.
- Data storage systems – These systems are often the target of modern cyberattacks. Servers, workstations, cloud, and even external or removable storage systems are included in this category.
- Additional hardware and software – Other hardware systems include networking equipment, personal user devices that don’t contain sensitive data, and data encryption software.
- Internal security policies – Finally, take some time to review your internal security policies. This information can be helpful when performing root cause analysis and when bolstering your defenses against future incidents.
Next, take some time to establish specific user roles and a hierarchy for your incident response team.
- Incident response manager or coordinator – This should be a senior-level IT staff member who can gather data, maintain communications, and oversee digital forensics.
- Incident response handlers and analysts – These employees serve as direct support for the coordinator. It’s their job to collect and analyze evidence, interview other pertinent staff, and complete the brunt of the incident recovery process.
- Human resources personnel – Any IT security incidents that affect your immediate staff should include dedicated HR personnel.
- Public relations staff – These team members are responsible for representing your brand to the public. Depending on the size and scope of the incident, PR staff might be unnecessary.
In cases involving direct and verifiable criminal action, you’ll also want to designate a legal professional to maintain communications with officers, law enforcement personnel, and other legal representatives. For those with potential regulatory fines, this individual is responsible for communicating with regulatory officials, too.
Request a Free Consultation
Stage 2: Identification
Now it’s time to identify the specific incident. Although there are myriad possibilities—with new ones emerging almost every day—most IT security incidents can be classified into one of the six common classifications.
- Network scans, probes, and attempted break-ins
- Improper system usage
- Unauthorized user access
- Denial-of-service attacks
- Malicious software or code injection
- Infrastructure or network investigations and inspections
While proper identification and classification of security incidents makes the remaining phases of the incident recovery process more manageable, there are still some complications to consider. For example, a large organization might receive thousands of network scans daily. Since it’s not feasible to address each one, most IT teams rely on cybersecurity systems to assess them and focus on the incidents that have immediate or severe consequences.
But this doesn’t mean that intrusion attempts and network probes should be ignored entirely. In some cases, they serve as warning signs of larger, more sophisticated cyberattacks. These precursory incidents often include network probes, SQL code injections, social engineering tactics, and phishing attempts.
Stage 3: Containment
During the containment phase of the incident recovery process, your team isolates the threat and mitigates any further damage. They can achieve this via multiple routes depending on the affected systems and the extent of the damage.
In many cases, the best response is to disconnect the affected machine or system from your network. While this will stop the incident from spreading—such as the case with a virus infection or ransomware—it’s only an option if the incident is limited to that machine. This isn’t a viable solution if an incident affects multiple areas or if you’re unsure which systems are affected.
The next option is to shut down your entire system, including all servers, workstations, and network devices. While this response should only be used in extreme cases, it’s one of the most direct and immediate ways of addressing an IT security incident.
Sometimes, you might keep your entire system operating throughout the entire incident recovery process. This approach is typically reserved for cases where sensitive data has not been compromised or when a cyberattack is not considered serious. Instead, your IT team can monitor day-to-day activities to spot the suspicious actions and address the incident at a later date.
In either case, you’ll also use this phase to collect any evidence that may be pertinent to the security incident—including digital and, sometimes, physical evidence.
- Digital – Network traffic logs, user access records, screenshots, and IP addresses
- Physical – Affected devices and serial numbers, hardcopy photographs, written statements, and printed records
Stage 4: Eradication
A threat can only be fully eradicated after being identified and contained. Temporary fixes are sometimes applied at first, but these should be replaced with permanent solutions as soon as possible.
In most cases, the eradication phase follows a clear protocol:
- Uninstalling or deleting the affected data or software
- Running antivirus and antimalware scanners to confirm eradication
- Rebooting or reinstalling the primary operating system (reserved for extreme cases)
- Patching outdated systems
- Restoring, recreating, or replacing any missing data
- Notifying affected consumers or personnel
After completing stage four, your team can consider the incident under control.
Stage 5: Recovery
The incident response recovery phase revolves around testing the systems that were repaired, replaced, or reinforced during the eradication phase. Successful tests lead to resumed operations and service delivery.
Like the first step in the standard incident recovery process, systems testing is a continuous cycle. As new threats emerge, new systems are installed, patched, and re-configured. There are numerous tools and methods for testing out your cyberdefense, but some of the most popular include:
- Network penetration testing
- Vulnerability assessment
- Simulated attacks and controlled hacks
- Tabletop exercises and scenarios
Stage 6: Incident Review
Often referred to as the follow-up or “lessons learned” phase, the final step in the incident recovery process requires a comprehensive review of the entire situation. Since this phase is all about reviewing the information you’ve already collected, this should be the easiest step in your plan.
Try to review as much pertinent information as possible during this step. Although it may be the easiest part of your incident recovery plan, you’ll want to ensure it’s a learning experience for your whole staff.
Make sure to interview any affected staff and, if possible, affected consumers. This usually involves distributing questionnaires and surveys, but consider the feasibility of direct interviews—either in-person or via telephone.
By integrating employee interviews and consumer feedback into your final review, you’ll start to view the incident from various perspectives. This alone might be enough to shape your future IT policies or guide your hardware and software investments.
Optional Phases
Although most experts recommend a six-stage process for incident recovery, it’s not a rule set in stone. Some organizations—and certain incidents—might only require a few steps. Likewise, you might need to introduce some additional stages to ensure the incident is properly addressed.
Threat Analysis and Investigation
When applied to a specific incident, threat analysis goes one step farther than simple threat identification. Once identified in the second phase of the incident recovery process, specific threats can be investigated and analyzed to provide a fully detailed threat profile. This includes:
- Information concerning the threat’s origin
- Its usage in other security incidents
- Whether there’s a chance for a secondary attack
But threat analysis can also be used in a more general sense. In this case, it’s often implemented during the final, “lessons learned” phase of the incident recovery process to give you an in-depth look at current and future threats.
Continuous Systems Testing
Comprehensive systems testing is recommended to ensure proper functionality. While it’s a significant component of the recovery phase, systems testing is useful at various points throughout the incident recovery process. Testing your cyberdefenses during the initial preparation or threat identification phase, for example, can give you an idea of any vulnerable entry points for hackers and other malicious actors.
Ongoing Communications
While internal communications are covered in the initial preparatory phase of the incident recovery process, this refers solely to internal communications amongst IT staff. In some cases, especially those involving a breach of consumer or patient data, you’ll also need to communicate with the general public.
In these cases, it’s best to maintain communications throughout the entire incident recovery process. A good strategy includes an initial press release to announce the incident and provide any initial details you may have, followed by periodic updates until resolution is complete.
Specific industry standards even require public notification of any significant data breach or security incident, including the Health Insurance Portability and Accountability Act (HIPAA).
When working with a third-party consultant or recovery team, it’s critical that you maintain communications at all times. Knowing what the other party is doing and how they’re progressing, will help create a timeline for the entire incident recovery process, which will be helpful when communicating with consumers, staff, and other stakeholders.
Employee Onboarding and Training
Any new employee onboarding or training should occur as close to the initial preparation phase as possible. It often doesn’t help to place someone in a situation where they’re immediately in over their head. While most of your incident response team will consist of current staff, some new additions may be required to fill the gaps.
In these instances, it may be more helpful to contact managed security services provider to step in and provide assistance.
Creating Your Customized Plan
Most incident recovery processes may adhere to the six steps outlined above, but they aren’t exactly uniform in every application. With so many different variables to consider—and with so many potential avenues of attack—it takes true diligence to cover all your bases.
If you’re currently creating or reviewing your incident recovery plan, or actively responding to a cybersecurity threat, contact RSI Security today.