2

I'm fully up to speed on PCI DSS requirements and have attend the ISA course recently. The course was helpful and I was able to bounce ideas off of the trainer. However I keep coming back to one aspect of PCI for which I need to decide if at this stage if it's applicable or if anyone else has gone down this route: vulnerability scans.

I have got the impression that if I can prove that the card data in our environment is fully encrypted from the PIN pad to our transaction handler and there is no way anyone could hack that or retrieve the decryption keys or even be able to influence the transaction, then a vulnerability scan will not add any security. (However I do see the point of vulnerability scans from a general security stand point.) It's a cost and time thing at the moment.

The setup (merchant Level 2 - SAQ C):
Multiple sites, segmented and not connected together via VPN/LAN/etc. All standalone sites. We use a PCI DSS Level 1 Card transaction handler and use their software and industry standard PCI-compliant PIN pads. The data is encrypted within the device and then transmitted. We have no access to the data or other information other than the last four digits after the transaction has been processed.

We currently have quarterly external penetration tests performed by an ASV.

With the encryption and access, does anyone feel I can de-scope the vulnerability scans?

AviD
  • 72,708
  • 22
  • 137
  • 218
Michael Lock
  • 21
  • 2

3 Answers3

6

Absolutely not.

If your goal is just to gain PCI-DSS compliance, you're assessing the situation incorrectly. Compliance should be a by-product of good security, and regular penetration testing and vulnerability scans are an invaluable part of that.

As an example, let's say a 0day is released for Windows XP SP3. There's a good chance you won't catch the news, and you'll be oblivious to the potential problems. Regular vulnerability scanning will alert you to that problem as soon as the scanner is updated with a detection routine. This is critical to keeping the barrier to entry on your network relatively high.

If cost is a major factor, it's time to present your case for a budget increase. You need to weigh up the potential damage and risks, and make a strong case as to why you need to be doing these scans.

Polynomial
  • 133,763
  • 43
  • 302
  • 380
  • Hi Polynomial, I agree with you but short term plan is to get PCI compliant, We more or less are and this is the only thing stopping me signing off on it. My main goal long term will be better security and prevention but i have a limited timeframe for PCI. If i can de-scope this aspect, it will buy me some time and immediate work while i work the other stuff out. Let me clear at the moment i feel i could leave every vulnerability on a machine and still the data would be secure. Im really interested in a general concensous or would like to hear from someone who has addressed this. – Michael Lock Oct 26 '12 at 11:22
  • "i feel i could leave every vulnerability on a machine and still the data would be secure" - I feel sorry for your customers. Sorry, but I cannot possibly condone this. It's a horrendous idea, and it's completely irresponsible. – Polynomial Oct 26 '12 at 12:02
4

Absolutely not.

While I completely agree with @Polynomial's answer, about prioritizing security, and having compliance as a byproduct, you need to realize something very important.

Compliance is not about security.

Simply put, you need to perform those scans, because it is what the regulation requires, if you want compliance. Encryption and access control are two other requirements, but they are completely seperate from the scanning requirement. (PCI does not state "Either encrypt all card data, OR perform a vulnerability scan".)
Both are required, neither can be descoped, and either one can prevent compliance.

Don't forget the real risk model you need when dealing with PCI compliance, summed up by the well-known AviD's Law of Compliance:

"PCI compliance reduces the risk of the penalties of non-compliance."

AviD
  • 72,708
  • 22
  • 137
  • 218
  • Avid, I totally understand what you are asying, however PCI DSS is not black and white and is open to interpretation. It is designed that way to allow companies to descope aspects of their environment. By using Tier 1 Card handlers and software and by not having the data ourselves we restrict the level of scope and can rightly cross/ say yes to many areas of PCI as they now do not apply. If we had control of the card data then i would nopt be asking this question. – Michael Lock Oct 29 '12 at 12:05
  • @MichaelLock this is correct, but not applicable here. You are asking not about de-scoping part of your environment, you want to remove a requirement. Also, as I understand from your question, you do store the card data (encrypted), so all of the requirements do apply. If you did not have any card data, even encrypted, you wouldnt need to comply with PCI at all :-) – AviD Oct 29 '12 at 12:09
  • Hi Avid, sorry for the confusion. We do not store the data at all, its sent encrypted from the device and then we only see/store the confirmation (Yes/No) and the last 4 digits. The only storage that occurs is in high memory for 10 seconds. PCI still applies as there are otehr aspects to consider, mostly policy and physical access. – Michael Lock Oct 29 '12 at 12:30
  • @MichaelLock I am still confused. PCI applies if you handle, process, store, or otherwise touch card data in any form and for any length of time (assuming the full PAN etc.). This is true even if a different component encrypts it first. If none of the above is true, PCI does not apply at all. So, the question is - does the CHD reach your system or not? If yes, then it is as I said; if no, then I am wrong and this is completely irrelevant, since you are not required to comply with PCI in the first place. – AviD Oct 29 '12 at 13:30
