PCI DSS: Ongoing Vulnerability Management
Updated: Oct 12
The 2020 Costs and Consequences of Gaps in Vulnerability Response from the Ponemon Institute revealed that most organization’s vulnerability management programs are not mature. 59% of the survey respondents shared that their programs are only in the early or middle stages of development, while at the same time the window of time to patch a vulnerability before the likelihood of attack is decreasing. 48% of those involved in the study shared that they had experienced a data breach in the last two years, and of those, 60% say the breaches could have occurred due to an available patch not being applied for a known vulnerability.
The Verizon 2020 Payment Security Report also revealed disappointing stats with overall PCI compliance sustainability continuing to fall across the board, with only 27.9% of organizations achieving full compliance during an interim compliance validation, and this is also largely due to lacking vulnerability management. When we look at vulnerability management as part of the Payment Card Industry Data Security Standard:
Requirement 6.1 compels organizations to establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking to newly discovered security vulnerabilities.
Requirement 6.2 stipulates that all system components and software to be protected from known vulnerabilities by installing applicable vendor-supplied security patches.
Requirement 11.2 calls for all merchants to perform internal and external vulnerability scans at least quarterly and following changes to their network infrastructure. Organizations must provide passing scans for each quarter.
In the above-mentioned Verizon Payment Security Report, Requirement 11 seemed to cause organizations the most difficulty, along with Requirement 6 and Requirement 12. The report shared that vulnerability data can be difficult to consume for many organizations. Common operational issues include:
Delaying until the month before the passing scan is due to run the scan, which often leads to the discovery of complex remediation issues that are not possible to resolve within 30 days
Changes in staff responsibilities/lack of oversight
Use of antiquated or end-of-life technologies that have no further support
Challenges reviewing the results of vulnerability scans and determining next steps
Difficulties adequately interpreting the results and filtering out potential false positives
It is critical for organizations to stay on top of passing quarterly vulnerability scans and installing critical security patches. Based on investigations of breached companies, no investigated organization that was breached was compliant with all twelve DSS requirements at the time of the compromise. In many cases, non-compliance with requirements like vulnerability scanning directly contributed to the breaches. Organizations are not patching web applications quickly enough, leaving known holes for hackers to exploit. According to the 2020 Verizon DBIR, only half of vulnerabilities are patched within three months after discovery. Attackers know patches are not consistently applied, and until organizations do so, attackers will continue to focus on these areas because they can harvest large amounts of valuable customer data with a relatively low amount of effort. It only takes one unpatched vulnerability to gain access to critical systems. Just ask Equifax! The more recent WannaCry ransomware attack also demonstrated how an unpatched vulnerability in Microsoft Windows OS was disastrous for targeted organizations. Vulnerability scanning is an integral piece of your overall vulnerability management program. Scans allow security teams to get an overall view on possible vulnerabilities, including those missing patches, and other weaknesses or misconfigurations. Performing scans on a regular basis and after any infrastructure or network changes is the best way to catch potential issues early. Compliance requirements, like the PCI DSS, may only require quarterly scans but, given how quickly the threat landscape evolves, your organization should really be scanning more often to eliminate potential risks. Running vulnerability scans alone is not equivalent to a robust vulnerability management program. To reduce risk and prevent data breaches, critical vulnerabilities must be continuously identified, prioritized by risk and effort to fix, and then successfully remediated. Use the information obtained from the scan to help prioritize the vulnerabilities, assess the associated risks, and allocate resources accordingly for remediation. Confirm the remediation work by re-scanning to validate that the vulnerabilities have been adequately addressed. Vulnerability Management Process:
Identify Vulnerabilities (external and internal vulnerability scans).
Evaluate the risk posed by identified vulnerabilities (what the impact to the organization would be if a vulnerability were to be exploited, how practical it would be for a hacker to exploit the vulnerability, and if any existing security controls reduce the risk of that exploitation).
Remediate any identified vulnerabilities (any detected vulnerabilities should be patched, fixed, or mitigated. Security staff may choose to mitigate the risk by ceasing to use a vulnerable system, adding other security controls to try to make the vulnerability harder to exploit, or reduce the likelihood and/or impact of the vulnerability being exploited successfully).
Re-test to confirm the remediation work.
Document and report on vulnerabilities and how they have been addressed.
Some additional guidance from the CampusGuard Offensive Security Services Team: [Wheeler]: Rome wasn’t built in a day, and we certainly know that Vulnerability Management programs aren’t either. One of the first things that has to happen before you can begin identifying vulnerabilities is know what systems you have. If you are only scanning a subset of your systems or miss that one test system that was used for that one thing, but not decommissioned properly, you are certainly setting yourself up for failure. We have seen this during many pen tests; that one test system that was forgotten about was missing patches thus able to be compromised, and then the dominoes began to fall until the entire domain was compromised. Ensure you have an accurate inventory of systems and subnets then scan everything. From there, you may need to further inventory systems to know what software is installed, what libraries are used, etc. Follow the steps above, and make sure you have a handle on detection, mitigation, and reporting. Next is to decrease your response time in applying patches. Recently, less than 72 hours after SAP patches were released*, attackers had reverse engineered the patches to develop exploits for the associated vulnerabilities. The capabilities of attackers are increasing, so our TTP (time to patch) must decrease to keep up. *Reference: https://www.darkreading.com/threat-intelligence/attackers-actively-seeking-exploiting-vulnerable-sap-applications/d/d-id/1340602