The Incident Response Plan according to PCI DSS

Transcription

1 The Incident Response Plan according to PCI DSS In today s IT based world of work, the reliable functioning of important information systems is indispensable for a smooth business operation. That is why information security is rapidly gaining in importance within a society that is becoming more and more information driven. Therefore an especially fast and also coordinated reaction to security incidents should be essential for most companies. Due to the complexity of today s system landscapes and the accompanying risk situations for the organisations concerned, the amount of potential security incidents is extensive or even unmanageable. Information and IT systems are almost constantly exposed to changing threats of any kinds. Therefore organisations do not only have to take further security efforts for the safety of their IT infrastructure, but also to make preparations for the event of an actual security incident. Therefore it should be guaranteed that in case of a security incident it can be reacted as quickly and coordinated as possible but most important in an adequate way. This way, potential damages due to the particular security incident should ideally be prevented or at least restricted to a minimum and the ability to act for the company should be sustained. Since this is an essential part of every holistic security concept, the PCI DSS in its current version of July 2009 takes up the topic and stipulates in requirement 12.9 important aspects which absolutely have to be considered in an Incident Response Plan. What characterises a security incident? Prior to dealing with the contents of the incident response plan it has to be clarified what exactly in the sense of PCI DSS has to be understood as a security incident. Requirement 12.9 includes the following statement: Be prepared to respond immediately to a system breach. [PCI DSS Requirements and Security Assessment Procedures, Version 1.2.1, July 2009] A system breach can assume various dimensions, which can, depending on the situation, become harmful down to threatening the existence of the organisation. Generally speaking an organisation experiences a security breach in the more trivial variation as a harmless disturbance that leads to an unexpected malfunctioning of processes or resources. In comparison, the dimensions of a dramatic variation of a security breach is a potentially existence threatening situation, whose occurrence might let the business processes come to a standstill or can be accompanied by financial damages which cannot be compensated. In the scope of PCI DSS, security breaches are defined as events that lead to a compromise of cardholder data or that threaten the security of the already processed card data. Security incidents include for example unauthorized access to credit card data processing network components and systems or the manipulation of their configurations and log files, the emergence of unauthorized WLAN access points in the particular network or simply the abusive or even criminal access on cardholder data. Mai 2010 SRC Security Research & Consulting GmbH Page 1 of 5

2 Dealing with security incidents and contents of the incident response plan In case such a security incident occurs, it is essential to avert immediate damages or to limit those damages as far as possible in case those have already been caused. To guarantee an appropriate reaction also under the additional pressure of an urgent security incident clearly defined policies have to exist for the employees that are responsible for incident response. This especially includes communication channels, escalation procedures as well as important processes for the reporting and the handling of security incidents. Those aspects have to be documented within a superordinate incident response plan which is applicable for identifying a security incident. Since an appropriate reaction is indispensable also in case of an impending, a suspected or actual compromise of cardholder data, the PCI DSS specifies in requirement some aspects that have at least to be considered in the developing of an adequate incident response plan. Those aspects should be explained briefly in the following: Definition of roles and channels of communication (requirement ) To provide the responsible employees with the information necessary for the incident response also in hectic times of a security incident, the clear definition of roles and communication channels is essential. Especially in case of seldom occurring events as security incidents the uncertainty exists of who to inform and who has to make decisions regarding how to react to a security breach. In case of threatening security incidents stress, strain and time pressure have to be expected which further impede internal communication. For not wasting time in case of a security incident searching for the right person in charge, the incident response plan should include the clear definition of roles and communication channels but also escalation procedures. In the ideal case it also includes contact data of the persons in charge e.g. in the form of an appendix. For instance the incident response plan should clarify who has to be informed in case of a security incident and when the information has to take place (at the time of a suspected breach due to certain security events or after the verification of a suspicion, meaning an actual security incident). Also it has to be clarified when external parties (such as law enforcement agencies, contracting parties or the public) have to be informed. According to requirement 12.9 it is mandatory to inform the affected payment brands in case of a credit card compromise. If applicable, it can be sensible or even necessary depending on the contractual situation to also inform the acquirer. Analysis of legal requirements for the reporting of compromises (requirement ) Depending on the location of an organisation it is subject to the nationally applicable law. Since the data protection or consumer protection law can vary substantially according the country of application, the PCI DSS requires an analysis of legal regulations for the reporting of data compromises. If there is the necessity to inform the public and also the law enforcement agencies about the compromise this has to be included into the defined communication channels. In Germany, for example, the innovation of the data protection act (of ) has to be considered in this context. Especially 42 is interesting regarding the processing of card data. It states: If a ( ) body ( ) determines that ( ) personal data concerning bank or credit card accounts it has recorded have been unlawfully transferred or otherwise unlawfully disclosed to third parties, threatening serious harm to the rights or legitimate interests of data subjects, Mai 2010 SRC Security Research & Consulting GmbH Page 2 of 5

