Shared Hosting and PCI DSS

[Magnafix]

I work for a relatively small web hosting company that hosts hundreds of ecommerce stores on a shared hosting cluster. Customers upload their own ecommerce software and manage their own stores.

I believe we meet all the requirements of Appendix A, and we have some work to do to bring our CDE into compliance.

If all of our ecommerce customers do quarterly scans (which inevitably produce false positives), then we will receive, on average, something like 4 scan reports every single day of the year.

I have been searching for a while and can't find how other hosting companies are handling this.

I have 100 other questions but this is the one that is causing us pain right now.

Thanks in advance for any replies.

[jbhall56]

What a lot of hosting companies are doing to address this is to conduct their own quarterly scanning and penetration testing and submitting the results to their customers. The cost of this scanning is part of the customer's charges for having their e-Commerce site hosted.

That said, since you are getting the scanning reports, it implies that your organization is responsible for the patching and management of the operating systems and likely the major services run on these servers. As such, these activities are NOT covered by Appendix A of the Security Assessment Procedures. Services provided by hosting providers above and beyond the hardware and physical security and environmental controls need to be covered within the 12 requirements of the Security assessment Procedures.

Under my previous assumptions of the services you are providing for OS maintenance, you are likely going to be on the hook for Requirement 2 because you are configuring the servers, Requirement 5 for maintaining anti-virus, Requirement 8 because your personnel have accounts on these systems, Requirement 11 if you adopt to do your own vulnerability and penetration testing, and Requirement 12 for your policies regarding the management of your own business and personnel that involve your services that must be PCI compliant.

That's just for what we know from your posting. If you are providing other services such as backup and recovery and others, those services will bring additional PCI compliance responsibilities. This is why most hosting companies go through their own PCI assessment process that they then provide to their customers (free or for a fee) so that their customers know what portions of the PCI Security Assessment Procedures they are responsible.

[Magnafix]

Thanks for the reply.

Our assumption is that we need to comply with 1 through 12 with regards to our CDE -- which stands apart from our shared hosting platform, and additionally, the shared hosting platform needs to comply with Appendix A.

But it sounds like you are saying our shared system is subject to complete compliance requirements too, because it handles somebody else's CHD?

You mentioned our role as the maintainers of the operating system and major services:

Yes - we maintain these on the shared hosting system. We also offer managed dedicated servers, and we are responsible for patching the operating system on those as well.

We provide backup and recovery services for both our shared system and managed srevers as well.


Are you saying that because our customers (probably) handle CHD on these systems we maintain, we are responsible for full PCI Compliance on all those systems? If so, is there a specific section that leads you to that conclusion?


Finally, we offer unmanaged virtual private servers. We install the operating system and then hand complete administrative access to the customer and they are responsible for upkeep and services thereafter. Our conclusion is that these customers are on their own to take whatever measures they deem appropriate to maintain compliance.


It sounds like there is indeed a provision buried somewhere which will allow us to present our quarterly scan results to our customers, and inform them to stop sending in their own independent scan results, at least for our shared system. Is that right? If so, where is that stated?


Like I first mentioned I have 100 questions; here's one more related to shared hosting:

I cannot see tens of thousands of small web hosts ever meeting the one-service-per-server requirement (2.2.1), and the firewall requirements (1.3.6, 6.6). As customers begin demanding 100% compliance from their web hosts and these smaller hosts are slowly driven out of business, I hope the growing PCI Compliance industry can create jobs for those entrepreneurs and their employees. Am I missing something?

[wconway]

Our assumption is that we need to comply with 1 through 12 with regards to our CDE -- which stands apart from our shared hosting platform, and additionally, the shared hosting platform needs to comply with Appendix A.

But it sounds like you are saying our shared system is subject to complete compliance requirements too, because it handles somebody else's CHD?

I would agree you need to comply with the full PCI DSS since from what you describe, it sounds like you are a Service Provider. And based on your having "hundreds" of e-commerce sites using your service, you are likely a Level 1 Service Provider per the new Visa definition.

