PCIP3-0 techniques - Payment Card Industry Professional Updated: 2023

The payment card industry (PCI) comprises all companies involved with credit and debit card transactions. For commerce and retail — and any institutions that issue any type of credit, debit or prepaid card — complying with PCI regulations is essential. Payment Card Industry Data Security Standard (PCI DSS) rules apply to every business that accepts these forms of payment. 

Even if your business employs only a few people and conducts one credit card transaction per month, your company must be PCI DSS compliant. Knowing what PCI compliance entails is central to your financial security and customer loyalty. Read ahead for a guide on PCI compliance and for answers to merchants’ most commonly asked questions about compliance for small businesses.

What is PCI DSS?

The Payment Card Industry Security Standards Council (PCI SSC) was launched on September 7, 2006, to manage the ongoing evolution of the Payment Card Industry (PCI) security standards with a focus on improving payment account security throughout the transaction process.

The major credit card companies (VISA, MasterCard, Discover, and American Express) came together and published a uniform set of data security standards that serve those who work with payment cards. This includes: merchants of all sizes, financial institutions, point-of-sale vendors, and hardware and software developers who create and operate the global infrastructure for processing payments.

Overview

All Northwestern University departments that accept credit/debit card payments are considered merchant locations and must process those payments in a secure manner.  It is the responsibility of each merchant location to maintain compliance with the NU Merchant Card Processing Policy and the Payment Card Industry Data Security Standard (PCI DSS) established by the Payment Card Industry Security Standards Council (PCI SSC).

Treasury Operations is a central e-commerce administrator and compliance resource for Northwestern University merchant locations.  All Northwestern University merchant locations must participate in Northwestern University’s PCI training program and compliance initiatives.  Failure to fully participate may result in the merchant account being revoked.

Northwestern’s PCI DSS Compliance Program addresses requirements of the PCI SSC, including:

1. Security Awareness Education (required PCI DSS Security Training and Attestation)
2. Third Party Service Provider (TPSP) engagement
3. System Vulnerability Scans
4. System Penetration Testing
5. Periodic Reviews and Audits
6. Annual PCI SAQ (Self-Assessment Questionnaire)

(1) PCI DSS Security Training and Attestation

Per PCI DSS requirement 12.6, Northwestern University requires all Northwestern merchant location personnel interacting with the Cardholder Data Environment (CDE) in any manner (from the initial entry to the final reconciliation) to complete an annual training and attestation.  This mandatory requirement includes student employees, contractors and volunteers.

Employees and those with myHR access should complete training in myHR: (PCI DSS: Payment Card Data Security).

Volunteers and those without myHR access should complete this training at: https://sites.northwestern.edu/pcidss/

• Individuals who have not completed training and attestation are not permitted to process Cardholder Data (CHD) on behalf of Northwestern University interests.  Merchant locations using untrained or unattested individuals to process CHD may have their merchant account revoked.

Merchant location personnel should also read and understand the Northwestern PCI DSS Compliance Policy.

Treasury Operations may require individual or group participation in additional PCI security awareness education training as needed.

(2) Third Party Service Provider (TPSP) engagement

NU Merchant locations or their representatives, including vendors and other TPSPs, may not enter into legally binding agreements with TPSPs processing or handling any type of CHD (Cardholder Data), or interacting in any other way with the CDE (Cardholder Data Environment) without proper NU vetting and approval first; including but not limited to Treasury Operations, NU IT Security and Compliance, NU Office of General Counsel and NU Purchasing.  All agreements with TPSPs must have specific PCI DSS and liability shift language included.

(3) System Vulnerability Scans

Merchants with non-P2PE, on-campus payment systems connected to the Internet are required to run vulnerability scans against their systems. Northwestern University’s contract with Trustwave includes external vulnerability scans that are scheduled on the TrustKeeper Portal; scan reports are posted on the TrustKeeper Portal as well. It is the responsibility of the Merchant to review the scans and address any vulnerabilities that have been identified. Failure to address identified vulnerabilities can result in the Merchant location, as well as the entire University, falling out of compliance. Merchants with PCI-validated P2PE payment systems are not required to run scans.

(4) System Penetration Testing

