Subject: Re: Mambo, Coppermine and PHPBB Attacks - msg#00120

Previous Message by Date: click to view message preview

RE: PCI DSS Compliance

I don't think many people think PCI is perfection (apart from marketing, perhaps:-) It seems to be reasonable, affordable mix of requirements that strives to be technology neutral. PCI already has about 4 layers of compliance needs, depending upon the annual volume of cards processed. These range from 'be careful' (very small volumes) to self assessment through to on-site accredited audits and vuln-scanning ( >6million cards pa). Technology and architeecture nuerality is a critical constraint in my view its easier to write a specific document for a single software architecture and product/tech mix. There is a very broad variety o ecomm archictures and techo/product mixes ot there - one client I work with (150 people and quite profitable) has an issue that a single PCI compliance aspect will cost around 5% of annual revenue (not profit) plus 12-20 person months to fix in 1 for just of their 3 payment processing 'streams' due to legacy impacts from decisions made years ago. In this single casse, a lack of well developed and robust products APIs etc in the market, plus architecture choices made before PCI/CISP et all were dreamt of continue to impact, meaning ustom APIs and code redevelopment or platfrom replacement is needed. So I stand by the view that PCI al-la '2005-style' is a good start, but we will continually need to get better security, at the level and pace that the business can afford. Since security people are generally bad at getting money to spend (or spend wisely in many cases), an industry wide driver approach is, in my view a good thing to get corporate commmittment. Will PCI fix all card security today - no; the majority of the reported compromises of card details over the past 18 months stem from failures of technology or process at card scheme members (i.e banks) who are not required to comply with PCI/AIS/CISP/SDP. The PCI of, say 2010, won't be the PCI of today - but I bet this current debate could happen then much as it is happening now - security is never perfect, just good enough for the risks the business is prepared to spend on! Lyal -----Original Message----- From: Pete Herzog [mailto:lists@xxxxxxxxxx] Sent: Thursday, 29 December 2005 9:26 PM To: Lyal Collins Cc: 'Craig Wright'; webappsec@xxxxxxxxxxxxxxxxx Subject: Re: PCI DSS Compliance 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.

Next Message by Date: click to view message preview

Re: PCI DSS Compliance

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.

Previous Message by Thread: click to view message preview

Re: Mambo, Coppermine and PHPBB Attacks

On Mon, 26 Dec 2005, Yasuo Ohgaki wrote: > But I don't insist nx bit support is useless. I'm not sure I follow this one? Are you meaning: http://en.wikipedia.org/wiki/NX_bit > Anyway, most php script do not need remote script execution feature. > And even with SELinux, it cannot prevent to execute remote code while > access to local file could be rejected and reported. > > Making allow_url_fopen useless is bad thing. Can you expand on this one please, or are you throwing it back to your original reply? -- Paul Laudanski, Microsoft MVP Windows-Security [cal] http://events.castlecops.com [de] http://de.castlecops.com [en] http://castlecops.com [wiki] http://wiki.castlecops.com [family] http://cuddlesnkisses.com

Next Message by Thread: click to view message preview

Re: Mambo, Coppermine and PHPBB Attacks

Yasuo Ohgaki wrote: OWASP guideline may be better to be updated, since allow_url_fopen=off is not practical and allow_url_fopen=off does not provide good enough safe guard. good points allow_url_fopen and many other functions try to do their best at the application level often php is uber hardened while cgi and exec are still allowed so imho the best combination is: - try to solve the problem with php settings (url fopen, open basedir, exec dir, etc) and with apache (the favolous perchild concept :P) - set up some acl system like selinux or rsbac - set up grsec and use the group socket restrictions is there somebody "developing" mpm-perchild? too late for long emails, Francesco 'ascii' Ongaro - http://www.ush.it/