Best Practices for Handling Incident Response During a Merger and Acquisition

Solutions Review’s Contributed Content Series is a collection of contributed articles written by thought leaders in enterprise software categories. Craig Jackson and Nate Pors of Cisco Talos go deep into how enterprises should handle incident response during a Merger and Acquisition.

The authors would like to thank Caitlin Huey for her contributions to the initial research for this blog.

Incident response can be a complex undertaking even under normal circumstances, even when a company isn’t going through a major period of restructuring or mergers. Factoring in another organization, its infrastructure, incident response team, executives, subsidiaries, and customers during an incident increases that level of complexity by orders of magnitude.

Organizations affected by a security incident during a merger or acquisition may find that their Incident Response Plan (IRP) and playbooks – foundational elements of an organization’s incident response capability – are of limited use when only a portion of the collective incident response personnel have defined roles and responsibilities. A breakdown in such a fundamental component of an organization’s incident response capability can hamstring response efforts before they even begin.

Of course, adversaries know all of this. They know the upheaval associated with M&A creates the perfect operating environment for malicious activity. They know threat models change overnight, risk profiles shift, and gaps in security monitoring appear as assets and infrastructure are transitioned. They watch for M&A announcements on public forums to identify potential targets. Some may be already watching from within the organizations themselves.

It’s up to the combined security leadership and technical personnel from all entities involved in the M&A process to recognize these challenges and implement proactive measures that not only protect digital assets during the merger and ensure that incident response efforts will be coordinated and effective.

NOTE: The authors are digital forensics and incident response (DFIR) professionals. The guidance and recommendations provided are focused on supporting an organization’s cybersecurity practice and should not be considered legal advice.

Best Practices for Handling Incident Response During a Merger and Acquisition

Case Study Scenarios

Scenario 1: The Acquired Entity’s Infrastructure is Found to be Compromised

The integration of Company B’s IT assets into Company A’s infrastructure begins on schedule. After several days of hard work and late nights, IT leaders from both organizations are optimistic that infrastructure consolidation might wrap up ahead of schedule. But before the high-fives start flying, Company A’s cybersecurity team detects unusual network activity between one of Company B’s servers and a group of Company A’s critical servers. When asked whether they’d noticed any related activity before the merger, Company B admits they didn’t have the ability to monitor east-west traffic internally. Further investigation reveals that an adversary had been present in the Company B network for months prior to the merger but went unnoticed because of the gap in security tooling.

This is one of the most common concerns anticipated by security teams during M&A preparation. In fact, many acquiring organizations require that the anticipated acquisition complete a third-party risk or vulnerability assessment as a precaution before any connection or crossover is made between their IT environments. While such an assessment should have identified Company B’s limited internal network visibility before the merger, the joint leadership team may have decided – or been told – to accept the risk to keep the merger on schedule. This scenario represents a worst-case outcome due to an assessment oversight.

Scenarios like this underscore the need for fundamental incident response capabilities during M&A. Despite cybersecurity teams’ best efforts to identify security concerns prior to the merger, no environment can be considered 100% secure or free of malicious activity. Merging entities should anticipate security challenges and prepare to work collaboratively to resolve those challenges as they arise.

Scenario 2: The Acquired Entity Experiences a Ransomware Attack

Some 70 percent of Company B’s IT infrastructure has been integrated with Company A’s environment. With only a week left to go before the planned completion of the infrastructure transition, Company B employees begin to have issues with authentication and data access. What is initially thought to be growing pains in the rapidly expanding network turns out to be something vastly different when a ransom note is found on a Company B file server attached to Company A’s network.

M&A activities aside, ransomware attacks are known to create urgent challenges even for companies with mature information security and incident response programs. Adding an acquired entity into the mix with its own infrastructure, personnel, and practices shifts the ransomware response paradigm most organizations have established. Even the culture or mentality toward ransomware response may differ between the acquiring and acquired organizations, causing unneeded friction between business and technical leaders. Sourcing funds for a ransom payment – i.e., determining the division of funds provided by the acquiring and acquired entities – is also likely to provoke conflict among internal stakeholders.