Northwestern University is now a PCI Level 3 Merchant based upon accurate card processing metrics, and NU Merchants with non-P2PE, on-campus payment systems connected to the Internet are now required to have internally conducted penetration testing performed at least quarterly. Since this service is not currently a part of our Trustwave contract, arrangements need to be made by e-Commerce Operations and NU IT Security and Compliance, coordinated with Merchant onsite Administrators and IT staff. Failure to cooperate with this mandatory requirement may result in your Merchant account being revoked. Merchants with PCI-validated P2PE payment systems are not required to run penetration tests.

(5) Periodic Reviews and Audits

Treasury Operations and Northwestern’s PCI DSS partners or consultants may perform periodic reviews or audits of merchant location operations to ensure that merchants comply with PCI DSS and the University's risk is reduced.  Failure to cooperate with such activities may result in merchant account usage being revoked.

Merchant locations should also routinely review their procedures and equipment, including physically inspecting card processing equipment to ensure devices have not been substituted or tampered. This Merchant Location Device Inspection Checklist can be used for your inspections.

Please contact ccard@northwestern.edu with questions or to request assistance.

(6) Annual PCI SAQ (Self- Assessment Questionnaire)

All Northwestern University merchant locations are required to validate PCI-DSS compliance at least annually by completing the appropriate SAQ in a timely manner. A questionnaire must be completed for each Merchant account, and a new questionnaire must be filled out whenever any of the following have occurred:

• - payment processing system changes
• - a year has elapsed since your last SAQ
• - upon Treasury Operations request

The SAQ should be completed through the TrustKeeper Portal which is available in the CardConnect CardPointe gateway.

There are 8 types of SAQ. Treasury Operations or Arrow Payments can help determine which type is required for your merchant location environment:

Resources:

Department and Unit Heads (who accept payment card payments other than through approved online methods)

The next version of the Payment Card Industry Data Security Standard goes into effect over the next 18 months. Because the new standard requires more documentation about methodology and means, penetration testers may find themselves under greater scrutiny from the organizations that hire them.

On the positive side, the updated standard may mean better business for pen testers. PCI DSS 4.0 widens the scope of PCI pen tests, allows pen testers more leeway in how tests are conducted and explicitly requires that follow-up pen tests be conducted to verify that vulnerabilities have been remediated.

Here's a look at what PCI DSS 4.0 means for pen testers.

What has and hasn't changed for PCI compliance testing

The overall framework of penetration testing for PCI DSS compliance stays mostly the same. PCI pen testing should take at least three approaches: an external black-box test, an internal test in which the pen tester tries to get into the cardholder data environment (CDE) from other parts of the network, and an internal test from inside the CDE itself.

Required PCI pen testing is still just once a year for most merchants, and twice yearly for service providers. More frequent pen tests are required if there is a security incident or, as the PCI DSS requirements and testing procedures state, "any significant infrastructure or application upgrade or change."

But PCI DSS 4.0 introduces stricter requirements to verify the safety of online payment pages and web-based applications. It also adds an explicit requirement that cloud service providers give pen testers access to their clients' cloud assets. We'll go over both those details, plus requirements about documentation and retention of records, below.

Hello, customized approaches

The most significant innovation in PCI DSS 4.0 is the ability for entities — i.e., any organization that must comply with PCI DSS — to choose "customized approaches" for individual requirements.

Customized approaches may seem like an expansion of the "compensating controls" loophole that previous versions of PCI DSS offered if a company couldn't quite meet the exact details of a particular requirement for technical reasons.

Compensating controls still exist in PCI DSS 4.0, but customized approaches are optional and offer something much better: A way for organizations, if capable, to meet individual PCI DSS requirements on their own terms rather than by sticking to the prescribed "defined approach." This is ideal for companies that have complex architectures or that must comply with many different regulatory frameworks.

"Unlike compensating controls, which are used when organizations have a constraint and are unable to meet the requirement as stated, the customized approach is for entities that choose to meet the requirement differently than is stated," explained Lauren Holloway of the PCI Security Standards Council in an official blog post.

