Welcome to the seventh post of a series on understanding the Payment Card Industry Data Security Standard–PCI DSS. We want to show how PCI DSS affects anyone going through the compliance process using the PCI SAQ’s (Self Assessment Questionnaires).
In the previous articles written about PCI, we covered the following:
- Requirement 1: Build and Maintain a Secure Network – Install and maintain a firewall configuration to protect cardholder data
- Requirement 2: Build and Maintain a Secure Network – Do not use vendor-supplied defaults for system passwords or other security parameters
- Requirement 3 & 4: Secure Cardholder Data
- Requirement 5 & 6: Maintain a Vulnerability Management Program
- Requirement 7 & 8: Implement Strong Access Control Measures
- Requirement 9: Implement Strong Access Control Measures
Having recapped this so far, we’re going to focus on the requirements under the Regularly Monitor and Test Networks section.
Today, we are going to dive into the monitoring aspect of the PCI puzzle. Let’s discuss monitoring access systems and how to ensure those systems remain current with the latest adjustments in order to tackle the always-changing landscape of new attack tactics and techniques.
PCI Requirement 10
Track and monitor all access to network resources and cardholder data
Without physical access controls, unauthorized agents could potentially gain access to sensitive information which is why maintaining visibility is critical.
Logging tools and the ability to track users is crucial in minimizing the potential impact of a data breach. The mere existence of logs allows better tracking and analysis when the worst case scenario occurs.
Determining the root cause of a compromise is very difficult, if not impossible, without these types of logs available. Our remediation lead, Krasimir, does an excellent job of outlining the importance of keeping audit logs available; as well as offering good tips on how to navigate this task.
The ability to establish a workflow to recall those logs for such digital forensic work will help in fulfilling sub-requirements 10.2 and 10.3.
Requirement 10.3 requires to maintain visibility over the following types of entries:
- 10.3.1 User ID
- 10.3.2 Type of event
- 10.3.3 Date & Time
- 10.3.4 Success or failure indication
- 10.3.5 Origin of event
- 10.3.6 Identity or name of affected data, system component, or resource
It seems obvious to want to maintain visibility over these specific entries, but Jacqueline von Ogden from Cimcor recalls the Verizon’s 2015 PCI study, concluding that:
Requirement #10 was one of the two most commonly failed PCI requirements by breached organizations followed by Requirement #6 .
So we’ve determined that tracking and monitoring all-access network resources and cardholder data is important, yet often missed a task. But what do we use?
Using OSSEC as a Monitoring Tool
Offsite monitoring technology is a great option, such as OSSEC, a host-based intrusion detection system that can perform system logging and help satisfy this requirement to fulfill PCI compliance.
Sucuri Co-Founder, Tony Perez, published a great writeup on installing OSSEC on a Linux architecture. Among others, there are posts on how to best optimize your use of OSSEC, which includes his own implementations as a guide.
PCI Requirement 11
Regularly test security systems and processes
Bad actors and researchers alike continue to uncover vulnerabilities, especially with the introduction of new software. For example, recently WordPress published a near-immediate patch after Gutenberg’s official debut.
Frequently testing system components, processes, and custom software will help continue to reflect an ever-changing ecosystem.
There are many plugins and tools out there that can help conduct vulnerability scans. However, a vulnerability scan is only as useful as the list of vulnerabilities it knows to look for. The “knowns” while trying to stay ahead of potential “unknowns” become tricky.
To account for this, if you’re not in the business of or proficient enough to maintain RSS feeds or alerts to the latest vulnerability trends and tactics being used out there, you should take full advantage of a Web Application Firewall (WAF) that can also function as a virtual patching tool.
The Sucuri WAF is built on an IDS/IPS stack, which helps fulfill Requirement 11.4 and we also offer virtual hardening to ensure we remain ahead of the emerging threats, not just the known ones.
Today we have discussed PCI requirements 10 and 11 which demands webmasters to regularly monitor and maintain their networks.
In the upcoming post of this series, we will touch on Requirement 12 that speaks to maintaining an information security policy.