As for your customers, if my understanding is correct then they likely qualify for SAQ A (if they don't store any cardholder data electronically) and they won't need to do any scanning at all.

[Magnafix]

I would agree you need to comply with the full PCI DSS since from what you describe, it sounds like you are a Service Provider. And based on your having "hundreds" of e-commerce sites using your service, you are likely a Level 1 Service Provider per the new Visa definition.


!! Visa expects us to guesstimate the number of ALL our customers' transactions in a year and include them for the purposes of defining our Service Provider Level? We are Level 3, internally, and have no good way to estimate how many transactions our customers might be processing on our servers since they install whatever web apps/gateway software they want.

As for your customers, if my understanding is correct then they likely qualify for SAQ A (if they don't store any cardholder data electronically) and they won't need to do any scanning at all.

We don't know whether our customers are storing cardholder data -- they install X-Cart, Zencart, OSCommerce, Interspire Cart, whatever they desire.

We are striving to reduce the scope of our CDE, but it sounds like you're saying that the hosting provider must treat their entire infrastructure as the CDE if they have a single customer who is processing their own transactions?

[jbhall56]

You mentioned our role as the maintainers of the operating system and major services:

Yes - we maintain these on the shared hosting system. We also offer managed dedicated servers, and we are responsible for patching the operating system on those as well.

We provide backup and recovery services for both our shared system and managed srevers as well.

Are you saying that because our customers (probably) handle CHD on these systems we maintain, we are responsible for full PCI Compliance on all those systems? If so, is there a specific section that leads you to that conclusion?

While the services you provide to your customers provide great assistance, they are also covered under requirements of the PCI DSS. Since you perform these services instead of the customer, your organization is on the hook to ensure compliance of these services with the PCI DSS.

This is the problem hosting providers run into. They provided a lot of additional services such as security, OS maintenance, backup and recovery and the like, not realizing that these services require PCI compliance if the customer is processing, storing or transmitting cardholder data (CHD). That is why we recommend to our hosting providers that they ask their customers annually whether or not they are processing, storing or transmitting CHD from the systems hosted. If the customers do process, store or transmit CHD, then our hosting providers typically move these systems to a different part of their hosting facility that they maintain as PCI compliant and is annually assessed by a QSA.

Finally, we offer unmanaged virtual private servers. We install the operating system and then hand complete administrative access to the customer and they are responsible for upkeep and services thereafter. Our conclusion is that these customers are on their own to take whatever measures they deem appropriate to maintain compliance.

Yes, these customers are responsible for their PCI compliance and you are only responsible for those items documented in Appendix A.

It sounds like there is indeed a provision buried somewhere which will allow us to present our quarterly scan results to our customers, and inform them to stop sending in their own independent scan results, at least for our shared system. Is that right? If so, where is that stated?

The PCI DSS requirement responsibilities are with the organization and their personnel that actually perform the activity covered by the requirement. As an example, for some customers, you maintain their systems and those activities are covered by a variety of PCI requirements and your organization is responsible for ensuring they are PCI compliant.

I cannot see tens of thousands of small web hosts ever meeting the one-service-per-server requirement (2.2.1), and the firewall requirements (1.3.6, 6.6). As customers begin demanding 100% compliance from their web hosts and these smaller hosts are slowly driven out of business, I hope the growing PCI Compliance industry can create jobs for those entrepreneurs and their employees. Am I missing something?

Unfortunately, those hosting companies have to comply with the PCI requirements. That said, there is the compensating controls approach to meeting requirements. But any compensating control MUST go above and beyond the requirement it is addressing, which in a services environment typically means even more work than just meeting the requirement.

And remember, the PCI DSS is nothing really new. It's just a compilation and codification of information security best practices. Things companies should be doing regardless of whether we're talking about CHD or social security numbers, drivers license numbers or any other personally identifiable information (PII). It all needs to be properly protected so that it cannot be readily released by just anyone with access to the system.

For the firewall requirements, there is absolutely no excuse in this day and age for not having a network firewall in place. While I know there are a lot of geeks out there that believe they can totally harden an OS and not use a firewall, it's just not a prudent business practice because there are typically just too many customers to make sure that you are always on top of every device you have.

In regards to requirement 6.6, an application firewall can be used OR code reviews can be used. And automated code review tools such as AppScan and the like can used, but they must be part of the development cycle and cannot be used after the fact once the application is put into production. The point of requirement 6.6 is to minimize the amount of risky code that ends up on the Internet.

I would recommend that you search the Forum as the bulk of your questions have likely already been discussed here.

[Magnafix]

This is the problem hosting providers run into. They provided a lot of additional services such as security, OS maintenance, backup and recovery and the like, not realizing that these services require PCI compliance if the customer is processing, storing or transmitting cardholder data (CHD). That is why we recommend to our hosting providers that they ask their customers annually whether or not they are processing, storing or transmitting CHD from the systems hosted. If the customers do process, store or transmit CHD, then our hosting providers typically move these systems to a different part of their hosting facility that they maintain as PCI compliant and is annually assessed by a QSA.


I predict that 95%+ of hosts will not do it, ever.

What do they risk? Will merchant account providers invent ever-higher non-compliance fees to eliminate their own customers?

[cmark]

PCI compliance is the responsibility of the organization who owns the data. In a shared hosting environment where it is truly shared hosting and the client can upload whatever they want, then the merchant is responsible for ensuring they are using a hosting provider that meets their needs. Simply having merchants that house data in a hosting environment does not impose the requirements upon the hosting provider.

There are two basic paths here. 1) the merchants need to ensure they are using a hosting provider that complies with the PCI DSS or 2) the merchants need to ensure they can manage their own systems in accordance with PCI DSS.