The high-profile nature of a ransomware attack also makes any related incident a public relations (PR) matter. Ransomware group blogs smear victims and, sometimes, even the victim’s partners, customers, and other associated organizations. How will disclosure of related data on a ransomware group’s site influence the M&A journey? What if the adversary discloses sensitive details about the merger process itself? Could a severe ransomware attack cause executives to reverse course on the entire merger?

Scenario 3: A Subsidiary of the Acquired Entity is Breached

As part of Company A’s acquisition of Company B, it is agreed that a subsidiary of Company B will maintain its own security team but will draw on Company A’s larger and more skilled incident response team during major incidents. Later, one of Company B’s custom-developed, critical applications is breached, requiring Company A’s incident response team to rely on Company B’s subject matter experts for insights into a specialized application they know little about.

Post-acquisition standardization of teams, tools and standards is simple in theory but extremely difficult in practice, especially when previously discrete security teams bring their own preferences and workflows to bear. In a perfect world, the teams will cooperate, and complementary tools and processes will lead to successful incident response efforts. Realistically, gaps or overlaps in processes and technologies will create conflict that highlights weaknesses ripe for exploitation. The teams may become hostile or defensive of the resources they own, creating major internal divisions.

Finances are also a factor. The acquiring organization’s CISO likely fights hard for their annual budget, and the Board may not understand the need for additional funding to extend the controls protecting the primary merging entities to a subsidiary. These financial restrictions may also prevent the subsidiary from receiving the appropriate technical and leadership training.

Scenario 4: The acquired company’s IT team includes malicious insiders

The merger between Company A and Company B concludes, and the networks of the two organizations have been integrated. Soon after, Company A’s security team identifies suspicious activity on a domain controller linked to the account of a former Company B IT contractor. Further investigation implicates at least three other past Company B contractors, all linked to an overseas IT consultancy. The Company A security team realizes that much of Company B’s original infrastructure was built by malicious insiders.

Attacks facilitated by malicious insiders are traumatic for any organization, adding layers of administrative rigorousness to investigations overshadowed by feelings of distrust and betrayal. To further muddy the waters, a merger is a vulnerable period for both employee and employer. Employees seek to find their footing in a new corporate culture, while employer concerns over disgruntled employees may be heightened. Feelings of distrust between Company A and Company B team members could escalate quickly. Incident responders must focus on digital evidence, but ignoring the human aspects of the incident would be a major mistake.

Lessons Learned

Lessons learned from the scenarios detailed above can be actioned by organizations preparing for M&A. Arranging these recommendations into administrative, technical, and legal/operational categories will also help align these action items with the correct stakeholders (e.g., legal, communications and cybersecurity).

Administrative Considerations

• Establish roles and responsibilities. Establishing incident response roles and responsibilities across all entities involved in the M&A process ensures that incident response personnel from different organizations can work collaboratively and efficiently towards a common goal – incident remediation and recovery. High-level plans should be created and documented to designate responsibility for specific response activities regardless of which entity is attacked. Subsidiaries of the acquired organization must also be considered during incident response planning. How much help does the subsidiary’s security team expect? Should the parent company’s incident response team step in even if the subsidiary doesn’t request help? If multiple subsidiaries are affected, which subsidiary receives priority assistance?

• Facilitate secure communications. Once incident response roles and responsibilities are understood by all entities, secure communication methods must be deployed to support the new cross-organizational incident response team. Remember that communications methods must be available to individuals supporting the incident response team, such as executive leadership, communications, legal and human resources. Lines of communication must be open to subsidiaries of the acquired organization as well.
• Follow personnel security best practices. The acquiring organization should follow new-hire onboarding processes for all incoming IT and cybersecurity personnel, including background checks and any other HR requirements. This requirement may seem inconvenient or offensive to tenured employees who are trusted by the acquired organization, but contracted employees may not have been included in security checks, and few companies conduct follow-up security checks after initial hire. Regardless of whether background checks are conducted, coordinate legal and human resources representatives from all entities to develop a fair and objective insider threat investigation strategy. Define thresholds for what types of evidence will be sufficient to bring an employee under suspicion and outline approved methods for conducting internal interviews and investigations discreetly.

