This exclusive video series, PCI Demystified, was developed to assist your organization in understanding what the Payment Card Industry Data Security Standard (PCI DSS) is, who it applies to, what the specific requirements are, and what your organizations needs to do to become compliant. In this episode, Jeff Wilder walks us through PCI Requirement 1.
The Payment Card Industry Data Security Standard (PCI DSS) was jointly developed by the payment card brands to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. Its purpose is to ensure that all of that data that lives within the Cardholder Data Environment (CDE) is protected and secured from theft or unauthorized use. If you are a merchant, service provider, or sub-service provider who stores, processes, or transmits cardholder data, you are subject to comply with the PCI DSS. The current version, PCI DSS 3.2, has approximately 394 controls, 6 control objectives, and 12 major subject areas. The 12 requirements are:
Install and maintain a firewall configuration to protect cardholder data
Do not use vendor-supplied passwords and other security parameters
Protect stored cardholder data
Encrypt transmission of cardholder data across open, public networks
Protect all systems against malware and regularly update anti-virus software or programs
Develop and maintain secure systems and applications
Restrict access to cardholder data by business need-to-know
Identify and authenticate access to system components
Restrict physical access to cardholder data
Track and monitor all access to network resources and cardholder data
Regularly test security systems and processes
Maintain a policy that address information security for all personnel
PCI DSS Requirement 1
The PCI DSS Requirement 1, which states, “Install and maintain a firewall configuration to protect cardholder data.” PCI Requirement 1 addresses building and maintaining a secure network. This requirement requires your organization to maintain the authorized inbound and outbound traffic of your environment. Requirement 1 also focuses on managing the changes that happen in your environment and maintaining the documentation and program. It’s also about maintaining strict rules about what traffic is allowed in and out of that environment. It’s also about establishing a DMZ and limiting the traffic only to that which is necessary. We will explain the main topics of Requirement 1, like firewalls, network traffic, controls, documentation, and so much more.
Introduction to Requirement 1
So PCI DSS Requirement 1 is about maintaining a secure network. It’s about maintaining the authorized inbound and outbound traffic in and out of your environment. It’s about managing the changes that happen in that environment, maintaining the documentation, and maintaining the program. It’s also about maintaining strict rules about what traffic is allowed in and out of that environment. Lastly, it’s about establishing a DMZ and limiting the traffic only to that which is necessary
We find that most organizations struggle with the documentation aspect of a PCI assessment. Established best practice states, “If it’s not written down, it’s not happening.” Organizations need documented policies, procedures, and standards to control risks to business assets, but to also have a common understanding and language to create consistency among the culture of your organization. Small organizations often question why they need to document how their organization runs, especially if there are only a few people in the company. We think that’s the perfect example of why your organization, no matter the size, needs documentation; what if something happens? Who would know how to securely operate your organization? You need to have the proper policies, procedures, and standards in place to ensure the ongoing continuity and security of your organization.
In order to create and document proper polices, procedures, and standards, you need to understand the differences between them. A policy is an executive level document that defines that something must be done. For example, a policy outlines what employees must do or not do, directions, limits, principles, and guides for decision making – Policies are the law at your organization. A procedure is the counterpart to a policy; a policy defines that something must be done, but a procedure defines how you do it. A policy defines a rule, and the procedure says “This is who is expected to do it, and this is how they are expected to do it.”  Standards are the tools, means, and methods that you will use to meet policy requirements.
Creating procedures is where most organizations tend to struggle. 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. Your organization needs to have this documentation in place to define how to complete tasks securely to ensure the ongoing operation and security of your organization.
Policies, procedures, and standards should be written at a level so that someone with knowledge of the topic could read the policy or procedure and be able to carry out the task that is detailed.
Now, I’d like to talk about policies, procedures, and standards. We find, here at KirkpatrickPrice, that a lot of organizations really struggle with the documentation aspect of an assessment. So, we’re going to spend a little bit of time now talking about the difference between policies, procedures, and standards.
At the top of this pyramid, if you would, is a policy. A policy is an executive-level document that defines that something must be done. This is something that’s an edict, that’s a directive by your executive-level management that says “Thou shalt do these things.” The next step down is our standards. What are the tools, means, and methods that you’re going to be using in order to meet these policy requirements? Lastly as part of this, we have procedures. This is where most organizations tend to fail. Having a set of standard policies and procedures is often required. Where a policy defines that something must be done and a standard will define the tools, means, and methods for how we’re going to do it, a procedure defines how we’re going to do these things. A procedure should be very clear in providing step-by-step instructions on how something must be done or how something is to be done. For example, if somebody should go on vacation for a couple of weeks, we would expect them to hand off the policy, procedure, or standards documentation and someone else to be able to carry on that activity securely. These are the instructions on how to run your business.
If you’re a small organization, 2 or 3 people, we often hear the argument, “I’m the only one that does this, so why do I need to document what I do?” Well, I think that’s the perfect example as to why you need to document. What if you’re not around anymore? We need to make sure that we have the processes in place that define how to perform a task securely to ensure the ongoing continuity and security of your organization.
Please review your documentation, please review your audit standards and understand that each of these particular controls often needed and they’re distinctive in nature. As an organization, you can have one monolithic policy set; one policy that has all of the necessary statements. You can have one set of procedures that cover everything in your environment. You can have one document for each; we really don’t care. What we do care about is when a requirement says to demonstrate that you have a policy, we look for the policy. Where there’s a procedure required, we actively look for the step-by-step procedures.
Policies, procedures, and standards should be written at a level that you can hire somebody or give these documents to somebody with knowledge of the specific topic, and that individual could be able to carry that task on. We don’t expect you to be able to educate someone or take them from the ground level to expert level; someone who has knowledge of the topic should be able to read the policy or procedure and perform the task that’s detailed.
Properly scoping your environment is the most important initial step of becoming PCI compliant. The scope of the Cardholder Data Environment (CDE) determines the extent to which all PCI DSS controls must be in place. If an asset is in scope, all controls will apply. If an asset is not in scope, then there’s no concern to PCI. Errors in scoping can lead to serious consequences, so it’s important to define an accurate scope before beginning your PCI DSS audit. No matter what kind of data you’re protecting – ePHI, cardholder data, financial information – you need to understand where your assets reside and what controls are protecting them. If you don’t know where your data is, how do you plan to protect it?
So, how does your organization determine if an asset is in scope? Any people, process, or technology that stores, processes, or transmits cardholder data, is considered to be within your CDE and in scope for your PCI DSS audit. The rules defined by the PCI Security Standards Council also state that:
If your organization has any devices that provide security/authentication services, such as a firewall, router, or patching server, then those devices are considered in the CDE and part of your scope.
If your organization has an asset that has connectivity into the CDE, that asset is in scope.
If there are any routing rules that allow traffic into your CDE, that traffic brings those assets into scope.
If your organization has an asset that is deemed to have impact over the security of the CDE in any way, it’s also considered in scope.
There will be some gray areas and areas where your organization may struggle to determine whether a particular asset is in or outside of the scope of your PCI audit. But, there are typically 6 questions you can ask to determine whether something is in-scope. If the answer to any of these questions is yes, then that asset is in scope:
Does the asset store cardholder data?
Does the asset process cardholder data?
Does the asset transmit cardholder data?
Does the asset provide security services within the CDE?
Is the asset connected to the CDE?
Could the asset impact the security of the CDE?
Establishing Scope of Your Environment
One of the most important things your organization will do during your assessment process is to try to understand what’s in-scope. Whether it be HIPAA data, PCI data, any type of data, or financial information, you need to understand where your assets reside and what the controls are that you have in place to protect them.
As an assessor, part of the process is spending time with your organization and working with you to understand the scope of your environment. If your systems, your processes, or your people somehow have the ability to negatively impact the security aspect of this data we’re trying to protect, we look to make sure that you have appropriate controls in place. We try to, if you would, draw a circle around the assets that are in question and apply those controls to that. When we look at it from a security perspective, you must understand that if you don’t know where your data is at, how do you expect to protect it?
So, establishing the scope of your environment is one of going to be one of the most important things that you do in maintaining security. You need to ensure that you have the appropriate controls applied in the appropriate places.
This exclusive video series, PCI Demystified, was developed to assist your organization in understanding what Payment Card Industry Data Security Standard (PCI DSS) is, who it applies to, what the specific requirements are, and what your organization needs to do to become compliant.
The 12 PCI DSS Requirements
The PCI DSS was jointly developed by the payment card brands to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. Its purpose is to ensure that all of the data that lives within the Cardholder Data Environment (CDE) is protected and secured from theft or unauthorized use. If you are a merchant, service provider, or subservice provider who stores, processes, or transmits cardholder data, you are subject to comply with the PCI DSS.
The current version, PCI DSS 3.2, has approximately 394 controls, 6 control objectives, and 12 major subject areas. The 12 requirements are:
PCI Requirement 1
“Install and maintain a firewall configuration to protect cardholder data.” Your organization should focus on securing and hardening your network and securing the inbound and outbound traffic.
PCI Requirement 2
“Do not use vendor-supplied passwords and other security parameters.” Most organizations tend to focus on hardening their operating systems, but this requirement is intended for all assets within the environment.
PCI Requirement 3
“Protect stored cardholder data.” This requirement focuses on securing cardholder data at rest; this is the encryption and the storage of sensitive information.
PCI Requirement 4
“Encrypt transmission of cardholder data across open, public networks.” If you transmit cardholder data over open or public networks, that data must be securely and appropriately protected.
PCI Requirement 5
“Protect all systems against malware and regularly update anti-virus software or programs.” Do not focus on only anti-malware or only anti-virus; this requirement deals with both.
PCI Requirement 6
“Develop and maintain secure systems and applications.” There’s more to this requirement than just securing applications. It’s about identifying vulnerabilities, patching your systems, change management, change controls, and secure software development.
PCI Requirement 7
“Restrict access to cardholder data by business need-to-know.” Requirement 7 goes hand-in-hand with Requirement 8; it focuses on authorization.
PCI Requirement 8
“Identify and authenticate access to system components.” Requirement 8 focuses on authentication.
PCI Requirement 9
“Restrict physical access to cardholder data.” If a hacker as physical access to your assets, they pretty much own that data.
PCI Requirement 10
“Track and monitor all access to network resources and cardholder data.” This requirement is all about logging.
PCI Requirement 11
“Regularly test security systems and processes.” Your organization must ensure that you’re testing for vulnerabilities and managing the security of your environment so that your assets are protected.
PCI Requirement 12
“Maintain a policy that address information security for all personnel.” This is the requirement that addresses the policy and procedure management and vendor management of your organization.
The PCI DSS is comprised of 12 requirements and 2 appendices that we need to have a discussion about. We start out with Requirement 1, which is focused on securing and hardening the network and the inbound and outbound traffic. Requirement 2 is primarily focused with looking to harden the systems and the applications; most organization really just tend to focus on hardening their operating systems, but Requirement 2 is really intended for all assets within the environment. Requirement 3 is focused on securing cardholder data at rest. This is the encryption and the prohibition of storage of sensitive information. Requirement 4 is focused on making sure that when you transmit cardholder data over open or public networks, that the data itself is appropriately protected. Requirement 5 deals with antimalware and deals with antivirus.
Requirement 6 has actually got quite a bit that it deals with. This requirement, when we talk about the PCI DSS, talks about securing applications, but there’s a little bit more than that. It’s identifying vulnerabilities, it’s patching your system, it’s change management, it’s change controls, it’s secure software development and all the requirements that go along with making sure the applications are maintained securely. Requirement 7 and Requirement 8 kind-of go hand-in-hand; Requirement 7 is authorization and Requirement 8 is authentication. We change things up a little bit when we get to Requirement 9. Requirement 9 is focused on the physical security of the environment. If I’m a hacker and I have physical access to your assets, I can pretty much own the data on it. We get to Requirement 10, which is all of your logging. When we get to Requirement 11, it’s focused on making sure that all of things that you’ve put in place to secure your assets are functioning appropriately. This is where we’re testing for vulnerabilities and making sure we’re managing the security of the environment. Requirement 12 is the policy and procedure management and vendor management of the organization. This is really the management aspect of the PCI DSS itself.
Most organizations, most people tend to focus on the 12 requirements themselves, however there are 2 additional appendices that might as well be requirements. The first one we have is for shared hosted services providers. If you have a question of whether you’re a shared hosted service provider, please look at Requirement 2.6 in the PCI DSS. That will clearly explain what a shared hosted service provider is and talk about what the requirements are there. Lastly, we have the last appendix which we need to be concerned with or have conversations about. This is the Designated Entities Appendix. Once again, we’ll talk about what that is when we get to that requirement.
This exclusive video series, PCI Demystified, was developed to assist your organization in understanding what the Payment Card Industry Data Security Standard (PCI DSS) is, who it applies to, what the specific requirements are, and what your organizations needs to know and do to become compliant.
Why was PCI DSS developed?
The PCI Security Standards Council is a third-party organization that was developed for the sole purpose of managing the security of cardholder data. Prior to the PCI Security Standards Council, each payment card brand managed their own security standards.
Eventually, the payment card brands realized that it was counterproductive to have five different sets of standards that their clients had to audit against, thus, the PCI Security Standards Council and the PCI Data Security Standards were created. The PCI DSS was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The founding payment brands for the PCI Security Standards Council include Visa, Inc., MasterCard, Discover Financial, American Express, or JCB International.
Who are the participants in the PCI environment?
If you store, process, or transmit cardholder data, interact with payment card data in any way, or have the ability to impact someone else’s cardholder information or the security of that information, you are subject to comply with the PCI DSS. The PCI Security Standards Council and payment card brands are major participants in the PCI environment and are responsible for tracking and enforcing PCI DSS compliance, penalties, fees, compliance deadlines, and the monitoring and facilitating of investigations. The other entities that are impacted by the PCI DSS compliance lifecycle are acquiring banks, issuing banks, merchants, service providers, and sub-service providers.
An acquiring bank is a bank or financial institution that processes card payments on behalf of a merchant. Acquirers are subject to payment brand rules and procedures regarding ensuring merchant compliance on behalf of the PCI Security Standards Council.
Issuing banks are the financial institutions that issue the payment cards on behalf of the payment card brands and who act as the middle man between the cardholder and the payment brand network.
Merchants accept the credit cards for payment and may store, process, or transmit cardholder data.
A service provider is any entity that stores, processes, or transmits cardholder data on behalf of a third-party (merchant), or otherwise have the ability to impact cardholder data security.
A sub-service provider is any entity that is acting on behalf of a merchant or service provider who has active access to their cardholder data environment.
Introduction to PCI DSS
Hi, my name is Jeff Wilder and I am the Director of PCI Services here at KirkpatrickPrice. We wanted to develop a series of videos to talk about what the PCI DSS Security Standards are, who they apply to, and then later on, talk about the specific requirements about what you actually need to do to in order to become compliant.
We want to start off the series by talking a little bit about the players within the industry. The PCI Security Standards Council is a third-party independent organization that was established about 10 years ago for the sole purpose of managing the standards themselves. Prior to the PCI Security Standards Council, each card brand managed their own standards. They realized that it wasn’t in their best interest to have five different standards and have clients having to audit against so many different standards. So, they established the Council as the sole means of managing a set of security standards that need to be applied if you interact with a Visa, MasterCard, American Express, or JCB. So in this lifecycle, we have the PCI Security Standards Council, we have the card brands themselves, and we also have what we call acquiring banks. Now these acquiring banks – if you are a merchant having merchant relationship with a bank, if you accept a credit card for payment, you have a relationship with an acquiring bank. These acquiring banks are the entities that, really, are responsible for your compliance. They are responsible for you on behalf of the Council to ensure that you are compliant on a day-to-day basis. Next in the ecosystem, we have what we call issuing banks. Now, the issuing banks have a relationship with the individuals that have credit cards. They’re the ones that actually issue the cards. Of course we have the merchants – these are the organizations that accept the credit cards for payment. Then we have service providers. Now, service providers are any entity that would store, process, or transmit cardholder data on behalf of a third-party, or otherwise have the ability to impact the security of it. If you interact with payment card data in any way, if you store, process, or transmit it, or if you have the ability to impact someone else’s cardholder information or the security of that information, you are subject to the PCI DSS standards.
In this series of videos, we’re going to be going over the requirements and talking about, not so much just what does the PCI DSS Security Standards say and the individual requirements, but what it really means. How is that going to apply into your environment? What I’m going to try to do is provide you with some guidance based off my 10 years of experience in the industry as former Council member helping to develop these standards and training for the last 2.5-3 years, prior to becoming the Director here at KirkpatrickPrice. I’m going to bring to the table all of that knowledge and information for you to use at your discretion. So, hope you enjoy the videos. Thank you.
