A quick note about PCI DSS compliance and scanning vs. penetration testing and PCI DSS 11.2 and 11.3. Often (too often) when I’m talking with organizations about their PCI compliance, they respond that they’re already compliant and they already have someone doing their quarterly scanning for them. That’s great, I say! Then I ask about their internal/external Penetration Testing.

That often generates dead silence on the other end of the phone.

Yes, organizations already PCI compliant (really compliant) are doing their quarterly internal /external vulnerability scanning and annual internal/external Penetration Testing; or after any significant infrastructure or application upgrade…

If you are scanning using an ASV (Approved Scanning Vendor) that’s great and continue! You also need to be doing external/internal Penetration Testing, which means working with someone that is trained and qualified to do so. It doesn’t need to be a QSA (Qualified Security Assessor) or an ASV, but they do need to be qualified.

The Standard states: 11.3.b – Verify that the test was performed by a qualified internal resource or qualified external third party, and if applicable, organization independence of the tester exists.

Penetration tests differ from automated vulnerability scans in that efforts are focused on actually exploiting weaknesses with the intent of gaining access to the environment.

Vulnerability Scanning outlines the vulnerabilities, but Penetration Testing demonstrates how those vulnerabilities can be exploited to gain access.

And, Penetration Testing requires People! It takes someone trained and qualified, not just an automated scan. If you’ve ever chatted with a trained Ethical Hacker, like we have on our team, you’ll fully understand the difference. They have some very creative ways of gaining access.

Nancy Sykora
Sr. Account Executive

 

 

PCI DSS Requirements

PCI DSS Requirement 5.4.1: Anti-spoofing controls such as DMARC, which stands for Domain-based Message Authentication, Reporting and Conformance, Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM) can help stop phishers from spoofing the entity’s domain and impersonating personnel. 

Clarification on eCommerce Outsourcing PCI DSS requirements 6.4.3 and 11.6.1

Unpacking the New PCI DSS Password Standards

Is Your Organization Prepared for PCI DSS Automation – Requirement 10.4.1.1?

What is the PCI DSS v4 Authenticated Scanning Mandate – Requirement 11.3.1.2?

What is the PCI DSS v4.0.1 Requirement for PoLP – Requirement 7.2.5?

PCI SSC Updates SAQ A: Removal of Key eCommerce Security and New Eligibility Criteria – Requirements 6.4.3, 11.6.1, 12.3.1

The New PCI DSS v4.0.1 Software Catalog Mandate – Requirement 6.3.2

How PCI DSS 4.0.1 Tackles Service Account Vulnerabilities – Requirements 8.6.1, 7.2.5.1, 8.6.2, 8.6.3, 10.2.1.2

Are You Keeping an Inventory of Cipher Suites and Certificates for the New PCI DSS – Requirements 12.3.3, 4.2.1.1?

How to Analyze An Attestation of Compliance (AOC)

PCI Compliance New Requirements and Targeted Risk Analysis (TRA)

 

RESOURCES & NEWS

Learn more about Penetration Testing and new exploits in HALOCK’s Exploit Insider.

The Dangers of Legacy Protocols

Exploiting API Endpoints

Abusing Default Credentials

Weaponizing Legacy Software

 

PCI Targeted Risk Analysis & DoCRA

https://www.halock.com/pci-compliance-new-requirements-and-targeted-risk-analysis/

 

HIPAA & Penetration Testing & Incident Response Plans

https://www.halock.com/are-you-ready-for-the-enhanced-hipaa-requirements-for-penetration-testing-and-more/

 

Top Threats in Healthcare

https://www.halock.com/top-cyber-threats-in-healthcare/

 

Cloud Security Risk Management

https://www.halock.com/prioritized-findings-and-remediation-in-cloud-security-reporting/

 

Penetration Testing Reports to Manage and Prioritize Risk

https://www.halock.com/a-threat-based-approach-to-penetration-test-reporting/