• Identify recovery time constraints and recovery priorities. Executives should be involved as an extension of the incident response team throughout the M&A process so incident recovery efforts can be coordinated with any contractual M&A milestones. Business leaders can also help the incident response team prioritize critical systems and services until asset criticality listings can be updated to account for the combined infrastructure.

Technical Considerations

• Plan immediate containment actions. Immediate containment actions should be updated to consider all incoming infrastructure. The potential effects of each immediate containment action should also be understood and approved by all entities involved in the merger. Sweeping containment actions commonly employed during critical incidents (e.g., ransomware attacks) may restrict operations for one or both merging entities, especially as more of the acquired entity’s infrastructure is absorbed.
• Address specialized applications and technologies. Ensure that specialized applications and technologies are acknowledged by all parties and that subject matter experts will be included in incident response processes. If a specialized application is supported by a third-party consultant or vendor be sure to identify an internal stakeholder to coordinate response efforts with those external resources.
• Create contingency plans. Adapt existing disaster recovery and business continuity plans to address outages in mission-critical applications or systems resulting from a cybersecurity incident during the merger. Include considerations for delays in technology integration initiatives resulting from malicious activity or other security constraints.

Legal/Operational Considerations

• Consider incident impact in legal safeguards. Considerable time and effort go into preparing legal protections on both sides of the negotiating table. Include considerations for an active incident and how a critical cybersecurity incident may influence the M&A process. Legal safeguards should also drive compliance with any regulatory requirements the merging entities are subject to during and after an incident.
• Align incident response support contracts. Review third-party DFIR provider and cyber insurance contracts for all entities. Confirm where coverage gaps exist, and which policies/contracts will take priority during an incident. Designate stakeholders to activate the relevant DFIR and cyber insurance support contracts.
• Coordinate legal counsel across all entities. Ensure that legal representatives from all organizations involved in the merger have established roles, responsibilities, and expectations for response processes requiring legal coordination. Participation will be particularly important during a ransomware attack, where activities such as adversary negotiation, ransom payment, and sensitive data disclosure often have public relations and legal implications.

Planning for Incident Response During M&A

Given the complexity of conducting incident response during M&A and the potential impact of a security incident on those processes, organizations must build foundational incident response practices into related security preparations. Doing so shouldn’t mean rebuilding an incident response program from scratch, but rather adapting key elements from an existing incident response program into the M&A preparation phase.

The lessons learned presented above can be referenced to support and supplement well-known security standards such as NIST 800-53 and the Centers for Internet Security’s (CIS) Top 18 Critical Security Controls. This will create increased confidence in the joint security team’s incident response capability and should help keep M&A processes on course in the event of a cybersecurity incident.

A Note on Divestitures

While this blog focuses on mergers and acquisitions, divestitures require similar incident response preparations. Business leaders might hesitate to pursue more than the minimum required due diligence processes required prior to divestiture of assets, considering such efforts to be “negotiating against themselves.” But proactively developing contingency plans to address incidents that occur during these key business transactions can help avoid failed negotiations and long-term legal issues at the cost of a short-term inconvenience.

Per recent SEC guidance, publicly-traded U.S. companies and foreign private issuers are obligated to report any “material cybersecurity incidents” with a Form 8-K or Form 6-K filing within four days. Reports concerning any part of the divesting organization’s network could complicate negotiations or even void a divestiture deal prior to closing. Proactively hunting for indicators of compromise within the asset to be divested can reduce the risk of a cybersecurity-related complication. Organizations might also consider preparing an organizational playbook for conducting incident response specifically during divestiture windows. This playbook would focus on scoping and containing cybersecurity incidents in a way that avoids tainting the reputation of assets planned for divestiture.