Monitoring Mechanisms in Incident Response Plans

PCI Requirement 12.10.5 states that your incident response plan should, “Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion-prevention, firewalls, and file-integrity monitoring systems.” We’ve talked about these monitoring mechanisms in PCI Requirement 10 and PCI Requirement 11, but what do they have to do with incident response? The PCI DSS explains, “These monitoring systems are designed to focus on potential risk to data, are critical in taking quick action to prevent a breach, and must be included in the incident-response processes.”

[av_toggle_container initial=’1′ mode=’accordion’ sort=” styling=” colors=” font_color=” background_color=” border_color=” custom_class=”]
[av_toggle title=’Video Transcript’ tags=”]

Back in PCI Requirement 10, we talked about logging, log review, and responding to anomalies. Understand that everything that shows up in a log is an event, but it isn’t an incident. It’s not an incident until such a time that your organization has triaged that event and defined that there is something that needs to be reacted to.

Your incident response plan needs to include the file integrity monitoring, your IPS/IDS, and all of those things that you’re capturing logs from. It’s not sufficient enough to have these systems creating these logs. We have to be reviewing these logs and including the log review process. When we identify that this event is now an incident in terms of what needs to be done next, that information is specifically called out in your incident response plan.

[/av_toggle]

[/av_toggle_container]

Training Your Incident Response Team

PCI Requirement 12.10.4 requires that your organization provides appropriate training to staff with security breach response responsibilities. One type of training that we recommend is table-top incident response exercises. Experts suggest that participating in table-top exercises to simulate a real-world scenario is the best way to prepare and test your incident response plan. When facilitating these exercises at your organization, be sure that the employees understand the purpose for conducting the exercises. They should understand that participating in these exercises will help determine if everyone can hypothetically talk through their respective functions during an incident and be sure everyone fully understands their role when responding to an actual incident.

The facilitator should present a scenario and from there, participants will engage in a discussion that focuses on roles, responsibilities, coordination, and decision-making during an incident. Prepare several scenarios in advance that will address specific areas of your Incident Response Plan you wish to test. Some sample scenarios include:

• During a routine evaluation of system logs, an administrator discovers that company data has been obtained by an unauthorized user account.
• A remote user has lost his/her laptop containing stored sensitive company data.
• After a recent move, it has been discovered that a locked cabinet containing sensitive company data is missing.
• A former employee, disgruntled after employment termination, has realized that he/she still has remote access to the company’s server and decides to infect the system with a virus.

To verify compliance with PCI Requirement 12.10.4, an assessor will interviews of personnel and observe training policies.

You’re required to provide appropriate training to staff with security breach response responsibilities. Once again, we’re looking for some type of evidence that you trained your staff and what were the things that you trained your staff for. We’re also looking to see that there’s some type of marriage between what you’ve trained them and your actual documented incident response program.

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.