A customized approach gives pen testers more flexibility in how to conduct a pen test on a particular requirement as long as everything about the customized approach, and the test, is documented down to the smallest detail.

Because PCI DSS 4.0 requires that each planned customized approach be subjected to a targeted risk analysis by March 31, 2024, it's possible that pen testers may be asked to conduct or assist with that process in the next few months.

Tougher requirments for payment pages and web apps

PCI DSS adds new requirements covering payment pages and web apps. Requirement 6.4.2, which goes into effect in 2025, mandates the use of an automated tool to detect and prevent attacks on web applications.

This replaces an older requirement (6.6 in PCI DSS 3.2.1, 6.4.1 as a one-year temporary option in PCI DSS 4.0) that web apps merely get vulnerability scans. By implication, web apps now need to be actively pen-tested.

According to Clone Systems Senior Security Engineer Tom Nianios, this puts application-program interfaces (APIs) into the scope of PCI compliance pen tests. He suggests using the Open Worldwide Application Security Project (OWASP) Top Ten framework as a guide.

"Before, APIs were kind of the secure thing that no one can compromise," says Nianios. "But now, APIs are within scope. So you need to test the web-application API, and you need to test the web application, obviously, with the OWASP standard."

There's also a brand-new requirement, 6.4.3, mandating all organizations that maintain online payment pages to manage, verify and inventory all scripts running on those pages, and to block unauthorized code or scripts.

Another new requirement (11.6.1) says that entities must implement a "mechanism," either manual or automated, to check payment-page content and HTTP headers at least weekly for evidence of tampering and unauthorized changes.

Scott Goodwin, a principal in the cybersecurity and privacy advisory at consulting firm PKF O'Connor Davies LLP, suggests that pen testers try to manipulate payment pages directly.

"Penetration testers can use tools like BurpSuite to manipulate requests to payment pages in an attempt to inject malicious code," he says, "and tools like SQLMap and SMBMap to identify and manipulate data stored in databases and on file shares, respectively."

Stronger network segmentation

PCI DSS 4.0 puts greater emphasis on network segmentation. It clarifies in requirement 11.4.5 (replacing requirement 11.3.4 in PCI DSS 3.2.1) that annual pen tests be conducted "according to the entity's defined penetration-testing methodology" to, as before, confirm that the segmentation works properly to isolate "all out-of-scope systems" from the CDE. PCI DSS was less stringent in this respect, asking only that pen testers verify segmentation as part of their testing procedures.

The requirement adds a new spin: Segmentation pen-testing must also confirm the isolation of "systems with differing security levels," an aspect not present in PCI DSS 3.2.1.

That in turn references requirement 2.2.3, which mandates that "primary functions with differing security levels that exist on the same system component are isolated from each other" or "are all secured to the level required by the function with the highest security need."

This is a bit looser than PCI DSS 3.2.1 requirement 2.2.1, which mandates that primary functions with different security levels should not be on the same server at all. PCI DSS 4.0 retains that as an option but not an absolute requirement, perhaps showing a bit more faith in the ability of segmentation to properly separate components.

More access to cloud assets

Cloud assets, including web apps, and cloud-based virtual servers have always been within the scope of PCI pen tests if they held or touched the CDE. But PCI DSS 4.0 should make it easier to access those assets if they're on "public" clouds run by the likes of Amazon Web Services, Microsoft Azure or Google Cloud Platform.

The new requirement 11.4.7 states that "multi-tenant service providers" — which includes cloud service providers (CSPs) — must "support their customers for external penetration testing." The multi-tenant service providers must also either show their clients documentation that a pen test has been done, or let their clients perform their own pen tests.

This was likely added because historically, some CSPs haven’t liked third-party pen testers poking around in their systems. PCI DSS 4.0 removes any doubt that CSP customers have a right to get someone to pen-test their own assets in someone else's cloud.

There are strings attached, however. Cloud systems are obviously very different from on-prem systems, even those running virtual servers, and learning to navigate them may require additional training.

"[The cloud] is a new set of skills. And it is a new set of methodologies," says Nianios. "However, it's easier [to pen test], in my opinion, because all the security controls that they had in place on-site, all these layers that they've added over the years, they don't exist over there [in the cloud]."

