PCI DSS & Incident Response Planning

No organization is safe from suffering a security incident. It may take more or less suffer and solve it, be more or less severe, or even can not find out you're having a security incident (no, I will not talk about APTs this time), but at some point your organization will need to respond to an incident.

Therefore, every organization should have an incident response plan consistent with the potential safety impact of a security incident can result for your business. The absence of a response plan security incidents can significantly increase the response time to an incident and may even cause a not adequate response that finish aggravating the incident's impact.

Paragraph 12.10 v3 PCI DSS requires organizations affected by the standard to implement a response plan and be prepared to respond immediately to any compromise on their systems. In this sense, what is required by the standard is the plan includes within its scope all the key elements that are necessary for the organization to respond effectively in the event that the incident might affect the cardholder data. But considered in developing a response plan, I think it is ridiculous to stick only to the scope of PCI DSS because with little more effort we can have a response plan that reaches across the organization and enable us to respond in a effective and efficient way in case of an incident.

Let us see the steps to follow to develop a plan that allows us to meet the requirement of PCI DSS 12.10 but at the time we prepared to act on incidents involving other areas of our organization.

Preparation

In the preparation phase we carry out the following main activities :

1. Clarify the scope of our Plan. Not the same prepare a Security Incident Plan to limit the scope only to incidents of Information Security, safety, property security , etc. To comply with PCI DSS, the scope of the Plan must include, at least, all critical systems within the scope of processing, storage and transfer cardholders data.
2. It should define and document the roles and responsibilities of all participants in the Incident Response Plan.
3. While many management methodologies proposed security incidents conducting a risk analysis, including the recently published NIST cybersecurity framework, I prefer making only one BIA (Business Impact Analysis ) that allows us to be clear what impact can have a incident in different fields (legal, financial , operational, human damage , reputation ). There are different methodologies or approaches for a BIA but my recommendation, especially in a first implementation of the Plan, is to opt for one that is simple enough to have a realistic BIA in a short space of time. Importantly, the BIA should not just analyse incidents that impair the availability of information, since it is not preparing the Plan Business Continuity, otherwise you have to take into account the impacts in terms of loss confidentiality and integrity of information.
4. Define scenarios of incidents that can occur based on the analysis in the BIA. Ie document all those events that can cause major impacts identified in the previous section. It is recommended in a first draft of the Plan will not be overambitious and unify and group enough to guarantee the volume of scenarios is manageable. We did not do any useful if document 500 possible casuistic and then we will take 5 years to write response procedures for each of it...
5. Document the mechanisms established to detect the realization of the scenarios defined in the previous phase. At this stage it is very likely that deficiencies or impossibilities in the detection of some of the scenarios are identified. In cases where feasible, prepare an improvement plan designed to implement controls or improvements to the detection of these scenarios in a tolerable time. In considering the elements that can trigger the process of incident management, PCI DSS requires that, at least, the monitoring systems of the organization are considered, such as IDS / IPS, firewalls or file integrity systems (FIM) events.
6. Documenting the criteria for classification of incidents. You must define a taxonomy and criteria for classifying a potential incident in the relevant category. Again my recommendation is to prime the simplicity. We should not have more than 10 categories for the first level of classification of incidents.
7. Documenting the action procedures in case of realization of each type of incident.These procedures should include or reference the BCP procedures that must be followed if the incident affects the business continuity. Additionally, to comply with PCI DSS, you must include or reference procedures for backup of data as well as any aspect or legal requirement to consider in case of incident. The procedures must include details of actions to be performed for:
1. Contain the incident.
2. Solving the incident.
3. Recover normal operation
8. Document strategies and procedures for communication to a security incident . Ie , what to say, who to say and how to say in each case, or in any case, clearly define who is responsible for making these decisions in case of incident. The damage to the image or reputation of the company can vary greatly depending on what is communicated and how to communicate following a security incident. To comply with PCI DSS these strategies should include, at a minimum, the procedure to communicate any compromise of card data to the payment card brands.
9. The Plan must be communicated and distributed to all concerned and should ensure their availability for a potential incident. That is, if one of our scenarios is that by reason of a DoS we fall our corporate systems, we should not store our Incident Response Plan just in corporate systems, since we can not retrieve it when needed. Also, if one of the scenarios considered is the lack of access to the office, we did not do any good if we only have it printed on our desktop.
10. It should define and establish the necessary way for anyone to notify the responsible occurrence of a possible incident. These routes should be simple, quick and have alternatives in case one of them fails.
11. The incident response team should be adequately trained and with a 24x7 availability to act in case of an incident materialize to prevent the delay in resolution might aggravate their impact and consequences. On the other hand, have well documented procedures and team training are vital to prevent the activities undertaken to resolve the incident may degrade or corrupt the evidence necessary for proper forensic investigation of the incident.
12. You need to plan a test plan that allows a high degree of assurance that the proposed Plan works correctly in case of incident. Testing will be performed at least annually, are critical to ensure that the defined procedures are truly effective and that all affected personnel have necessary knowledge thereof.

During the incident.

During the incident should note the following:

1. It must follow the procedures defined in the Plan in each case.
2. You must keep a detailed log of all the events and actions carried out during the incident.
3. You should prioritize containment incident.
4. Once content, you must proceed to its resolution.
5. Finally, once resolved, should proceed to the recovery of the affected systems.

Continuous Improvement.

PCI DSS requires that a specific section of continuous improvement is included in the incident response plan so that the action and resolution in each security incident is analysed to detect areas improvement in the processes of incident detection or response.

To do this, you must analyse the outputs, understanding what happened and why it happened, for each of the incidents suffered as well as the tests done and analyse what improvements can be made in the Plan in several areas:

• Improvements in the prevention of incidents.
• Improved detection of incidents.
• Improved containment and resolution of incidents.
• Improved recovery of equipment or business.
• Improvements in the test plan.
• Improvements to the defined incidents scenarios.
• Improved staff training or awareness.

Finally , it is also important to consider the plan within the change management of the organization, so that the Incident Response Plan is updated whenever changes in systems or in the organization leave obsolete any of the incident response procedures.

In short, it is to have a documented plan, distributed, tested and known to allow act in the best way and in the shortest possible time when a security incident happen in order to minimize the impact and consequences that the incident can cause to the organization.