The fact that you (Magnafix) are actually complying with appendix A puts you in rare company. Very, very few hosting providers care or are even attempting to pursue compliance with requirement A.

Long and short...yes you are a service provider BUT you are not storing, transmitting or processing data. You simply own the systems that allow merchants to do so. Your responsibility is to comply with appendix A unless you manage the ecommerce sites or provide some other function that puts you in the category of storing, transmitting, or processing CHD. Consider a telco as another example. If my company decides to transmit unencrypted cardholder data across Verizon, it is difficult to believe that this would not place Verizon in the category of a service provider that is responsible for the data as they are providing the mechanism to transport. Much of this is related to intent and knowledge. If you are selling a hosting solution that says: "Use our super duper eCommerce hosting" then I think you are now assuming more responsibility for the data.

With regard to the scans, you should have a quarterly scan as the merchants likely do not have the ability to make any changes to the systems/FW. It doesn't make much sense in my mind for the merchants to be scanned in a shared hosting environment as they cannot fix any identified issues. Your scan should be sufficient for the merchants' compliance needs although I suspect you will get grief as it will impact the revenue of the ISOs and ASVs. Unfortunately, there are a large number of ASVs partnering with acquirers and requiring 'opt out' scanning for merchants.

[Magnafix]

Long and short...yes you are a service provider BUT you are not storing, transmitting or processing data. You simply own the systems that allow merchants to do so. Your responsibility is to comply with appendix A unless you manage the ecommerce sites or provide some other function that puts you in the category of storing, transmitting, or processing CHD.

So you disagree with wconway above who proposed that the aggregated transactions of our hundreds of hosted merchants place us in the Level 1 (highest) level of merchant? That would really be a worst case scenario for us.

[derra]

Yes cmarc is correct.

[cmark]

Walt is very good at PCI. In this case I disagree.

The aggregate transactions would not count unless you were selling eCommerce hosting and were the gateway and had responsibility for some one else' data. In the scenario described you are simply providing hosting (unless my assumption is incorrect) and therefor have no real responsibility for the fact someone may or may not have data in their account. This is a very confusing situation but you do not have responsibility for those merchants. Your job is the comply with Appendix A. In reality your non-compliance is not an issue as well. You are not in the card brand chain. You are simply complying as a courtesy to your clients and your non-compliance is not a compliance issue for the merchants.

As you are likely to get some conflicting views let me say(I apologize to those who know me or feel I am being arrogant) that I worked at MasterCard, was on the PCI SSC Technical Working group and trained over 1,500 QSAs worldwide. This is the world in which I live.

Please call me directly if you have any further question. 435-513-0484

[Magnafix]

Walt is very good at PCI. In this case I disagree.
The aggregate transactions would not count unless you were selling eCommerce hosting and were the gateway and had responsibility for some one else' data. In the scenario described you are simply providing hosting (unless my assumption is incorrect) and therefor have no real responsibility for the fact someone may or may not have data in their account. This is a very confusing situation but you do not have responsibility for those merchants. Your job is the comply with Appendix A. In reality your non-compliance is not an issue as well. You are not in the card brand chain. You are simply complying as a courtesy to your clients and your non-compliance is not a compliance issue for the merchants.