Pen-testing a third party's cloud assets could cause legal trouble, too. Before a pen-testing firm goes into a client's assets on a third-party public cloud, it needs to thoroughly understand the specific shared-responsibility agreement between the client and the CSP (perhaps better than the client does), and to establish exactly where the red lines marking the beginnings of CSP responsibility are.

Pen testers "really need to dig into the licensing and contractual agreements that that organization would have with the cloud provider," explains Jason Stockinger, Director of Global Information Security at Royal Caribbean Group. "For example, if you're doing infrastructure as a service, [the cloud provider] is not going to allow you to pen-test past a certain point. If you start probing that, it'll be a breach of contract."

Document everything, and get ready for a grilling

PCI DSS 4.0 requirement 11.4.1 is an update of PCI DSS 3.2.1 requirement 11.3 and clarifies that the complying entity must define, document and implement a pen-testing methodology. It's a bit less stringent in that it lets the entity figure out the methodology.

That methodology doesn't have to be a cookie-cutter version of a standard pen-testing frameworks like OWASP or the Open-Source Security Testing Methodology Manual (OSSTMM) — many pen testers mix and match parts from different methodologies — but it has to be documented and defined.

The means of pen-testing the network inside and out also needs to be documented and clarifies that the various attack vectors and vulnerabilities defined in requirements 6.2.4 and 6.3.1 must be addressed.

Pen testers will have to show that they tried to get in via "injection attacks, including SQL, LDAP, XPath" and attacks on "data and data structures", "cryptography usage," "business logic," "access control mechanisms" and so on, and that commonly known vulnerabilities are also addressed.

Requirement 11.4.4 clarifies that every vulnerability documented in the final pen-test report must be remediated, no matter how small. The means of remediation must be documented, and then a second pen test must be performed to verify those remediations. Previously, PCI DSS 3.2.1 required only that "testing is repeated to verify the corrections."

Requirement 11.4.2b and 11.4.3b are the least fun parts. They add to their PCI DSS 3.2.1 predecessors (11.3.1b and 11.3.2b) by mandating that the complying entity not only verify that a "qualified internal resource or qualified external third party" carries out the pen test, but that the entity must also interview involved personnel as part of the verification process. Likewise, requirement 11.4.5c (replacing 11.3.4c) specifies that segmentation pen-testers be interviewed.

In other words, third-party pen testers may have to sit down and be grilled about how they conducted the tests, how they got into systems, what they found, and so forth.

The requirement is vague enough so that a detailed pen-test report presented an in-person meeting with the client may qualify as an "interview" as long as the client asks questions, but it might be best to bring along some of the front-line pen-testers just in case. It definitely means that pen testers will need to document every step of the pen-testing process if they're not doing so already.

For the post-test period, PCI DSS 4.0 states in a bullet point in requirement 11.4.1 that all notes, records and reports from a PCI compliance pen test must be retained for at least 12 months. The length of the retention period wasn't specified in PCI DSS 3.2.1.

The requirement doesn't say whether the pen tester or the entity should be the one holding on to the records, but if they don't have them already, firms that carry out PCI compliance pen tests may need to build secure storage systems that can easily retrieve such documents upon demand.

Should social engineering be in scope?

Finally, a social-engineering pen test is still not part of the PCI DSS requirements, but it may be more important than ever — especially when it comes to staffers who have privileged or administrative access to the CDE.

In well-defended organizations, such employees may be a weaker point of defense than the CDE itself. But pen-testing firms might have trouble getting their clients to pay for a social-engineering pen test until the PCI SSC makes it mandatory.

"While PCI DSS 4.0 does not explicitly require social engineering as a component of penetration tests, it is still one of the most common ways organizations are initially breached," says Goodwin. "From a purely risk-based perspective, it makes sense for any organization processing cardholder data to engage in periodic adversarial social-engineering exercises."

Accepting credit card payments online is an excellent way for small businesses to streamline sales and attract customers. However, safeguarding your business and customers is critical, and so is mitigating common risks and types of fraud that proliferate online. 

We’ll explore expert tips and advice about small business credit card processing online and what business owners should understand about card-not-present payments. 

Getty Images