JayBee thanks for posting back more detailed information. 

http://www.aspdotnetstorefront.com/t-pabp.aspx - that outlines aspdnsf committment to this compliancey

I did a bit more research on this - and I found this information here -

http://usa.visa.com/merchants/risk_management/cisp_merchants.html - here is their interpretation of Level 3 & Level 4 as mentioned in your above comments -

<begin Quote -

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

- End Quote>

I then downloaded quite a bit of information I am going to read through it more. I appreciate there is the need to create a more secure environment, but I still cannot see how DNN can be responsible for providing full compliancy - some of the documents talk about firewall settings - and that is not any responsibility of DNN no matter how I see it.

I did see there was documentation you could provide under these guidelines -

• Annual SAQ recommended
• Quarterly network scan by ASV if applicable
• Compliance validation requirements set by acquirer

I read the SAQ recommendations and it covered some fairly typical things and not relevant if you don't store credit card information.

There are different levels of documentation depending on the type of ecommerce solutions you provide and I believe you fall into category A which is ecommerce provider, with others being things like portable ecommerce, kiosks, unattended locations for taking card information and how that was managed.

I also saw there were about 520 participating organisations, aspdnsf was not one I could see but at 2,500 US per year, started by the credit card companies in the first place, it's not going to be affordable for everyone to be 'participants' BUT that has nothing to, from what I can read about the compliancy costs - I couldn't find them but will do some further reading.

I noted there are already quite a few companies that have complied and fit into different categories in refernce to PA-DSS which are Payment Application providers and fall into different categories - so it's going to be some interesting reading and I can only make assumptions on the legalities not being a lawyer.

Most of the issues I see come from people storing credit cards on servers when it comes to ecommerce and no matter how hard I try to read into this, I can't see how DNN can be held responsible, and it seems to be a unusual stance to take, considering even without DNN, I was unable to see ASPDSF could ever be compliant without the hosting provider being compliant too.  At what point can DNN be certified to handle computer IP addresses, update AntiVirus systems regularly and restrict phsyical access to card holder data?  

I'm interested in reading more about this - we're looking at the TNSI gateway at the moment - and they just bought out some elements of Verisign, so I'll see what I can find out from someone within that company and shed more light there - this company is also involved in the PCI-DSS area from what I read on their website and the PCI one.

I understand some of the comments here about interpretation of gateways but there are many facets on how people do business online, and storing someone's credit card on the server for transactions later on indicate to me that 1 - they are too tight to spend more on a secure method of transactions, 2 - they are not correctly setup for online transactions as you have a different Merchant ID for online transactions than you do with your swipe machine - it's another account altogether, or 3 - they really don't care about other people's security - ... refer to 1 if you have questions on that.

I tell my clients if you want to go online - you get a payment gateway - full stop - and if you can't invest in the infrastructure, use paypal - not that I like that option, but no way will I ever store credit card information on my servers, however, I will be writing a blog shortly about the person who thought they were doing the right thing and still got stung by a thief.

Nina

I have a DNN site which is PCI-DSS compliant including PCI-DSS scans using ASPDNSF MLL/DNN which should be PA-DSS (formally PABP) compliant by grandfather compliance of the base code. It is possible to simply change a DotNetNuke or ASPDNSF setting to make it uncompliant.

PCI-DSS involves all sorts of issues beyond DotNetNuke, including IIS and SQL and other relatd components.

PCI-DA is only applicable to the application that deals with credit cards info, yet the two are very intertwined and often unrelated.

This is one ofthe most confusing implementations I have ever seen. They even have troubles with their own acronyms.