What is a Shared Hosting Provider?

PCI Requirement 2.6 exists to protect hosting environments. When multiple clients’ data is all on the same server, the security of the server often becomes susceptible to vulnerabilities. For example, one client could create insecure functions, but because the data is under the control of a single environment, the other clients’ data would also become compromised. This is why PCI Requirement 2.6 requires that shared hosting providers protect the cardholder data of every single entity’s hosted environment. PCI 2.6 states, “Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers.”

There are two parts to PCI Requirement 2.6: first, determine whether your organization is a service provider, so that you can then determine whether or not you are a shared hosting provider. If your organization supports third-parties that interact with cardholder data, or if your organization is interacting with cardholder data in some capacity, or if your organization might have the ability to impact the security of cardholder data, then your organization is defined as a service provider. If your organization is hosting applications, hosting websites, or hosting anything on behalf of a third-party, and your organization has multiple clients on the same platform, that determines you are a shared hosting provider. So, PCI Requirement 2.6 is intended for hosting providers that provide shared hosting environments for multiple clients on the same server.

PCI Requirement 2.6 also focuses on Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers. If your organization is a shared hosting provider, then Appendix A1 is applicable to you. You should perform the testing procedures outlined in Appendix A1 to verify that you are appropriately protecting hosted environments and cardholder data.

If you have any questions about whether or not you’re a shared hosting service provider, we encourage you to start that conversation with your assessor, who could walk you through the process of how to categorize your organization.

PCI Requirement 2.6 Transcription

When we get to Requirement 2.6 within the PCI DSS, that’s really kind of a pointer down to Appendix A. Specifically for PCI DSS version 3.2, it’s Appendix A1. Requirement 2.6 says that if you’re a shared hosting service provider, Appendix A1 applies to you. If you’re interested in what those requirements are and what they mean, please have a look at those videos.

Requirement 2.6, pointing down to Appendix A, has to do with shared hosting service providers, so I want to take a few moments to describe to you what a shared hosting service provider is. If you’re an organization that is supporting third-parties that interact with cardholder data and you are interacting with cardholder data in some capacity, or you might have the ability to impact the security of it, you are defined as a service provider. The other part of that clause is the shared hosting service provider. If you’re hosting applications, hosting website, hosting anything on behalf of a third-party, and you have multiple clients on the same platform, that puts you into the shared hosting service provider category. That would also make Appendix A1 applicable to you.

If you have any questions on whether or not you’re a shared hosting service provider, take the opportunity to have that conversation with your assessor. I’m sure they’d love describing that and walking you through the process to fully identify whether or not you are a shared hosting service provider.

Ensure that Policies and Procedures are Documented, In Use, and Known to All Affected Parties

PCI DSS Requirement 2.5 addresses one of the most important aspects of the assessment. It directs, “Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.” If vendor defaults and other security measures are not continuously managed, it’s harder to prevent insecure configurations; this is why security policies and procedures must be documented, in use, and known to all affected parties. We find that many organizations struggle with documentation, but policies and procedures are vital to your business. You need to have the processes in place to define how to complete tasks securely to ensure the ongoing operation and security of your organization. Small organizations, huge businesses – it doesn’t matter, you must ensure that policies and procedures are documented, in use, and known to all affected parties.

Do you know the difference between a policy, a procedure, and a standard? A policy is an executive level document that defines that something must be done. Standards are the tools, means, and methods that you will use to meet policy requirements. A policy defines that something must be done, but a procedure defines how you do it. A procedure should provide very clear, step-by-step instructions on how something must be done or is to be done. Procedures are instructions on how to run your business.

Policies, procedures, and standards should be written at a level so that someone with knowledge of the topic could be able to carry that task on. These documents aren’t intended to educate or teach someone from the ground level; someone who has knowledge of the topic should be able to read the policy or procedure and perform the task that’s detailed.

Organizations who do not implement policies and procedures do not comply with PCI Requirement 2.5. If the only time you interact with policies and procedures is during an assessment, you must begin educating your users; ensure that security policies are documented, in use, and known to all affected parties. During the assessment, your assessor will examine your policies and procedures, then examine your staff to verify that the documentation you present is actually in use.

PCI Requirement 2.5

