Incident Response in PCI DSS

Incident response is a critical process in every organization. If you are processing or storing credit cardholder data, it becomes even more important and can impact your compliance with the PCI DSS standard. In this article, we’ll cover the basics of PCI DSS and explain how you should adapt your incident response process to comply with the standard and ensure the required level of protection for sensitive credit card information.

What is PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) is a collection of security standards regulating the use of credit card information. It was formed in 2004 by MasterCard, Visa, Discover Financial Services, JCB International, and American Express.

The Payment Card Industry Security Standards Council (PCI SSC) is the entity that governs the PCI DSS. The purpose of the standard is to prevent fraud and data theft by securing debit and credit card transactions.

The PCI council does not have the legal authority to enforce compliance. However, PCI DSS is a mandatory requirement for all organizations processing debit and credit card transactions; organizations who fail to comply may be fined by their payment processor, and in extreme cases, can be blocked from performing credit card transactions.

Organizations can get a PCI certification if they meet certain requirements established by the PCI council. Some common security measures mandated by PCI DSS are the use of firewalls, antivirus software, and data protection measures such as encryption, intrusion prevention systems, and data loss prevention (DLP).

PCI DSS Incident Response Requirements

When implementing an incident response procedure in an organization impacted by PCI DSS, you should take into account two main PCI DSS requirements:

• Requirement 10—Implement Logging and Log Management
• Requirement 12—Documentation and Risk Assessments

Below we describe each of these in more depth and how they can affect your incident response operation.

PCI DSS Requirement 10: Implement Logging and Log Management

Requirement 10 stipulates that a merchant must “establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.”

Requirement 10 was created to ensure the reliable and safe transfer of credit and payment card data through the use of monitoring and analysis of system activity logs. To comply with this requirement, organizations need to protect customer data against many types of threats.

Complying with Requirement 10

Requirement 10 security controls are a common contributing factor to data breaches. System event logs record small bits of information about actions performed on printers, office computers, firewalls, and other systems. Logs can help detect threats and weaknesses. However, to truly be useful, logs should be regularly reviewed.

Requirement 10 stipulates that logs must be reviewed on a daily basis, at the very least. Logs should be searched for anomalies, errors, and any suspicious activities deviating from the norm. Additionally, to comply with Requirement 10, organizations are asked to set up a process for responding to the anomalies and exceptions detected in their logs.

Log monitoring systems can help you gain visibility and control over logs, especially when this functionality comes built into your security information and event monitoring (SIEM) solution. Log monitoring functionality can store user actions occurring within the ecosystem, monitor and inspect system events, and push alerts when suspicious activity is detected.

How Requirement 10 Impacts Incident Response

This requirement specifies how you should record and monitor logs to identify security incidents. Logs are one of the main ways to identify and triage security events in an incident response process. To ensure your incident response is PCI DSS compliant, implement compliant logging systems, and ensure log anomalies are reviewed by security staff at the required frequency.

PCI DSS Requirement 12: Documentation and Risk Assessments

PCI DSS requirement 12 stipulates that all policies, documentation, procedures, and any evidence related to the security practices of the organizations must be safely stored.

During assessments, a Qualified Security Assessor (QSA) usually checks that company policies and procedures (P&P) document and define the relevant PCI requirements. Next, QSAs follow a predefined testing procedure designed to ensure that all relevant policy controls have been implemented in compliance with the PCI DSS.

Complying with Requirement 12

To comply with Requirement 12, your organization must include certain information in its PCI documentation, including employee manuals, third-party vendor agreements, policies and procedures, and incident response plans.

In addition to documentation, the organization must perform a formal risk assessment on an annual basis. This assessment must identify critical assets, vulnerabilities, and threats. It can help organizations in the identification, prioritization, and management of information security risks.

How Requirement 12 Impacts Incident Response

To be compliant, ensure your incident response process is comprehensively documented and that any change to the process is documented as well. In addition, it is not sufficient to perform ad-hoc improvements to incident response processes or post mortem after major incidents. PCI DSS requires you to conduct a full threat assessment, document your findings, and incorporate the results of the assessment into your incident response process. Specifically, you will need to develop and document incident response procedures for every major threat.

How to Implement a Successful Incident Response Plan for PCI DSS

Beyond specific adjustments you may have to make in light of PCI DSS Requirements 10 and 12, take the following steps to implement a PCI-compliant incident response process in your organization:

1. Identify and prioritize critical assets—identify where your sensitive data and mission-critical applications are located. Make a list of these critical assets, which will cause heavy damage to the organization if compromised. Classify assets into risk groups and define a protection plan and budget for each group.
2. Establish procedures and policies—create clear, well-documented procedures for personnel to follow when an incident occurs. The process should detail the role of operational and security staff, when and how to escalate the incident, internal and external communication protocols, and when to enlist help from third parties like consultants, legal, or PR.
3. Establish an incident response team—you must have a team of individuals, who may be dedicated full time to incident response or take on this responsibility alongside a related role in IT operations or security. Each member of the team should have clear roles and responsibilities in case of a cyber incident.
4. Educate all stakeholders about the incident response plan—a cyber incident can affect different parts of the organization, from IT to software development, legal, HR, and public relations, all the way to senior management. All relevant stakeholders must be aware of your incident response plan, and should also be encouraged to provide inputs from their perspective. This will ensure that when a cyber incident occurs, everyone is aligned on the steps that should be taken, and roles and responsibilities are clear.
5. Get buy-in from senior management—an incident response plan cannot succeed if senior management is not involved. This is especially true if incident response measures require a budget—for example, to procure security tools, leverage third-party security services, or perform training and certifications for staff. Present the incident response plan to management, explain the security and compliance implications, and the business benefits of incident response to the company.
6. Security training for employees—incident response will not be effective without security awareness and a culture of secure business practices. Conduct regular security training for all employees, and ensure everyone in the company knows how to recognize and avoid social engineering, and is aware of their responsibility to prevent and actively report security violations.
7. Test your plan—incident response plans cannot remain on paper until an incident occurs. Validate your plans using tabletop exercises involving all relevant staff. Conduct regular, realistic drills and exercises to ensure your team can work together effectively when an incident occurs. After every tabletop or simulation, review the incident response plan to identify gaps and update it to address them.

Conclusion

In this article I covered several ways PCI DSS compliance impacts incident response:

Requirement 10 specifies how you should log events and review log data, as part of security event triage and detection of security incidents.

Requirement 12 specifies that your incident response process must be formal and documented, and must be informed by an annual threat assessment.

Beyond these specific requirements, you must implement an incident response process that prioritizes critical assets, establishes a clear process and a well-defined incident response team, is shared with stakeholders across the organization, and includes education for management and employees (even if they are not directly involved in incident response).

I hope this will be of help as you move closer to a secure, PCI-compliant IT environment.

PCI Hosting with Atlantic.Net

Contracting with Atlantic.Net for PCI web hosting gives you peace of mind that your provider knows what they’re doing. Atlantic.Net is SOC 2, SOC 3, HIPAA audited, and PCI ready, providing clients with the hardened, secure, and compliant infrastructure they need.