In a previous blog, we introduced the importance of a Computer Security Incident Response Plan (CSIRP). We reminded our readers that security breaches are virtually inevitable, and can involve thousands of data records while costing millions of dollars. A CSIRP can help reduce the cost and mitigate the severity of breaches. Based on experience working with companies of all sizes, we’d like to share some advice for building and maintaining an effective CSIRP.

In this blog we will highlight the ten most common shortcomings of CSIRPs we encounter and how you can avoid these potentially costly mistakes.

1. Making a CSIRP too complex

When designing your CSIRP, it is best to keep in mind that the audience will be reading the document during a crisis. There will be stress, chaos and, of course, urgency. Some individuals will be panicked and worried about their jobs. Executives who may or may not understand the fine technical points of what is happening will be distressed if the news media is asking questions.

CSIRPs must be crisp, clear and concise. If an employee who is unfamiliar with the document cannot quickly examine the processes described within the CSIRP, understand the chain of command and perform the necessary actions, your CSIRP may be too complex. Of course, making a CSIRP too simple is also a potential pitfall; striking the right balance between brevity and actionable direction is essential to a successful CSIRP.

2. Overloading key personnel

Every organization has a “Joe.” Joe knows everybody and every system, router, cable and coffee machine in the building. Joe is the person to whom we all look during an incident. Joe, undoubtedly, is the best person around for minor incidents and can handle them from beginning to end. When we develop CSIRPs for our customers, we quickly find the “Joe” of the organization during our standard questioning: Who is in charge of anti-virus? Joe. Who takes the lead on technical response? Joe. Who communicates with executives and regulatory authorities? Joe

Joe is fantastic at what he does during the regular workday. However, when an incident stretches on for multiple shifts or even days, Joe can’t be your go-to guy for 72 hours straight. Separating duties during an incident and distributing them across designated, trained staff is necessary if an organization does not want sleep-deprived, overloaded—and thus less effective—employees responding to incidents.

3. Treating incident response as a serial process

During a large-scale incident, multitasking is essential. Managers who look at incident response as a serial process are doomed to failure when it comes to resolving an incident in a timely manner. While each incident is unique, all incident responses are comprised of a number of short-term efforts. Pushing out new anti-virus signatures, patching systems, leading investigative efforts, informing employees and customers of your current status, fetching additional supplies of caffeinated beverages and other important tasks are all individual processes and should be treated as such. A common failure is focusing on only one of these tasks at a time and neglecting other important tasks that should be completed in parallel.

4. Failing to establish proper lines of communication

When responding to an incident, potentially many different individuals and vendors will be asked to assist. The individual responsible for managing the “‘boots on the ground”—the incident manager—must be a master communicator. Communication must be orderly, efficient and follow the proper channels to ensure that all parties involved in the response are kept informed and coordinated. Within an organization, this could include technical teams as well as those responsible for physical security, human resources, compliance, regulatory affairs and risk management. External communications are also crucial, requiring that someone is clearly designated as responsible for providing timely and factual updates to your organization’s public relations, media relations, customer affairs and marketing focal points. Many an organization has damaged the trust of stakeholders by failing to communicate quickly and openly about security incidents.

5. Focusing on what’s easy, not what needs to be done

During almost every incident, the urge arises to focus on the easy tasks versus what needs to be done. This is akin to filling up the window washer fluid on a car when the engine won’t start. While resolving a security incident, it is tempting to focus too heavily on easy tasks like static evidence gathering—for example, capturing hard drive images—rather than challenging tasks like performing analysis. But regardless of difficulty, all tasks need to be completed. Failing to focus your energy on the essential problems, whether easy or hard, will only cause prolonged headaches and prolonged incidents.

6. Focusing on what’s interesting, not what needs to be done

During some incidents, the responder will discover some bits of interesting information and become focused on a chase down an unrelated path. A common source of diversion is finding inappropriate user activity such as browsing sites that are off limits. This newly discovered information may be extremely captivating, but if it does not play a material role in the incident you are investigating, it should be set aside for later research. Endless hours can be spent on this sidetrack, consuming time that you can’t afford to lose. Stay focused on resolving the incident and save the exploration for later.

7. Abandoning the CSIRP

The urge will occasionally arise to throw out the CSIRP because it doesn’t address the specific situation at hand. There is a reason why the document does not address the latest email virus or Trojan horse. The CSIRP is not meant to be an all-inclusive guide on how to confront every specific type of incident; rather, the document is a blueprint for lines of communication, roles, required notifications and steps to be taken to respond to any security breach.

Although each incident is entirely unique, a flexible and well-constructed CSIRP will allow for a response to be formulated quickly by identifying the key people who should be included, their roles, and your communication protocols. With this structure in place, the necessary steps may then be taken to address the technology behind the incident at hand.

8. Making a policy, not a plan

Always remember that the “P” in CSIRP stands for “Plans” not “Policy.” Occasionally, we review a CSIRP that reads more like a policy document rather than a plan. What is the difference? A plan comprises actionable steps and roles while a policy states overarching guidelines to be applied within the organization. When an incident occurs, do you really want to be reading company policy in order to formulate a plan? Of course not. You would like a well thought out plan that tells you what to do.

9. Failing to assign an owner and keep the plan up to date

Your CSIRP has a lot in common with your garden. Both develop over time, require maintenance and attention, and should have owners responsible for their well-being. When you establish a CSIRP, an owner should be assigned to the document. This means a specific person, not a department or a position, is tasked with maintaining the document, ensuring that the personnel and procedures contained within are still relevant, and coordinating annual testing.

Without a specific owner, the document may languish, becoming stagnant and possibly causing increased response times to incidents. Moreover, to be effective, this person needs to have executive support for the ownership role or be in a high enough position to allocate resources for testing and updating.

A CSIRP should be updated regularly, at least twice a year, as well as after significant events such as completion of a merger or acquisition, major infrastructure or personnel changes, or a cyber security incident. On average in working with clients, we see CSIRPs being updated every 18 to 24 months—although in our experience it is not uncommon to see a CSIRP that has not been updated in five years. In the eventuality that an incident occurs, this out-of-date document is brought out, dusted off and the response team quickly finds that key personnel named in the plan are no longer with the company or have moved to other roles. The unfortunate end result is a delay in response—with potentially significant consequences.

10. Skipping the incident closeout process

The most valuable lessons from any incident can be learned from the after-action review. Prior to an incident being officially closed, the best practice is to hold a lessons-learned meeting where you can evaluate the effectiveness of the CSIRP (how well did it work?) and document a root cause as well as other findings.

Even if it seems like everything went as planned during an incident, it is likely that an after-action review will nevertheless bring potential improvements to light. Identifying mistakes or issues that need to be changed will only make the CSIRP stronger and more able to address your needs during future incidents. Although your response team may be eager to put the past behind them and return to normal operations, this final step should not be neglected—it is often the most important part of the incident response process.

How sound is your CSIRP?

Does your organization have a formal, documented Computer Security Incident Response Plan—and if so, when is the last time your CSIRP was updated? If your answers are anything other than “yes” and “within the last six months,” you’d probably benefit from talking to an IT security expert from outside your company.

Schedule a consultation to learn more about strategies for minimizing costly security breaches.

If you liked this blog, you also might like:  Responding to a Cybersecurity Incident – Dos and Don’ts

Stay connected online:

Facebook | Twitter | LinkedIn | Instagram