PCI DSS Requirement 2.5 is very similar to the majority of the other requirements. You have to maintain your policies and procedures. Understand that in years past, organizations would develop policies, give them to the assessors, the assessors would sign off “Yes, they have policies,” but that was the only time that organizations would interact with them. PCI DSS Requirement 2.5 requires that you educate your users on your policies. One of the things that they added that I really appreciate is that these policies need to actually be in use.

So, this capstone that we have here is going to require that your assessor, being knowledgeable of what your policies say, interviews your staff, looks at your processes, and looks at your procedures to make sure that the documentation you have put forth is not just, what I would call, a paper tiger. Policies need to demonstrate how you go about doing your business.

Requirement 2.5 requires that you have policies and procedures that are documented, in use, and known to all affected parties.

Maintaining an Inventory of Assets

We believe that if management is not aware of an asset, it’s probably not appropriately protected. Based on PCI Requirement 2.4, we think the PCI Security Standards Council and major card brands believe this as well. PCI Requirement 2.4 states, “Maintain an inventory of system components that are in scope for PCI DSS.” In order to comply with PCI Requirement 2.4, your organization must maintain a list of the assets in your environment.

When your organization begins to define the scope of your environment, you will need this current inventory of system components. It will make the scoping process smoother, plus, without this list, some of the assets you are trying to protect may be overlooked and inadvertently excluded from your configuration standards and left vulnerable. If you don’t know what or where your assets are, how can you protect them?

Any time that you add or remove an asset from your environment, your inventory list needs to be updated. PCI Requirement 2.4 is a continuous cycle. During the assessment process, your assessor will take this documented inventory and compare it to your network and data flow diagrams. Your Change Management Program should also be involved in the process of updating this list. PCI Requirement 2.4 ties into PCI Requirements 1.1.1, 1.1.2, and 1.1.3.

PCI DSS Requirement 2.4

I’ve been doing assessments and security for the greater part of my career, and one of the positions that has always become evident to me is that if management isn’t aware of an asset, it’s likely not to be protected. The PCI DSS and the card brands have taken notice of this. When we look at Requirement 2.4, it says that we have to maintain a list of the assets that we have in our environment; these are the physical assets. This is with the intent of: if you don’t know what you have, you typically cannot protect it.

From an assessment perspective, what we’re really looking for here is that you actually have a documented list of the assets. What we do is we take that list and compare that against your network diagram and we look for some correlations there. We also might ask you for a copy of an Nmap scan being run against your environment to compare the IP addresses to the asset list that we’re given. It’s required that you maintain this list. We recommend that you have some type of hook into your Change Management Program. Any time you make a change to your asset inventory, like adding a device to the list or removing a device from the list, we recommend you hang that change control open until such time that the asset inventory in your networking diagrams and your data flow diagrams have been updated to support that.

Administrative Access and Strong Encryption

PCI Requirement 2.3 calls out the need to encrypt all non-console administrative access using strong cryptography. If your organization does not meet PCI Requirement 2.3, a malicious user could eavesdrop on your network’s traffic and gain sensitive administrative or operational information.

Your organization does not have to encrypt all types of access, just administrative access. So, what does “administrative access” mean? If a user has the ability to impact or make changes to a system or a setting that would impact the security of the sensitive data that you are trying to protect, that user should be classified as an administrative-type role. Or, if a user has the ability to impact the security of another user or change another user’s experience, that user should also be considered in an administrative-type role.

PCI Requirement 2.3 also instructs organization to use “strong cryptography,” but what exactly is classified as “strong cryptography”? The PCI DSS states, “To be considered ‘strong cryptography,’ industry-recognized protocols with appropriate key strengths and key management should be in place as applicable for the type of technology in use.”

During the PCI Requirement 2.3 assessment, your assessor should observe administrators logging on to verify a couple of things. First, the system configurations should be examined to prove that a strong encryption method was invoked before the administrator’s password is requested. Observing an administrator log on to each system will also prove, “Administrator access to any web-based management interfaces is encrypted with strong cryptography.” In addition to observing administrators, the assessor needs to examine vendor documentation to ensure your vendors are also implementing strong cryptography according to industry standards.

We encourage your organization to be aware of how you are connecting to your assets and that you are only using secure protocols, ports, and services. Encryption can prevent a malicious user from accessing your organization’s network, becoming an administrator, and taking data.