0

First of all, let me just say that @Polynomial is 100% right. When handling/storing with CC data, PCI DDS cannot be ignored.

Also, as @AviD correctly pointed out, this is not "just" a security issue but a regulation issue as well.

Having said all that I wanted to offer a way around you problem.

If I understand you correctly here, you are trying to deal with the section 6.6 of the bill that calls for periodic code reviews (after each update) or for integration with a PCI DDS compliant WAF (Web Application Firewall).

PCI DDS 6.6 explained

Vulnerability Scanning is mostly geared towards the 1st option, as it will help you identify weak spots in your code (and hopefully patch them). While there are some advantages to this, they are mostly long-term ones and - as you correctly stated - in the short-term this will be a much more time consuming and costly activity.

I would suggest going the other way and installing a PCI DDS compliant WAF "around" you network of sites.

This will take absolutely no time and provide you with the same (or even better) level of protection + instantly solve PCI DDS related issues. This can also be used as a temporary solution, to be replaced in a future (when you'll have the time to deal with code vulnerabilities).

Thanks to advances in Cloud technology, today you can "rent" a PCI DDS compliant WAF for just a few dozen dollars a month. Currently this service is only offered by one security company (a well known company for which I currently work for and won't mention here because I don't want to "plug" our services).

I will say that:

A. You can get full protection in just a few minutes (simple DNS change)

B. You will have an option to produce PCI DDS Reports

C. As an extra "bonus" the service is also combined with Gloal CDN and Caching acceleration and Spammer protection

I hope this will help solve your problem.

GL

Igal Zeifman
  • 563
  • 3
  • 8
  • Hi Yigal, very interesting service - but I dont think he was talking about 6.6 with the vulnerability scans, I dont have standard in front of me to check but I remember that the scanning is a different requirement from CR/WAFs. – AviD Oct 28 '12 at 08:48
  • Interesting point. I know that PCI DDS also calls for quarterly vulnerability scans but this is not as time consuming as OP described (simply because of the required rate of once/3 month). Still, the scan itself is not nearly as demanding as the resulting patching and with PCI compliant WAF, this should not be required, simply because the WAF will compensate for code related vulnerabilities. Of course this is not "plug in and get full PCI compliance forever" tool :) Still, it will help a lot. – Igal Zeifman Oct 28 '12 at 09:57
  • To clarify the work load for Section 11.2, in order to complete the internal vulnerability scans, I would have to setup/create site2site VPNs for each site, purchase software or a hardware scanning tool to cover all IP's and find someone else to run those scans as it cannot be Me or our Support guys who maintain the network. Additionally all vulnerabilities would need to be patched quickly.Yes the scans only have to run once a quarter but im trying to focus on the fact do i need to do them at all? I see it as something we should do, but not necessarily for PCI at the moment. – Michael Lock Oct 29 '12 at 12:21
  • Understood. The answer is "Yes". For PCI DDS compliance you MUST run quarterly audits and "Yes", if you store CC data you should be compliant - even if not accessing it directly. (PCI compliance required for handling of CC data, this includes storing/transmitting) Having said that, I think you'll find that - once initially performed - the quarterly scans are not as taxing as the "audit after each change" 6.6 requirements. Maybe it will be different in your case, as it depends on change rates, but this is how things are in general... – Igal Zeifman Oct 30 '12 at 13:37
  • Also, I understand that the data is fully encrypted but I don't think that this changes things. Statement like "there is no way anyone could hack that or retrieve the decryption keys..." sounds too good to be true and some guys I know would consider this a challenge :) Still, I would like to learn more here. If you will obtain an official answer to this (and I think you should), please post it here so we can learn more from it. Thanks! – Igal Zeifman Oct 30 '12 at 13:44