Documenting Your Review Process

The final requirement in PCI Requirement 12 works in conjunction with PCI Requirement 12.11. PCI Requirement 12.11.1 mandates organizations to maintain documentation of a quarterly review process, which should include documenting results of the reviews and review/sign-off of results by personnel assigned responsibility for the PCI DSS compliance program.

Why are PCI Requirement 12.11 and PCI Requirement 12.11.1 listed separately? The PCI DSS explains, “The intent of these independent checks is to confirm whether security activities are being performed on an ongoing basis. These reviews can also be used to verify that appropriate evidence is being maintained—for example, audit logs, vulnerability scan reports, firewall reviews, etc.—to assist the entity’s preparation for its next PCI DSS assessment.”

The last requirement within the last requirement of the PCI DSS is PCI Requirement 12.11.1. PCI Requirement 12.11.1 says that if you are a service provider, you have to implement a program where your management is receiving all of the documentation about your program and they’re signing off on it.

Understand that management is responsible for the overall security. They might delegate that responsibility to somebody else within their organization, but really at the end of the day, they own it, they broke it, they bought it, it’s theirs. PCI Requirement 12.11.1 says that they’re receiving that information, they’re managing that information, and that they’re well aware and signing off on that after having received it.

Reviewing Your Personnel

If you are a service provider, your organization must comply with PCI Requirement 12.11. It requires that you perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. These reviews must cover the following processes:

• Daily log reviews
• Firewall rule-set reviews
• Applying configuration standards to new systems
• Responding to security alerts
• Change management processes

The PCI DSS explains, “Regularly confirming that security policies and procedures are being followed provides assurance that the expected controls are active and working as intended. The objective of these reviews is not to re-perform other PCI DSS requirements, but to confirm whether procedures are being followed as expected.”

If you’re a service provider, once again the PCI DSS calls out another specific requirement for you. PCI Requirement 12.1 says that if you are a service provider, you have to have a program in place that’s performed at least quarterly, making sure that your security program is still functioning. For example, your log review program, your firewall route reviews, and your scanning – all of those things that go into the daily care and feeding of your information security program. What we’re going to be looking for if you’re a service provider is that you actually have a program in place for monitoring and then taking corrective actions in the event that you find out, for some reason, your program has failed and it’s no longer working.

Modifying Your Incident Response Plan

Your incident response plan should be able to easily modify so it can be as thorough and up-to-date as possible. PCI Requirement 12.10.6 says, “Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.” This is sort of a management exercise to analyze what could’ve been done better during incident response and to keep your incident response plan current and able to react to emerging threats and security trends.

PCI Requirement 12.10.6 defines that after you have an incident or after you’ve practiced your incident response plan, you have “lessons learned.” Understand that this is not really about that Johnny did good and Susie did bad; this is really a management exercise to identify what you did good and what you could have done better. It’s really meant to evolve your practice to the next level. We look for evidence that you perform this process of evaluation, making sure that you look at what are the new incidents and types of events that could impact you. We’re also making sure that your organization has that documented after an incident or a practice incident response as a requirement and that you retain evidence of that occurring.

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.