PCI Requirement 3.1 requires organizations to securely delete data that is not required to be retained for business or legal requirements. Why is complying with PCI Requirement 3.1 important? So that cardholder data cannot be recreated by malicious individuals.

PCI Requirement 3.1 states that organizations should, “Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures, and processes…” PCI Requirement 3.1 aligns with the methodology of many other PCI requirements: If you don’t need it, get rid of it. It is acceptable to retain data that’s required by contract, for business reasons, or for legal reasons. However, if you’re retaining cardholder data that is not required, it becomes a liability for your organization. The PCI DSS states, “In order to define appropriate retention requirements, an entity first needs to understand their own business needs as well as any legal or regulatory obligations that apply to their industry, and/or that apply to the type of data being retained.”

During a PCI assessment, assessors need to examine your data retention and disposal policies, which should outline what data needs to be retained, where that data resides, why you’re keeping it, and the length of time that you’re keeping it. Then, assessors will survey the data you have within your custody. Taking inventory is an important part of the assessment process; whether it’s physical print media or electronic, assessors need to see where the data is located. Then, after taking a sample of the data, assessors will compare the life of that data against your organization’s data retention and disposal policies.

PCI DSS Data Retention Requirements

When the PCI DSS describes data retention requirements, it stipulates that cardholder data storage should be kept to a minimum. If you don’t need it, get rid of it. Unless cardholder data needs to be retained for business or legal reasons, it needs to be securely deleted. When it gets past this point, it becomes a liability to your business.

Your organization’s data retention and disposal policies, procedures, and standards should document how you securely delete information. Assessors expect that if data has been securely deleted, it can never be recreated. Print media should be shredded and electronic data should be overwritten on a hard drive. The process of securely deleting information should be done either manually or by an automatic process and should be done at least quarterly.

“Continuing on with the mantra of, “If you don’t need it, you should get rid of it,” we have to look at the assets or the information that you have within your custody. If you’re storing credit card data, storing medical data, or storing client data because it’s required by contract, for business reasons, for legal reasons – whatever the reason is, it’s alright, there’s nothing wrong with that – however, if you’re maintaining this information and it’s not required that you do so, it becomes a liability to your organization. PCI Requirement 3.1 states that if you don’t need the data, you need to get rid of it. There’s a couple of requirements around what that looks like. You either have to have a manual process where you’re manually going through and looking at your physical inventory. You might have printed media, perhaps, residing in an offsite storage facility. You might have electronic data residing in a database or in flat files somewhere. When we start with the assessment of Requirement 3.1, we’re going to ask for your Data Retention and Disposal Policies. These Data Retention Policies should state the type of data that you’re keeping, why you’re keeping it, and the length of time that you’re keeping this data. The assessor will perform an inventory of where this data is located. Whether it be electronic or whether it be physical print media, we’re going to be performing an inventory of where that media is at. We’re going to be sampling that data, then comparing the life of that data against your Retention Policies and Procedures. Once again, if you need the data, there’s no problem with keeping it. However, if you don’t need it, it should be disposed of. We’re then going to look at your Data Disposal Policies, Procedures, Standards, and documentation and look at how you’re securely removing that information. This process of removing that information should be done at least quarterly. It needs to be either a manual or automatic process, but the process needs to be run quarterly. We’re going to look to see that you securely delete that data, understanding that “delete” is different than the “secure delete” function. When the term “secure delete” is used, we’re looking to ensure that the data can never ever be recreated or re-rendered. If it’s print media, we’re looking to see that it’s been turned into confetti. If it’s electronic media, we’re looking to see that the data has been overwritten on a hard drive. Requirement 3.1 requires that if you do not need the data to support your business or your legal requirements, that data needs to be removed. “

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.