Penetration testing blog

Back to writing after several days or weeks (I could go back and check when the last post took place but I’m very lazy)

In case you’re not familiar with the PCI standard, here’s their website: https://www.pcisecuritystandards.org/

Basically, anyone dealing online with American Express, Discover Financial Services, JCB, MasterCard Worldwide, and/or Visa International is required to comply with a series of security requirements. The main aim is to prevent someone malicious from obtaining access to the credit cards that you handle as well as to make sure that you’re not keeping any sensitive data unsafe internally; and the process therefore involves not only a software-level review but also physical security assessments.

Depending on how many transactions you handle a year and a few other variables (such as if your company has already been compromised before) you get a merchant level assigned which ranges from Level 1 (bigger, more critical) to Level 4 (smaller). Depending on your Level you get different base requirements.

For a detailed description of the 12 main requirements, take a look at: https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf

I ran across this article by Mark Curphey called “Why the PCIStandard needs as serious re-think” where he talks about the Quarterly scans performed by ASVs (Approved Scanning Vendors) and the quality of the work they deliver.

I wanted to add something more to it, just a quick note, that was the whole purpose of this post.

There is a supporting document by PCI called “PCI DSS Validation Requirements for Approved Scanning Vendors (ASVs)v 1.1” which among several other items, it describes the 5 different Risk levels available at the time of tagging a vulnerability with the corresponding risk.

The document is available <here>

Vendors can’t go creative and assign a risk level that they feel fits the issue, they need to work along the different levels presented by the standard and the explanation provided by the standard for each level. And that’s where I’m going with this. The explanation is completely focused on network-level security and privilege escalation and gets to be a very deep headache at the time of determining in real life what goes where.

If you’re used to running software products that do everything automatic for you, then fine, you don’t even know what I’m talking about here and probably don’t even care - but I wouldn’t advice simply sticking to your automatic product. When findings stuff that automatic products would just miss and/or when working with web-application security, then you better have a Tylenol near by.

The difference between a level and another (level 2 and level 3 for instance) simply means “Compliant” or “Non-compliant” (in case the merchant is unable to fix this on time) and it’s therefore very important to think twice or even three times before deciding what risks to assign. I’m not saying avoid Level 3, I’m saying that you often run into dark areas where there’s no easy way of determining where an issue falls and you need to be careful whenever you make that decision.

Let’s just stop here and we’ll talk about PCI, ASVs and QSAs some other time.