The PCI DSS compliance model depends on risk assessment and mitigation. The testing instructions for PCI DSS published by the PCI Security Standards Council for QSA’s tell us to look for evidence of documentation being updated as a result of lessons learned from activating the (IRP) Incident Response Plan, as a business-as-usual practice, and also in response to “developments in the industry”. “Developments” doesn’t always mean a good thing. New methods of attack from the hacker community are developments, just as much as a new heuristic, or AI tool is, to detect them.
Over the last couple of years as an industry, we have had major issues with massive DDoS attacks, ransomware, DNS provider hijacking, Spectre and Meltdown. Not to mention the run-of-the-mill announcements from nearly every vendor about nearly every product.
When I am assessing whether documents have been “recently updated”, I look for these types of issues to be called out. The Risk Assessment (RA) is not complete without addressing such threats. Especially because Spectre and Meltdown had no stable vendor response at first, they should be considered higher risks and each organization has to consider what other compensating controls might be necessary to mitigate the risks they present.
What documents should you be looking at? I think any or all of the list below should at least be reviewed for their specifics and be updated to befit the situations that arose to cause the IR Plan to be invoked.
- Incident Response Plan
- Allowed port, protocol justification(s), and network locations for technology
- Authorized technology (applications, and hardware such as BYOD devices)
- Firewall and router configuration(s)
- Network diagram
- Data flow diagram
- Vendor list
- Authorized employee list
- Authorized remote accesses
- Hardening guide(s)
- Hardened golden images of operating system and software install packages
- Risk Analysis
In my experience, the first response to most incidents is to remove the network cable from the affected machine(s) and then to shut off all communication at the firewall with any system attempting retries to connections to that IP address. That is slightly harder if the device in question is connected through a wireless connection, but turning off the Wi-Fi and Bluetooth transmitters is usually reasonably trivial. That’s why I chose the specific order listed above because it tends to be the order in which they are encountered or followed during an incident. Indeed, having all that information readily available to the IR team might enable a much faster incident resolution.
There is another somewhat related issue in that while the PCI DSS standard and QSA testing procedures only talk about critical patches being installed within 30 days of vendor release, they really should have been asking for mitigation for any high-risk vulnerability within the 30 days of the announcement, even if there’s no formal patch available. This could mean putting in a different control until there is a formal patch available. That’s why you need to watch more than just the patch announcements and look at the CVEs as they are published.
When I can’t find evidence that the RA and IRP have been updated to address lessons learned from well-known recent vulnerabilities and breaches, I begin to look deeper into what else might have been missed. Please don’t become non-compliant because your radar is not attuned to the vulnerability announcements the way Requirements 6.1, 12.2, and 12.10 prescribe.
Truvantis is a full-service information security consulting company with highly trained and experienced staff who can assist you in starting or completing any part of the compliance journey. Whether you need gap analysis, written policies and procedures, implementation guidance, or an assessment, our Professional Services team is available to assist, not just with PCI, but other common standards such as ISO 27001, ISO 27701, CIS, SOC 2, CCPA, CPRA, GDPR, HIPAA and more. Use the Contact Us button to start the conversation.