24/7 Incident Response Team

Even if you’re a small organization, PCI Requirement 12.10.3 requires that you designate specific personnel to be available on a 24/7 basis to respond to alerts. The PCI DSS explains, “Without a trained and readily available incident response team, extended damage to the network could occur, and critical data and systems may become ‘polluted’ by inappropriate handling of the targeted systems. This can hinder the success of a post-incident investigation.”

Breaches don’t work around holidays, birthdays, or anniversaries – a breach could happen at any time. How will your organization meet PCI Requirement 12.10.3?

From a PCI DSS perspective, you’re required to have someone available 24/7 to react in the event of a breach. Where we see most organizations struggle with this is if you’re a small organization, perhaps you’re a one- to two- person show, it gets pretty hard to deal with this during holidays, birthdays, and anniversaries, or even on religious days such as the Sabbath. In that situation, you need to take into account how you want to meet the 24/7 requirement, making sure that in the event that there is a breach that somebody is available to respond to those events.

Testing Your Incident Response Plan

You must test your incident response plan. What’s the point of the plan if you aren’t sure that it works? Without appropriate testing, major steps or gaps could be missed, which could result in increased exposure during a real incident. PCI requirement 12.10.2 states, “Review and test the plan, including all elements listed in Requirement 12.10.1, at least annually.”

To verify compliance with PCI Requirement 12.10.2, an assessor will interview personnel and review documentation from previous testing to verify that the plan is tested at least annually, and that testing includes all elements listed in Requirement 12.10.1.

Your incident response plan needs to be documented, as we talked about, but your plan also needs to be tested at least annually. The purpose of this is to make sure that whatever you have documented is going to function as you believe it is. A lot of organizations kill two birds with one stone; they test their plan annually and as part of that, they also do the education of their incident response program at the same time. What your assessor is going to be doing is looking for some type of artifact that shows that your plan has been tested and that you carried out the plan as defined within your incident response program.

Elements of Your Incident Response Plan

To develop a thorough incident response plan, PCI Requirement 12.10.1 lists out the elements that should be included in your plan. At a minimum, your plan should include:

• Roles, responsibilities, communication, and contact strategies in the event of a compromise including notification of the payment brands
• Specific incident response procedures
• Business recovery and continuity procedures
• Data back-up processes
• Analysis of legal requirements for reporting compromises
• Coverage and responses of all critical system components
• Reference or inclusion of incident response procedures from the payment brands

To verify compliance with PCI Requirement 12.10.1, an assessor will interview personnel to examine your incident response plan to ensure that it contains the elements above.

PCI Requirement 12.10.1 really calls out the program attributes (or the majority of them). We won’t go over all of them, but if you have specific interest in them, I would recommend looking at the PCI Requirement 12.10.1, or better yet, you can give me or your assessor a call and they’ll be happy to work with you on this.

You need to develop a communication plan in the event of a breach. You need to include the payment brands in terms of what to do or how to alert them in the event of a breach. You have to have a notification program. In many of the states and many of the places where you do business, if you are breached and one of the residents of a state that has a notification law is impacted, you’re required to notify them. You’re required to take those things into account. You’re required to document specific incident response procedures such as: what do we do in the event of X? We’re not going to spend a whole lot of time as part of this video series talking about what is a good incident response program, but we do have a webinar where we’ve talked about that, so please look through our webinar series for that information.

Incident Response Plans

PCI Requirement 12.10 requires organizations to implement an incident response plan and be prepared to respond immediately to a system breach. Incident response plans are incredibly important to business continuity, and we believe that organizations should spend more time developing and testing their plan. The absolute worst thing that could happen in the event of an incident is no one knowing what to do next.

There are six basic steps to follow when creating an incident response plan:

1. Preparation – How are you currently preparing for a security incident? What are you doing to prevent an incident? How are you limiting the impact of an incident? Have you tested policies and procedures?
2. Detection and Identification – How would you identify an incident? How do you report an incident? How do you detect malicious activity? Do you have a specific team dedicated to incident response?
3. Containment – Has the appropriate personnel been notified? What evidence should be collected? Have you fully assessed the scope of the damage? How can you prevent further damage?
4. Remediation – Do you have backups in place? Has a complete forensic analysis been performed? Have you cleaned the system? Can you make changes to prevent a repeat incident? How can you test the changes?
5. Recovery – Have you securely restored the system? Do you have continuous monitoring to ensure problem is resolved? Have you replaced any lost files with backups?
6. Lessons Learned – What happened? What gaps can you now identify and remediate? Have you regained your consumers’ confidence? Have you reviewed policies and procedures to prevent future attacks?

PCI Requirement 12.10 requires organizations to implement an incident response plan so that confusion and lack of a unified response do not create further downtime for the business, unnecessary public media exposure, as well as new legal liabilities.

PCI Requirement 12.10 is rather short, sweet, and simple. It says that you need to implement an incident response plan and be prepared to respond immediately to a system breach. This is another one of those controls where organizations really ought to spend a lot more time in developing and correction. The last thing that you want to have happen in the event of a breach is standing around and wondering, “What do we do next?” This program needs to be tested and fully documented. There’s a lot of things that the PCI DSS calls out as it relates to the incident response program, but as part of this particular assessment, your assessors are going to be asking you for a copy of your incident response program and making sure that it contains the attributes that are called out within the rest of the requirement.

Service Provider Responsibilities

If you are a service provider, you must comply with PCI Requirement 12.9, which states, “Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.” PCI Requirement 12.9 functions in conjunction with PCI Requirement 12.8.2 to promote a consistent level of understanding between service providers and their customers about their applicable PCI compliance responsibilities.

The PCI DSS explains, “The service provider’s internal policies and procedures related to their customer engagement process and any templates used for written agreements should include a provision of an applicable PCI DSS acknowledgement to their customers. The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.”

PCI Requirement 12.9 is another one of those requirements for those organizations that are deemed as a service provider. What PCI Requirement 12.9 says is that if you are a service provider, you need to maintain some type of template or contractual language so that when your customers come to you and ask you for an agreement, you have something that says you are going to maintain all of the appropriate controls securely and that you can provide that to them.

What we found in the industry is that a lot of merchants and organizations who use service providers would go to their service providers and ask for this contract language and those service providers would not be able to provide that to them. If the organization that you work with is going to play within this PCI DSS space, it’s required that they provide you with that contractual language, or at least that language denotes that they’re going to be doing things in a compliant way.