PA-DSS is not a security panacea as the other stated as well. I read someone mentioned about looking into your SDLC. That's a good starting point. Don't look at security as a check box to meet the PA-DSS or any other compliance needs. That's when you fail. It should be an integral part of your thought process when designing and developing software, not a bolt on. Lastly, the QSA is not to be blamed completely not knowing what environment and circumstances were available to the QSA when the engagement was performed and if those parameters changed when the product was delivered to the client (eg, your WAS might filter out reflected XSS while they do not have such filtering in their test environment. Another example, the QSA tested on chrome or IE with XSS Auditor enabled while the client tested with all bets off). The reality is there are vulnerabilities in the application. Your answer (since you said you have no answer) should be to assure the client that you would go back to the drawing boards and take reasonable measures to fix the flaws before re-delivering the app. If you don't have a good SSDL in place, this might be a good opportunity to start thinking about it and getting your management involved :) Hope this helps! Cheers, Prasad On May 28, 2013, at 10:18 AM, Steve Kerns <Steve.Kerns@netspi.com> wrote: > Can an application be hacked even if it is PA-DSS validated? The answer is yes? Have you made any changes to the application since the validation? If so, are you performing code reviews and your penetration testing against the application? Are you doing these internally or do you have them performed by a third party? > > These should have been caught before the validation process during your testing/QA phase. The auditor should have also caught them, but depending on their skills, they may have not performed the right tests or used the right tools. > > I am curious, what company did the PA-DSS validation? > > Steve Kerns > > From: websecurity [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of sarvesh shete > Sent: Friday, May 24, 2013 1:25 AM > To: Christian Heinrich > Cc: websecurity@lists.webappsec.org > Subject: Re: [WEB SECURITY] [Web Security] Can a PADSS certified system be hacked > > Thanx Maanav, Thanx Christian! > > Actually why I asked this question is because same case happened in my organization. > I work for a company who develops banking products. We have a product PADSS certified and while delivering it to a bank who is our new client; the product 'go live' has been put on hold because bank carried out penetration testing from other company who is specialized in penetration testing based on pure hacking stuff. Though the pen testers could not break encryption or hashing done on stored card numbers but were able to find flaws in few screens of application like XSS, SQL injection etc because in some screens developers missed out server side validations. Now the client bank says if your product is PADSS certified then why such issues? It must be completely secure. We have no answer! Surely we can fix the same but we have got no explanation why such issues still exist even though product is PADSS certified. > > On May 24, 2013 8:56 AM, "Christian Heinrich" <christian.heinrich@cmlh.id.au> wrote: > Sarvesh, > > I provided an overview of the political and technical deficiencies > within http://www.slideshare.net/cmlh/padss back in 2010. > > On Tue, May 21, 2013 at 1:16 PM, sarvesh shete <sarvesh.sse@gmail.com> wrote: > > Can a system which is PA DSS certified be hacked? > > Hacked means not in case of getting sensitive data(data is stored with > > AES256 and strong cryptography mechanism) but hacked means getting vertical > > privilege escalation, XSS, Sql injection in the application. > > Is it possible that the application is developed by secure coding techniques > > and includes the code for handling XSS, sql injections etc and is PADSS > > certified but still can it be hacked? > > > > -- > Regards, > Christian Heinrich > > http://cmlh.id.au/contact > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Prasad, On Wed, May 29, 2013 at 12:44 AM, Prasad Shenoy <prasad.shenoy@gmail.com> wrote: > Lastly, the QSA is not to be blamed completely not knowing what environment > and circumstances were available to the QSA when the engagement was > performed and if those parameters changed when the product was delivered to > the client (eg, your WAS might filter out reflected XSS while they do not > have such filtering in their test environment. Another example, the QSA > tested on chrome or IE with XSS Auditor enabled while the client tested with > all bets off). This would be addressed within the "PA-DSS Implementation Guide" which is a requirement to be listed on https://www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php -- Regards, Christian Heinrich http://cmlh.id.au/contact

Sarvesh, On Wed, May 29, 2013 at 12:18 AM, Steve Kerns <Steve.Kerns@netspi.com> wrote: > I am curious, what company did the PA-DSS validation? I have to agree with Steve (and others) here that we need to know if the person and or company was qualified to do so i.e. https://www.pcisecuritystandards.org/approved_companies_providers/payment_application_qsas.php ? Also, if you could indicate which application(s) you are referring to that are listed on https://www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php would be helpful too? -- Regards, Christian Heinrich http://cmlh.id.au/contact

Well that is exactly why the client is puzzled as well :)..... Cheers, Prasad On May 28, 2013, at 8:33 PM, Christian Heinrich <christian.heinrich@cmlh.id.au> wrote: > Prasad, > > On Wed, May 29, 2013 at 12:44 AM, Prasad Shenoy <prasad.shenoy@gmail.com> wrote: >> Lastly, the QSA is not to be blamed completely not knowing what environment >> and circumstances were available to the QSA when the engagement was >> performed and if those parameters changed when the product was delivered to >> the client (eg, your WAS might filter out reflected XSS while they do not >> have such filtering in their test environment. Another example, the QSA >> tested on chrome or IE with XSS Auditor enabled while the client tested with >> all bets off). > > This would be addressed within the "PA-DSS Implementation Guide" which > is a requirement to be listed on > https://www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php > > > -- > Regards, > Christian Heinrich > > http://cmlh.id.au/contact