3 then the ( ) body shall notify the competent supervisory and the data subjects without delay( ) Clear designation of responsibilities to roles (requirement ) To act promptly and especially adequately to a security incident, persons are required who are technically qualified and specially trained. For redundancies not to occur when handling a security incident, those roles defined above have to be assigned to clear responsibilities. That way it will be guaranteed that during the handling of the incident no insecurities come up concerning the competences or the scope for action. For every person involved not only his or her own powers of discretion but also the authorities of superordinate persons have to be explicitly defined. For example, it has to be defined who is responsible for the coordination in handling a security incident and who is responsible for the selection or implementation of counter measures. Also when selecting counter measures, competences have to be explicitly regulated. In case of immediate reactions on security incidents time (among other things) plays an important role. Therefore short approval processes should be in place to permit immediate investments or far reaching counter measures (such as shutting down systems). It can prove to be sensible to provide an experienced incident manager with emergency authorities that clearly exceed his competences of normal operation. Covering all critical components (requirement ) Since security of credit card data is not only threatened by security incidents on card processing systems, but also by compromises of security relevant systems, the PCI DSS requires to cover all critical components within the incident response plan. For example the failure of a PCI DSS relevant firewall, the triggering of an IDS/IPS alert or the alert of a virus scanner must be covered by the incident response plan. A Business recovery and continuity strategy (requirement ) To prevent that security incidents lead to an interruption of the running operations the incident response plan has to include strategies to keep up operation during and following a security incident as well as strategies to business recovery after serious failures. Therefore all essential IT components for an appropriate business operation have to be preventively identified and their restart time should be known. Backup concept (requirement ) To guarantee the recovering of defined system states after a serious interruption of business operation or after a compromise of systems, a stringent backup concept has to be linked to the incident response plan. Furthermore in case of some security incidents it might be necessary to backup compromised system states for further investigation of the incident. For example this can be necessary in the course of securing evidence for forensic analysis e.g. of attack vectors or for subsequent error analysis. The instruction to perform a forensic backup if necessary therefore has to be included within the incident response plan. Reference or inclusion of incident response procedures of the payment brands (requirement ) Mai 2010 SRC Security Research & Consulting GmbH Page 3 of 5

4 The payment brands possess specific procedures for the handling of security incidents which have to be included in the incident response plan or at least have to be referenced. Currently, those procedures can be found for example under the following URLs: Master Card Fraud Prevention: VISA USA What to do if compromised VISA USA If Compromised VISA EU In case of compromise VISA EU What to do if compromised Here it has to be considered that the links mentioned above or the information contented might change, which makes necessary a regular verification of adopted links in own documents. Specific incident response procedures (requirement ) Concluding, specific procedures should be elaborated which define guidelines for particular critical situations. Which specific events have to be covered, depends on the respective threat scenarios of the organisation. A card issuer for example has to define particular guidelines to incorporate characteristics in handling sensitive card data (CVC2/CVV2, track data or PINs). Furthermore it has to be considered that the PCI DSS explicitly states in requirement 11.1 that a defined reaction to the detection of an unauthorized WLAN access points is required. Operation and development of the incident response plan The above mentioned aspects are an essential part of a documented incident response plan. However the existence of such a plan alone cannot be a guaranty for the appropriate handling of security incidents. Just as important is a correct handling of the incident response plan as well as its regular development and maintenance. For this reason, the PCI DSS defined requirements to with further specifications that have to be considered in conjunction with the incident response plan. Also those aspects should be highlighted briefly in the following. Testing of the incident response plan (requirement ) To guarantee that the incident response plan is always appropriate, also in light of changing threats and complex system landscapes that constantly develop, it has to be tested at least once a year. With that, also the employees responsible for the incident response will get trainings and become more confident in handling the incident response plan. For example those trainings can be Mai 2010 SRC Security Research & Consulting GmbH Page 4 of 5

5 performed on the basis of particular scenarios. Here the employees responsible are confronted with one or more fictitious scenarios and based on those have to act through the processes of the incident response plan. Since those tests should simulate various security incidents, it should be made sure that a real incident is not seen as yet another test in day to day business. The incident response plan should basically cover all potential incidents. If you consider the incident response plan as an imaginary decision tree, every potential incident takes up its own path within the decision tree. In the long run, those paths which are run through in case of actual incidents should provide only relatively little scope for further optimisation due to the routine gained (optimisation will especially take place due to "Lessons Learned" as defined in requirement 12.6). The testing of the incident response plan is used to also improve those paths which could not be optimised on the basis experienced real incidents. When testing the incident response plan scenarios should be taken as basis which have not already been covered by actual incidents of the past to guarantee a comprehensive optimisation of the incident response plan. 24/7 reactivity (requirement ) Due to the fact that security incidents take place not exclusively within the usual core times, an operational readiness has to be ensured round-the-clock to react on security incidents at all times. Thus, at least one qualified person should be available at all times to initiate an immediate emergency response and to implement the incident response plan. Without a 24/7-on-call duty there is the danger that security incidents that happen outside the working hours will remain undetected until the next morning (or in the worst case over the whole weekend). That way the possibilities can be reduced severely to fend off emerging incidents or to reduce the measure of damages of incidents that already occurred. Training of personnel for incident response (requirement ) Not only attack methods and also attackers change (script kiddies vs. organised criminality) but even processes and methods of incident response and forensic evaluation of security incidents are in flux. This leads to the necessity to regularly perform trainings with employees responsible for incident response. Finally, an incident response plan is just as good as the people that implement or respectively live it. Inclusion of system alerts (requirement12.9.5) Often alerts of surveillance systems such as Intrusion Detection / Prevention Systems (IDS/IPS) or File Integrity Monitoring Systems are the first targets of attacks, attack preparations or even compromises. For this reason it is necessary to consider those alerts (security events) of such systems and to verify specifically if those alerts indicate a security incident or not. Development of the incident response plan (requirement ) The incident response plan has to be adjusted to constant progress of attackers, their methods of attack and also new forensic methods. Here also possibilities of the plan s optimisation can be taken into account. Those include processes to evolve the plan by means of new findings of science or new technical possibilities as well as processes which enable a reprocessing of past events and if necessary an adjustment of the incident response plan by means of the insights gained by past incidents. Mai 2010 SRC Security Research & Consulting GmbH Page 5 of 5