Thanks for the reply.

There's a lengthy discussion of hosts' responsibilities over at webhostingtalk (http://www.webhostingtalk.com/showthread.php?t=751732) too.

I understand that there's no way for us as a host to try to ascertain our clients' individual compliance status, but the fact remains that if all small business e-commerce customers began efforts to become compliant, there would be tremendous impacts on hosting companies, including at least:



Demands from customers to establish contractual relationships in which hosts accept full responsibility for cardholder data collected by the customers. (12.8.2)
Demands from customers that their hosts become fully PCI DSS compliant. (12.8.4)
A barrage of customer-initiated quarterly scans and the associated research to deal with the inevitable false positives.

And that doesn't begin to account for the formidable amount of work required for a small web hosting company (of which there are many thousands in the US alone) to re-architect their existing systems to comply.

Hence, my hypothesis that a tiny fraction of hosting companies will actually try, since (unless something changes) there's little perceivable benefit to becoming compliant currently (despite it being "required").

[cmark]

I agree. That is why I feel the PCI is not feasible for small, level 4 eCommerce merchants. Those merchants, in my opinion, should focus on removing the data from the equation. There are a number of solutions that rely upon hosted payment pages. The EMEA region, and the EU are heavily invested in hosted payment pages. In this way the merchant does not store, transmit, or process CHD and the PCI DSS requirements do not apply....and your company is not in the middle. There are a huge number of ASVs making a bunch of money pushing scanning for small merchants. It is both ineffective and expensive for many small merchants. Over 70% of internet related compromises result from SQL Injection. The scans conducted by the ASVs focus upon network layer vulnerabilities and cannot detect SQL Injection vulnerabilities.

Check out Mercantec, ProPay and some of the other companies focusing on alternative solutions. This is where PCI is headed, in my opinion.

[wconway]

Walt is very good at PCI. In this case I disagree.

The aggregate transactions would not count unless you were selling eCommerce hosting and were the gateway and had responsibility for some one else' data.

Chris is, of course, correct. I mis-interpreted Magnafix' situation to include hosting. I'll take the FUBAR hat for the day.

[cq142]

your non-compliance is not a compliance issue for the merchants

I am having trouble making sense of this statement. If I want my e-commerce site to be PCI DSS compliant, won't I need a PCI DSS compliant host?

[jbhall56]

What Chris is pointing out is the PCI compliance of any third parties you use for hosting and the like does not affect your organization's PCI compliance. The rationale is that you have no control over them. However, you are required to monitor their progress on their achieving PCI compliance.

IMHO, organizations using non-PCI compliant third parties need to have a 'Plan B' in place if a third party refuses or fails to become compliant. You need to establish timeframes for these organizations and if they do not achieve compliance within the timeframe, then you need to take your business elsewhere.

[cmark]

Thanks jbhall, I couldn't have said it better.

[Magnafix]

What Chris is pointing out is the PCI compliance of any third parties you use for hosting and the like does not affect your organization's PCI compliance. The rationale is that you have no control over them. However, you are required to monitor their progress on their achieving PCI compliance.

IMHO, organizations using non-PCI compliant third parties need to have a 'Plan B' in place if a third party refuses or fails to become compliant. You need to establish timeframes for these organizations and if they do not achieve compliance within the timeframe, then you need to take your business elsewhere.

As far as I can tell, ASVs (e.g., SecurityMetrics) are notorious (among my customers) for insisting that the only requirement to become compliant is a clean scan.

And - my sense is that 99% of smaller web hosting companies (that host in aggregate millions of small ecommerce operations) are not and will not be (truly) PCI DSS compliant any time soon -- for most, probably never.

[jbhall56]

A clean scan is all in the eye of the beholder. ;)

There is a significant amount of work to prove that all vulnerabilities identified are truly vulnerabilities and NOT false positives. In a great number of instances, a lot of high, critical or severe vulnerabilities are actually false positives that cannot be exploited. This is why the PCI DSS now requires penetration testing so that the false positives get taken out and the real vulnerabilities can be addressed.

BTW It's our experience that most mid-sized ISPs/ASPs can pass vulnerability scanning and penetration testing of their PCI in-scope systems. This may surprise some (it did me at first), but it's amazing how much these organizations see their ability to comply with PCI as a competitive advantage over their larger brethren.