Not all PA-QSAs are created equal. Penetration tests are mostly black-box (unless you choose a white/gray box test specifically). In such tests, some vulnerabilities are sure to be missed. But the keyword here is *some*. Seems like the PA-QSA company did not do the assessment properly and went ahead with whatever would fly. So the answer is you need to change your PA-QSA vendor. Thanks, Rajat. On Tue, May 28, 2013 at 8:43 PM, Christian Heinrich < christian.heinrich@cmlh.id.au> wrote: > Sarvesh, > > On Wed, May 29, 2013 at 12:18 AM, Steve Kerns <Steve.Kerns@netspi.com> > wrote: > > I am curious, what company did the PA-DSS validation? > > I have to agree with Steve (and others) here that we need to know if > the person and or company was qualified to do so i.e. > > https://www.pcisecuritystandards.org/approved_companies_providers/payment_application_qsas.php > ? > > Also, if you could indicate which application(s) you are referring to > that are listed on > > https://www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php > would be helpful too? > > > -- > Regards, > Christian Heinrich > > http://cmlh.id.au/contact > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > -- Rajat Swarup www.rajatswarup.com

Yes, now I got all my doubts clear. Thanx everyone! On Jun 15, 2013 1:53 AM, "rajat swarup" <rajats@gmail.com> wrote: > Not all PA-QSAs are created equal. Penetration tests are mostly black-box > (unless you choose a white/gray box test specifically). In such tests, some > vulnerabilities are sure to be missed. But the keyword here is *some*. > Seems like the PA-QSA company did not do the assessment properly and went > ahead with whatever would fly. > So the answer is you need to change your PA-QSA vendor. > > Thanks, > Rajat. > > > On Tue, May 28, 2013 at 8:43 PM, Christian Heinrich < > christian.heinrich@cmlh.id.au> wrote: > >> Sarvesh, >> >> On Wed, May 29, 2013 at 12:18 AM, Steve Kerns <Steve.Kerns@netspi.com> >> wrote: >> > I am curious, what company did the PA-DSS validation? >> >> I have to agree with Steve (and others) here that we need to know if >> the person and or company was qualified to do so i.e. >> >> https://www.pcisecuritystandards.org/approved_companies_providers/payment_application_qsas.php >> ? >> >> Also, if you could indicate which application(s) you are referring to >> that are listed on >> >> https://www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php >> would be helpful too? >> >> >> -- >> Regards, >> Christian Heinrich >> >> http://cmlh.id.au/contact >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> > > > > -- > Rajat Swarup > www.rajatswarup.com >