Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: PCI DSS Compliance |
|---|---|
| Date: | Wed, 14 Dec 2005 17:45:07 -0500 |
On Tue, Dec 13, 2005 at 11:36:43AM -0500, Ademar Gonzalez wrote:
A shared hosting client needs to get his site PCI DSS certified. He forwarded us the following request from the company doing the assessment. "Your site could not be certified. Your site appears to be running scan detection software, that has prevented a reliable port scan. This test is inconclusive. Please add our scanner ip: ##.##.##.## to your scan detection software exclusion list to allow our scanner to make a complete assessment of your system." Is this request plain stupid or what ? Comments ?
It looks like the client runs the risk of not being certified 'cause his website is over-protected. How would you proceed in this situation ?
For those unfamiliar with PCIDSS: http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html (I believe Visa/MC/etc. have simliar programs for other regions besides USA.)
From what I've seen, typically the companies who are certified by
Visa, Mastercard, etc. to perform Payment Card Industry Data Security Standard external network audits will announce a ~48 hour window in which they'll scan the network. So the merchant site needs only to disable any auto-response mechanisms for the auditer's IPs for that particular window of time. Remember that the auditers aren't asking for any special access or firewall holes. I think it's reasonable. PCIDSS scanners check a huge number of vulns & services. It'd be pretty awful if the merchant's attack detection and countermeasure system blocked the scan after it had probed missing or "strong" services or apps, but just before the scan found that unpatched server running an OS from three years ago -- a real attacker might be luckier or smarter and get that exploit launched to your client's soft underbelly on the first try. PCIDSS is certainly not perfect, but on balance it's a good thing. Your client should play along, in my opinion. Besides, merchants who take credit card payments are contractually obliged to play along in order to keep accepting credit card payments. Few of us can *afford* to put up principled nit-picking fights about this. On a side note, I've found the PCI DSS standards to be an excellent tool for convincing corporate management to take more aggressive stances on security issues, as the costs of failing to comply, especially if an attacker is every successful in compromising your security, are *huge*. -Peter
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: PCI DSS Compliance, Craig Wright |
|---|---|
| Next by Date: | RE: PCI DSS Compliance, Steven Jones |
| Previous by Thread: | RE: PCI DSS Compliance, Lyal Collins |
| Next by Thread: | RE: PCI DSS Compliance, Sebastien Deleersnyder |
| Indexes: | [Date] [Thread] [Top] [All Lists] |