Incident Response: Does Your Plan Pass the Test?

Article Incident Response
Incident Response Plan

 

Hopefully none of you reading this are working in an organization that is operating under the assumption that a data breach will never happen. With the continuous flow of stories about successful hacks and unwitting victims (Thanks Equifax), it is more likely a matter of WHEN, and not IF you will be a target. Prevention is the name of the game so it is important that you have all of the appropriate security controls implemented in advance of the attack, and that you have a comprehensive Incident Response Plan in place to quickly identify incidents and respond effectively to limit potential damage.

Requirement 12.10 of the PCI DSS states that organizations must implement an incident response plan (IRP) and be prepared to respond immediately to a system breach. The guidance section for this requirement states, “Without a thorough security incident response plan that is properly disseminated, read, and understood by the parties responsible, confusion and lack of unified response could create further downtime for the business, unnecessary media exposure, as well as new legal liabilities.”

What condition is your incident response plan in? Has one been defined and, if yes, has it been documented and shared across the organization? Many organizations have a plan in place within the IT Department to handle a data breach, but it is important that you include specific steps in the event of a cardholder data breach. Creating an initial draft of your plan can be a little overwhelming, but breaking it up into smaller components can help you manage the effort and ensure you are covering all of your bases.

Below are a few of the main topics you will want to address in your incident response plan:

  1. Contacts/Communications List
    Who should be contacted immediately in the event of a breach? Do you have an incident response team? When should the executive and legal teams be brought in? Is Public Relations necessary? Do you need to notify the affected employees or customers? Knowing who and when to contact personnel is important. Ensure all contact information is up to date. Payment card brand notification procedures should be included as each has a specific set of requirements and timelines you must adhere to. You may also want to include some draft messages with well-thought out bullet points to make sure you are including all necessary information during the event.
  2. Technical Procedures and System Recovery Processes
    What should the average employee do in the event of a suspected breach? Contact the Incident Response Team immediately. Shutting off computers or POS systems can compromise possible evidence so don’t do anything unless instructed to do so. Then what? The Incident Response Team and IT staff will work together to ensure the compromised system is isolated. Make sure that the location of all system configuration and network diagrams are documented in the IRP so the teams can easily locate them. Document the circumstances under which the system should be disconnected from the Internet or network. Included details to help determine what information may have been compromised and how to identify the breach scope. They will need to gather and review all system, firewall, file integrity, and intrusion detection system logs and alerts so include the locations and/or staff member(s) who can help to collect these. Consider including options for containing the breach, like switching to back-up systems. Once the breach has been contained, the team will begin to diagnose the potential gaps through which the attack was launched. The incident response plan should have some preliminary steps for places to look and information to gather for review. For example, they may want to know about any recent security patches or updates that may have been installed. Be sure to include any specific areas or processes that are unique to your organization.
  3. Document, Document, Document
    Designate a central location or log for documenting all actions taken in the event of a data breach. Details should include an overview of the incident, including the date, time, and location of the incident, the incident type, intrusion method, overview of the affected data, persons involved, how the compromise was discovered, any and all actions taken, and the impact the breach has on daily activities. As the team conducts research into the event, screenshots and other data captured by various tools should be retained in the same central location. Consider identifying the document repository, staff members with access, and any other structural requirements for folders and/or documents in the IRP. Defining how the vast amounts of documentation are to be named and saved will assist with the review process down the road. (Isn’t it easier to decide if you want to open a document titled “Screenshot of computer with error message.JPG” than to have to open “Scan13.JPG”?)
  4. Staff Preparation
    The incident response plan should be reviewed and tested at least annually through mock data breaches and incident response drills. Ensure all employees are properly trained on and aware of their individual roles and responsibilities in the event of a data breach. Document, at least by staff title, who is responsible for what and include the escalation procedures in the event someone is away from the office. During the annual review, update any roles and/or titles that may have changed due to changes in organizational structure or assignments. By training and preparing your staff, they will be much less likely to make critical mistakes during a high pressure event.
  5. Lessons Learned
    Following an incident, it is important to analyze the breach, as well as the response efforts to see what weaknesses can be improved upon in the future. Review the gap between when the breach was detected versus when the system was initially compromised, and how it was identified; look for opportunities to reduce that time. Review the scope of the incident and what systems and data were affected. If you are not currently using network segmentation, consider that as an alternate strategy in order to help reduce the reach of a future incident. Are there other tools that can be utilized to ensure a similar attack will not reoccur? Discuss how the team was able to contain the breach and what changes were made to systems during the recovery process. Through this exercise, you will be able to identify potential areas for improvement and outline what parts of the response plan worked and what didn’t.

Having a plan in place will provide your teams with the ability to act quickly to determine the severity of the incident, backup and preserve any compromised data, and return to business as soon as possible.

The last thing you want to waste time doing during a potential data breach is trying to track down lists or determine who is responsible for what. Having a comprehensive incident response plan defined, documented, and rolled out today will save you a lot of time and effort down the road.

To request CampusGuard’s Incident Response Plan template, our Immediate Breach Response Checklist, or examples of table top scenarios you can use to test your plan, contact us.

Some additional guidance from our Security Advisor team below:

[Burt]: Don’t forget to test at least annually!!! Yes, that’s correct, organizations actually have to test the Incident Response Plan (IRP). This is not only a PCI DSS requirement, but an absolute must to be prepared in case an actual security incident or breach occurs. Speaking from past experience, I can tell you that it’s extremely easy to spend months upon months preparing an IRP then eventually forgetting the most important step. Try not to think of the entire exercise as merely checking a box for compliance. That is the main trap most people fall into (e.g. creating the IRP becomes too much like work). Think of it more as protecting/saving your organization and customers from harm or disaster and you will be much better off. At the end of the day, it’s all about being prepared. Have some fun!

[King]: What would you do in an Incident? As overwhelming as that question can sound now, the task of answering it becomes even more so once an incident has occurred or is in progress. Don’t wait until the pressure is on before you make/test/update your plan.

Do your staff know what to do in an Incident? Trained and knowledgeable personnel are key to an effective IRP. Once you have a plan in place, make sure all personnel know what to do when they suspect an incident has occurred. Make sure personnel who are responsible for responding have been trained and know their responsibilities. This is where testing your IRP comes in. Lessons learned in the testing can then be used to improve the plan and minimize losses in the likely event an incident does occur.

Share

About the Author
Katie Johnson

Katie Johnson

PCIP

Manager, Operations Support

As the manager of Operations Support, Katie leads the team responsible for supporting and delivering CampusGuard services including online training, vulnerability scanning, and the CampusGuard Central® portal. With over 15 years of experience in information security awareness training, Katie is also the Product Lead for CampusGuard’s online training services. As a Senior Customer Relationship Manager for a limited number of customers, Katie assists organizations with their information security and compliance programs and is responsible for coordinating the various teams involved.