By Andy Fulwood, Information Security Technician
Do you remember retail giant Target’s 2014 data breach that affected more than 40 million payment card accounts? The infamous breach is thought to have been made possible by hackers stealing electronic credentials from a vendor completely unrelated to their payments process. With access to the right credentials, the hackers were able to easily move across the network, accessing and infecting Target’s Point-of-Sale (POS) systems with malware.
Unfortunately, the Target incident was far from being the last major data breach we’ve seen. Just in the last few months we’ve witnessed many blue-chip brands be compromised due to a lack of security measures, and if you think your company has all the boxes checked and can defend against any cyberattack, think again.
Unlike many information security teams, cybercriminals aren’t only working 9-5, they’re working around the clock to discover weaknesses in the defenses of even the most well-protected organizations, and all it takes is just one chink in the proverbial armor for them to exploit a vulnerability.
The case of Target illustrates just how easy it is for threats to slip right under a company’s nose. Many would cite the Target example as the classic case study for the importance of network segmentation – with improper network segmentation configuration, the “bad guys” may access what should be secure payment card data by compromising areas that do not have the maximum number of security controls in place.
To address this issue and combat against the constantly evolving landscape of cyberthreats, the Payment Card Industry Security Standards Council (PCI SSC) introduced a new, mandatory requirement to the Payment Card Industry Data Security Standard (PCI DSS) that may have caught some unaware. As of Feb. 1, 2018, Requirement 188.8.131.52 now maintains that service providers must have a plan for conducting a network segmentation test every six months. They must also have at least one segmentation test conducted that is less than six months old.
Do Your Homework Before Contracting Service Providers
We all may agree upon the important role that network segmentation plays in securing our own payment card data, but it is even more critical that any service providers with which an organization works (particularly those that touch payment card data), have in place proper network segmentation practices and procedures. It is certainly within the right of an organization to inquire about those policies and to inquire upon the methodology for regularly testing those segmentation policies.
Some of the questions merchants should be asking of potential service providers include:
- Do you have a plan for conducting a network segmentation test every six months?
- Do you have at least one segmentation test conducted that is less than six months old?
- Do you conduct vulnerability scans of your networks quarterly?
- Do you conduct penetration testing of your environments?
- How often do you conduct these penetration tests?
- Are your penetration tests conducted in an automated manner, or are they conducted manually?
- Are your penetration testers qualified? What are their qualifications?
The Importance of Penetration Testing
With the ever-present cybercriminal constantly probing for vulnerabilities, it’s important to remember that while complying with the requirements of the PCI DSS may allow your organization to pass its annual assessment, in many cases, that’s not always enough to prevent a breach from occurring and should serve as an absolute bare minimum.
In our minds, even more effective than the required segmentation test outlined in Requirement 184.108.40.206 (which simply ensures payment card data is only in the places it should be), would be to add an active penetration test upon the network, to ensure it is properly hardened from a dedicated attacker.
Such a practice is precisely what we do every six months here at Semafone with our hosted environments for each and every customer. It is our considered belief that knowing where your payment data is located is a very different proposition than knowing that your data is secure from the real-world types of attacks responsible for many payment card data breaches historically (like Target’s).
From the simple and relatively inexpensive web application scans, to more hands-on, manual, red-team active and targeted break-in attempts, many activities have previously been classified as some form of penetration testing. The most secure organizations have traditionally elected for manual penetration tests, believing that having a skilled penetration tester or team of testers most accurately represents the type of real-world attacks played out against organizations on a daily basis.
Aspects of penetration testing have long played a role in achieving and maintaining an organization’s own PCI DSS compliance (which in itself brings a number of benefits, including increased security). In fact, the PCI Security Standards Council (PCI SSC) released an information supplement to further the understanding and objectives of penetration testing for compliance programs in September of 2017.
Immediately after that release, Troy Leach, chief technology officer of the PCI SSC, was quoted as saying, “Penetration testing is a critical component of the PCI DSS. It shines a light on weak points within an organization’s payment security environment which, if unchecked, could leave payment card data vulnerable.”
In addition to that information supplement, new penetration testing requirements were placed upon Level 1 and Level 2 service providers with the introduction of PCI DSS 3.2.
If the PCI SSC has underscored the role of critical activity in your own organization’s program, doesn’t it make sense to also demand the same principles to those service providers that may process, have access to, or in some way intersect with your own payment data? Wouldn’t you want that to include all of your service providers, regardless of their “Level?”
Our good friend, Jeff Hall (more commonly known as the PCI Guru) has a great write-up and more details on this matter on his blog. You can read more of his take on the clarification on the network segmentation requirement here.