Incident Response Procedures

What would your organization do if an unauthorized wireless device was detected in your environment? PCI Requirement 11.1.2 requires that you implement incident response procedures so that in the event of some type of rogue wireless device, your employees know exactly how to respond. The size and complexity of your environment will determine what your incident response procedures should be. To verify compliance with PCI Requirement 11.1.2, an assessor will ensure that incident response procedures include instructions on unauthorized wireless device situations.

We believe that there are six basic steps in effective incident response procedures:

  1. Preparation – How are you currently preparing for a security incident? How are you limiting the impact of an incident? Have you tested our policies and procedures?
  2. Detection and Identification – How do you detect malicious activity? Do you have an Incident Response Team?
  3. Containment – Has the appropriate personnel been notified? What evidence should be collected? How can you prevent further damage?
  4. Remediation – Do you have backups in place? What changes can you make to prevent a repeated incident?
  5. Recovery – Have you securely restored the system? Do you have continuous monitoring to ensure problem is resolved?
  6. Lessons Learned – What happened? What gaps can we now identify? Have we regained our customers’ confidence?

To learn more about effective incident response procedures for PCI Requirement 11.1.2 compliances, visit these resources:

Incident Response Planning: 6 Steps to Prepare your Organization

What Is an Incident Response Plan? The Collection and Evaluation of Evidence

Conducting Incident Response Plan Table Top Exercises

If your organization should identify that there is a rogue wireless device or a device that was not authorized to have been installed within your environment, you need to maintain those activities within your incident response program. As part of the test, your assessor is going to be asking about your incident response program. They are going to be looking to make sure that wireless has been called out and what to do as a procedure in the event that wireless has been identified.

Regular Testing

PCI Requirement 11 is about managing the security of your environment. It states, “Regularly test security systems and processes.” From everything we’ve learned in the PCI DSS so far, we know that it’s required us to:

  • Harden our networks
  • Harden our systems
  • Protect data in storage
  • Protect data in transmission
  • Protect systems against malware
  • Ensure that system and applications are developed securely
  • Restrict access to cardholder data based on business need to know
  • Implement identity management procedures
  • Protect cardholder data from physical harm
  • Track and monitor all access to resources and cardholder data

Now, in PCI Requirement 11, we want to regularly test security systems and processes to ensure that everything is working as it’s supposed to. This testing should be of wireless access points, incident response procedures, vulnerability scans, penetration testing, intrusion-detection, change-detection, and policies and procedures. Regular testing ensures that new vulnerabilities are caught by the right people and measures are taken to protect against new threats. Recognizing that you have an ever-changing environment will help you see the value in PCI Requirement 11.

PCI Requirement 11 is about managing the security of your environment. If you think about this from the way that the PCI DSS flows, PCI Requirement 1 is about hardened networks; PCI Requirement 2 is that we’ve hardened our systems; PCI Requirement 3 is that we’ve protected our data in storage; and PCI Requirement 4 is that we’ve protected the data in transmission. For example, we’re applying antivirus to protect from malware, we’re patching our servers, we have change control, we’re developing software securely, we have authorization and authentication, we have good passwords, we’re logging everything, and we have physical controls around our environment. When we get to PCI Requirement 11, it is about testing the efficacy of our overall security program and making sure that it is working as we have defined it.

Implementing PCI Requirement 10

PCI Requirement 10 states, “Track and monitor all access to network resources and cardholder data.” Complying with PCI Requirement 10 is critical to ensuring that you know who had what access to cardholder data. For this requirement, we’ve discussed aspects of tracking and monitoring access to network resources and cardholder data, such as how to implement audit trails, what should be documented in logs, which failures you should be notified of, how long to retain audit trail history for, and more. But, as we’ve learned, it’s not enough just to learn and talk about these things. All policies, procedures, and standards must be implemented in order to comply with PCI Requirement 10.9.

PCI Requirement 10.9 states, “Ensure that security policies and operational procedures monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.” This is not only saying that your organization needs to maintain documented security policies and operational procedures; the policies and operational procedures need to be known and in use by all relevant parties. It is not sufficient that you generate documentation just for the sake of the audit. It is a requirement of this framework that the affected parties use the policies and procedures. Your assessor should be reading these documents, be familiarizing themselves with the policies and procedures, and be interviewing staff to make sure that anybody who is subject to the policies and operational procedures understands what they are. If PCI Requirement 10.9 is not met, your cardholder data could be left vulnerable.

[av_toggle_container initial=’1′ mode=’accordion’ sort=” custom_class=”]
[av_toggle title=’Video Transcript’ tags=”]

PCI Requirement 10.9 is the capstone to PCI Requirement 10. Once again, policies, procedures, and standards – the assessor is going to be asking for all of that documentation. They will be reviewing it, making sure that it is in place, that you’re actually using it, that you’re managing the documentation, and that it’s known to all effected parties.

[/av_toggle]

[/av_toggle_container]

 

Responding Failures

So, you’ve been alerted of failures of critical security controls…what do you do next? PCI Requirement 10.8.1 requires that you respond to failures of any critical security controls in a timely manner. If not, attacks can take the opportunity to infect your systems.

Your organization’s policies and procedures should outline the expected response to failures, which includes:

  • How to restore security functions
  • How to identify and document the duration of the security failure
  • How to identify and document cause(s) of failure, including root cause, and document remediation required to address root cause
  • How to identify and address any security issues that arose during the failure
  • How to perform a risk assessment to determine whether further actions are required as a result of the security failure
  • How to implement controls to prevent cause of failure from reoccurring
  • How to resume the monitoring of security controls

PCI Requirement 10.8.1 is an additional requirement for service providers only.

As part of that review, if there is a failure in any of your systems that detects that you might be hacked, it is required that you have appropriate measures in place to immediately react to that in order to bring those things back online to protect those environments. You have to have a program in place for detecting the failure of those critical systems that detect that you’ve been compromised.

[/av_toggle]

[/av_toggle_container]

Monitoring Failures

Without formal processes in place to detect and alert when critical security controls have failed, failures could go undetected for extended periods of time and provide malicious individuals with opportunities to compromise your systems and obtain sensitive data from the cardholder data environment. This is why PCI Requirement 10.8 requires that service providers implement a process for the timely detection and reporting of failures of critical security control systems. This could be the failure of things like firewalls, IDS/IPS, FIM, anti-virus, physical access controls, logical access controls, audit logging mechanisms, and/or segmentation controls.

PCI Requirement 10.8 is an additional requirement for service providers only.

[av_toggle_container initial=’1′ mode=’accordion’ sort=” custom_class=”]
[av_toggle title=’Video Transcript’ tags=”]

PCI Requirement 10.8 is another one of those requirements that is specific to service providers. If you’re a service provider and you’re providing services to other third-party organizations, you need to have a process in place that your log program and your security program is functioning as expected. PCI Requirement 10.8 calls out the requirements for monitoring programs, making sure that all of those assets are functioning, that you’re getting logs from all of those things, and that you’re reviewing them as appropriate.

[/av_toggle]

[/av_toggle_container]