PCI DSS Requirement 2.3

PCI DSS Requirement 2.3 calls out the need to encrypt all non-console administrative access. This doesn’t mean you have to encrypt all access; we’re only looking to see that you’re encrypting administrative-type access.

Now, I want to talk a little bit about administrative access and, from an assessment perspective, how we classify administrative. If you have the ability to impact or making changes to a system or a setting that would impact the security of the data that you’re trying to protect, or you have the ability to impact the security of a user or change a user’s experience, we put those types of actions in the administrative-type role.

From an assessment perspective, the assessor is likely to ask you for the results of an Nmap scan that’s been run against your environment. What this will define for us is what protocols, ports, and services you actually have open. We’re going to be looking at the installed and running services. One of the things we’re going to look for is: you might have VMC running, you might have telnet running, you might have a plethora of different protocols, ports, and services that are open and applications that are running in order to support these remote-access services.

You’re required to have these encrypted and they need to be encrypted with strong cryptography. As part of this, there might be situations where you as an organization might have a Legacy main frame server running some type of TN3270 but it only supports TLS 1.0. In situations like that, from an assessment perspective, we would have to look for other security features that you can implement or perhaps put a wrapper around these protocols to secure them. As to give an example, if you’re running a Microsoft server, there’s different negotiation levels that these servers will encrypt. Typically, the default setting is to negotiate. From a security and assessment perspective, we look to see the encryption settings for the RPI set to high. This forces strong encryption.

So, be aware of how you’re connecting to your assets, making sure that the protocols, ports, and services that you’re using are secure. The intent behind this is to prevent a malicious user that may be in your environment from sniffing this traffic and gaining the authentication credentials.

Removing All Unnecessary Functionality

PCI Requirement 2.2.5 states, “Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file system, and unnecessary web servers.” Unnecessary functions are yet another way that hackers could gain access to your system, so if a function is not needed, it needs to be shut off. The PCI DSS says that, “By removing all unnecessary functionality, organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited.” PCI Requirement 2.2.5 is not just focused on servers; it applies to protocols, ports, services, applications, databases, etc.

It is not the assessor’s job to define what is necessary or required for your business. That is the organization’s responsibility. It is the assessor’s job to verify that you are doing the things you say you’re doing to keep your system secure. When an assessor asks you to validate why you need a certain application or port, it’s not to challenge you. It’s to gain an understanding of the level of due diligence that your organization has gone to.

Like other PCI Requirement 2 sub-requirements, the way to test that your organization meets PCI Requirement 2.2.5 is to take a sample of system components and compare it to your configuration and hardening standards. An assessor will inspect the sample to see that all unnecessary functionality has been removed, that there is appropriate documentation that verifies enabled functions, and that only the documented functionality is present on the sample. For example, if an assessor finds unnecessary default services running, this would call into question whether or not you’ve actually hardened your assets.

The purpose of PCI Requirement 2.2.5 is to help protect your organization’s environment from becoming susceptible to malicious individuals. Like many other PCI Requirement 2 sub-requirements, PCI Requirement 2.2.5 hopes to protect your organization from providing opportunities for hackers to invade your environment. Just remember: if it is not needed, it needs to be removed. Once PCI Requirement 2.2.5 is met, your organization can focus on securing the functions that are required for your business.

PCI DSS Requirement 2.2.5

Moving along with the theme of removing things that are unnecessary, we come to the next requirement, PCI DSS Requirement 2.2.5. This requirement specifically states that we have to remove all unnecessary functionality. This would include protocols, ports, services, applications – really anything. Understand that this is not just focused on servers; this is your application layer, this is your database layer. It basically boils down to: if it’s not needed, it needs to be shut off. From an assessment perspective, it’s really not our job as assessors to define what’s required for your business. It’s not our job to state whether or not you truly need something or not.

When we’re asking those questions as assessors, like “Why do you need this?”, it’s not really to challenge you to say you don’t need it. It’s really to get an understanding of the level of due diligence that you’ve done around why this particular situation or why this particular configuration is required. For this assessment, what we’re doing is we’re going back and we’re looking at your configuration standards, looking at your hardening standards, and then we’re looking at what’s actually installed. Often times we find unnecessary default services running and once again, this calls into question whether or not you’ve hardened those assets.