The previous installment of this column discussed what to do when a cyberattack inevitably occurs, including how to react if a client’s organization (or a CPA’s own employer) lacks an incident response plan (IRP). It is never desirable to operate without an IRP, so this installment will discuss the best practices to reduce the financial and business impact of an attack to a level that will not threaten the viability of the organization.
There is a right way and a wrong way to build an IRP; the wrong way will be covered first.
The Wrong Way
All of the following are ways to ensure an IRP will be insufficient to the task:
- Put the chief information officer or the chief information security officer in charge of the IRP.
- Depend on the technology and security teams to build and test the IRP.
- Make sure that all copies of the IRP are only stored on the network.
- Make sure to select only one person for each critical role.
- Do not engage the executive team, legal, audit, or communications departments.
The Exhibit represents a real, New York State–based organization that ended up on the front page of the Wall Street Journal. This white-glove firm paid a third-party consultant to develop this process map for them and then accepted it, without testing, as its active IRP. By tracing the paths, one can see that this plan is predestined to compel the organization to perform poorly during an incident.
Exhibit
Real-Life Example of a Bad Incident Response Plan
First, the organization determined, upon notification of the incident, whether the incident was at a high, medium, or low level of severity. That determination was impossible to make upon initial notification; only detailed forensic activity would have determined how severe the incident was. All incidents should be presumed to be of high severity at the outset.
Second, the process flow documented in the Exhibit did not begin to address the potential dwell time and its impact. Being notified of an incident does not mean that the incident has just happened. The FBI and other industry experts warn that the average dwell time (i.e., the time from the incident occurrence to the identification of the incident) is approximately 221 days. After every 100 days of dwell time, the business cost of the incident doubles.
Third, too many single points of failure appear embedded within the process. Note that the chief technology officer (CTO) was the designated update layer for all issues on a regular basis. There was no indication who in the organization functioned in this role in the absence of the CTO. In addition, the security team manager was a second single point of failure.
Fourth, the organization “considered” activating the third-party incident response augmentation—meaning a third-party firm on retainer to support it during and after the incident—but never went any further.
Fifth, the process chart heavily focuses on “informing” and “updating.” At no point in this process did anyone actually make any key decisions, such as the following:
- When did the team decide to contact law enforcement?
- When did the team craft a message to the board of directors and the press? (Or, in the case of a privately held firm, when did the team engage the investors?)
- When did the team bring in a third-party forensics team?
- Who was responsible for managing the news flow?
Finally, and most importantly, the organization presumed that the entire incident was a technology problem. There was absolutely no engagement with any part of the organization dealing with the business, and no contemplation of either the potential operational or financial impact. Nothing in this chart addresses how the business will inform and interact with the public; there are no defined lines of communication.
The Right Way
Focus on the business.
Incident response is vital for corporate health. It is a function that should report to the CEO and the board. The board and executive team must treat it as a primary fiduciary responsibility. Cybersecurity needs to be viewed as a business issue, not a technology issue. Only the board and the CEO, supported by the outside auditor, have the power to mandate that historically siloed teams work together. And everyone, from every business line, must speak with a single voice. Make sure that there are links to shareholders, the board, and—if the firm is private—investors. Empower the plan to help get in front of the bad news, as opposed to responding to the flurry of media requests.
Build an effective incident response plan. Ensure that the IRP is a fully cross-functional plan with multiple resources from each of the following:
- The executive suite
- Human resources
- Legal/compliance
- Business side
- Customer service
- Information technology
- Information security
- Service desk
- Security incident response team (SIRT)
- Marketing
- Communications.
Update and test the IRP regularly.
Business is not static, and the IRP always reflects the state of the business at the time the plan is written. Build in the appropriate collaboration tools to support updates to the plan at least once a year. When testing the plan, try to make it fail. Organizations learn far more from plan failures than from a smooth, no-issue test. Remember, the goal is not to assign blame; the goal is to find any embedded weaknesses and remediate them quickly. When the real event occurs, a tested and updated plan will assist in recovering faster and at a far lower cost than otherwise.
Engage third-party support.
Establish a retainer agreement with one or more forensic or response firms. Having an independent, objective view is critical to developing a complete picture of the incident. Third parties never make the assumptions that involved parties automatically make about their own businesses. Work with the third-party support organizations to do an annualized security audit.
Engage law enforcement.
Bringing in law enforcement immediately accomplishes two specific goals. First, it establishes that the organization is clearly the victim of the attack and has nothing to hide. Second, it empowers law enforcement to take quick steps to recover any lost assets. In February 2018, the FBI’s Internet Crime Complaint Center (IC3) created a recovery asset team (RAT) to assist victimized organizations in trying to recover lost assets. To date, reports indicate that when the RAT is engaged quickly, recovery rates can approach 70%.
A Matter of Defense
Organizations that lack an IRP should engage a reputable cybersecurity firm to help guide them to develop one. Doing so will be far less expensive than doing nothing.
