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.




Network Security Web-App-Sec
[Top] [All Lists]

Re: PCI DSS Compliance

Subject: Re: PCI DSS Compliance
Date: Thu, 29 Dec 2005 11:25:54 +0100
Lyal, all,

Sorry for the delay-- I had vacation.

Lyal Collins wrote:
I don't think it's a question of the PCI document being right or wrong, but
of compliance to a set of domumented requirements in order to either stay in
business or minimise financial impact on a company if a security breach
involving credit cards occurs.

This is indeed a problem where compliance is seen as protection. The two are very often not the same. Why accept the PCI document as one
that minimizes financial impact, privacy breaches, etc. if the premise
only scratches the surface of the definition of protection? We cannot simply accept that products, blacklists, and the products that love them are to be regulations. Compliance should be simply the do's and don'ts of protection and loss controls with metrics to assure compliance. Remember that best practices are not best for all. The protection requirements should be documented but not the process of achieving them.



PCI requires, among 190+ other things, vuln scanning of all internet facing systems, and those internal systems that process cardholder data, not the entire internal network. PCI also requires an annual pen-test, to attempt to exploit scanning-discovered vulnerabilities. Of course you may choose to scan the rest of the entire network as part of enterprise security management.

Pen tests are another thing that are also poor security tests.
Requiring a pen test is barely better than requiring a vulnerability
scan of systems that hold cardholder data. But maybe I don't understand what you mean by pen test. To me it's a test for exploiting weaknesses in a network to raise privileges and meet a pre-assigned goal (such as card member data).


In that case a pen test is big mistake. A black box pen test can only ever be favorable to the client as opposed to one where the tester has more information about the network, the systems, the processes, and the alert/alarm profile. The latter is more beneficial to the card holders and the card issuers because it would mean something about testing protection and loss controls and not just the tester's skills.

Sure PCI is about compliance but takes the wrong approach to be about
protection and loss controls. For example, just asking for a third-party every year is such a huge generalization because if you consider the speed of progress, then shouldn't sites with more interactions, a greater scope, need more frequent audits than smaller ones? If this was based on a metric, you could assure audits were done whenever the metric reached an unsavory number.


I know this document came out to improve things but it's still far from that goal.

Sincerely,
-pete.

<Prev in Thread] Current Thread [Next in Thread>