A Guide to Implementing the Payment Card Industry Data Security Standard (PCI DSS)
V3 Copyright CertiKit
A Guide to Implementing PCI DSS Contents 1
INTRODUCTION ....................................................................................................................................... 2 1.1 1.2 1.3 1.4 1.5
2
WHAT IS CARDHOLDER DATA (CHD)? ..................................................................................................... 2 WHAT IS SENSITIVE AUTHENTICATION DATA (SAD)? .............................................................................. 2 WHAT IS THE CARDHOLDER DATA ENVIRONMENT (CDE)? ...................................................................... 3 WHAT ROLE DOES YOUR ORGANIZATION PLAY IN PAYMENT CARD PROCESSING?...................................... 3 MERCHANT AND SERVICE PROVIDER LEVELS ........................................................................................... 3
THE TWELVE REQUIREMENTS OF PCI DSS ................................................................................... 5 2.1
REQUIREMENT 1: INSTALL AND MAINTAIN A FIREWALL CONFIGURATION TO PROTECT CARDHOLDER
DATA 5
2.2
REQUIREMENT 2: DO NOT USE VENDOR-SUPPLIED DEFAULTS FOR SYSTEM PASSWORDS AND OTHER SECURITY PARAMETERS ...................................................................................................................................... 6 2.3 REQUIREMENT 3: PROTECT STORED CARDHOLDER DATA .......................................................................... 7 2.4 REQUIREMENT 4: ENCRYPT TRANSMISSION OF CARDHOLDER DATA ACROSS OPEN, PUBLIC NETWORKS .... 7 2.5 REQUIREMENT 5: PROTECT ALL SYSTEMS AGAINST MALWARE AND REGULARLY UPDATE ANTI-VIRUS SOFTWARE OR PROGRAMS ................................................................................................................................... 8 2.6 REQUIREMENT 6: DEVELOP AND MAINTAIN SECURE SYSTEMS AND APPLICATIONS ................................... 9 2.7 REQUIREMENT 7: RESTRICT ACCESS TO CARDHOLDER DATA BY BUSINESS NEED TO KNOW .................... 10 2.8 REQUIREMENT 8: IDENTIFY AND AUTHENTICATE ACCESS TO SYSTEM COMPONENTS............................... 10 2.9 REQUIREMENT 9: RESTRICT PHYSICAL ACCESS TO CARDHOLDER DATA .................................................. 11 2.10 REQUIREMENT 10: TRACK AND MONITOR ALL ACCESS TO NETWORK RESOURCES AND CARDHOLDER DATA 12 2.11 REQUIREMENT 11: REGULARLY TEST SECURITY SYSTEMS AND PROCESSES........................................ 13 2.12 REQUIREMENT 12: MAINTAIN A POLICY THAT ADDRESSES INFORMATION SECURITY FOR ALL PERSONNEL ....................................................................................................................................................... 14 2.13 APPENDIX A: ADDITIONAL PCI DSS REQUIREMENTS ........................................................................ 15 3
WHERE TO START ................................................................................................................................ 17 3.1 KNOWING YOUR NETWORK ..................................................................................................................... 17 3.1.1 Cardholder Data Flow.................................................................................................................. 17 3.1.2 Identifying the Cardholder Data Environment (CDE) .................................................................. 17 3.1.3 Network Segmentation .................................................................................................................. 18 3.2 THE PRIORITIZED APPROACH .................................................................................................................. 18
4
SUBMITTING COMPLIANCE .............................................................................................................. 19 4.1 4.2 4.3
5
QUALIFIED SECURITY ASSESSOR ............................................................................................................ 19 REPORT ON COMPLIANCE (ROC)............................................................................................................. 19 SELF-ASSESSMENT QUESTIONNAIRE (SAQ) ........................................................................................... 19
CONCLUSION.......................................................................................................................................... 20
V3 Copyright CertiKit
Page 1
A Guide to Implementing PCI DSS
1 Introduction The Payment Card Industry Data Security Standard (PCI DSS) was created by the Payment Card Industry Security Standards Council (PCI SSC) which is governed by the following Payment Brands: • • • • •
MasterCard VISA American Express JCB Discover Financial Services
PCI DSS was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. Any organization involved in payment card processing which includes the storing, processing or transmitting of cardholder data (CHD) is usually contractually required to be PCI DSS compliant. Failure to do so could result in penalty fines to the organization. This guide takes you through the process of implementing the Payment Card Industry Data Security Standard. It adopts the same route to compliance provided by the PCI SSC called the “Prioritized Approach”. This approach is designed to assist organizations on where to start and to reduce risk early on their journey to compliance. It is important to note that PCI DSS compliance should not just be treated as a project, with a beginning and an end; rather the goal should be to implement the 12 requirements of PCI DSS into the organization’s ‘business as usual’ processes and procedures when handling cardholder data.
1.1
What is Cardholder Data (CHD)?
Cardholder data is the following information on credit/debit cards: • • • •
1.2
Primary Account Number (PAN) – The long 16-digit number across the card Cardholder Name – The name of the person(s) associated with the card Expiration Date – The date the card expires Service Code – A code indicating what country or countries the card can be used in
What is Sensitive Authentication Data (SAD)?
Sensitive Authentication Data is the following information on credit/debit cards: • • •
Full Track Data – Magnetic strip on the back of the card or the chip on the front of the card CAV2/CVC2/CVV2/CID – The three or four-digit value, typically on the back of the card next to the signature section PIN/PIN BLOCK - Personal identification number entered by cardholder during a cardpresent transaction, and/or encrypted PIN block present within the transaction message
V3 Copyright CertiKit
Page 2
A Guide to Implementing PCI DSS Note: This data must never be stored, even if encrypted.
1.3
What is the Cardholder Data Environment (CDE)?
The Cardholder Data Environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. System components include network devices, servers, computing devices, and applications. Examples of people and system components within a CDE may include but are not limited to: • • •
1.4
A cashier attendant using a till/cashier in a shop An ecommerce website on the Internet. The web server hosting this website would be a system component A PIN Entry Device (PED, also known as a Chip and Pin Device) in a supermarket
What role does your organization play in payment card processing?
PCI DSS applies roles to each entity involved in payment card processing. It is very important you understand what role your organization plays and those of other entities you use. Such entities include: • •
•
•
•
1.5
Merchant – an entity that accepts payment cards bearing the logos of any of the Payment Brands as payment for goods and/or services Processor – an entity engaged by a merchant or other entity to handle payment card transactions on their behalf. While payment processors typically provide acquiring services, payment processors are not considered acquirers unless defined as such by a payment card brand Acquirer – an entity, typically a financial institution (e.g. bank) that processes payment card transactions for merchants and is defined by a payment brand as an acquirer. Also referred to as “merchant bank”, “acquiring bank”, or “acquiring financial institution” Issuer – an entity that issues payment cards or performs, facilitates, or supports issuing services including, but not limited to, issuing banks and issuing processors. Also referred to as “issuing bank” or “issuing financial institution” Service Provider – a business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services, as well as hosting providers
Merchant and Service Provider Levels
All Merchants and Service Providers are categorized into different levels depending on the volume of card payment transactions the organization processes per year. There are four levels into which an organization can be categorized, with level 1 being the highest and level 4 being the lowest.
V3 Copyright CertiKit
Page 3
A Guide to Implementing PCI DSS
However, the volume of transactions per year that determines the categorization level of your organization also varies between the Payment Brands (Visa, MasterCard, American Express, Discover, and JCB). Therefore, it is highly recommended you confirm your organization’s transaction volume and categorization level with your acquiring bank. Once you have determined your level you will know what validation methods are required for PCI DSS compliance.
V3 Copyright CertiKit
Page 4
A Guide to Implementing PCI DSS
2 The Twelve Requirements of PCI DSS PCI DSS provides a baseline of technical and operational requirements designed to protect cardholder data. These requirements are broken down into 12 areas and we will consider each one in turn.
2.1
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Relevant Toolkit Documents • • • • • •
Network Security Policy Configuration Standard Template Network Diagram Example Cardholder Data Flow Diagram Example Mobile Device Policy Configuration Review Form
Firewalls are fundamental devices to ensure traffic flow between networks is controlled. Traditionally firewalls were used to protect a perimeter network but its more common now to have segmented internal networks with firewalls controlling the traffic between them. PCI DSS recommends that you segment your CDE network to ensure cardholder data is protected. This requirement ensures there is a ‘best practice approach’ to firewall security with well documented policies, procedures and configuration standards in place. This requirement talks about ensuring a Firewall and/or Router are established and implemented within your organization with appropriate configuration standards in place. The main reason behind this is to provide a documented list of build configuration, services installed and firewall rules. This way you have a document to justify why a firewall or router is built that way and can be used to review against the firewall or router for integrity. Formal processes must also be in place for effective change management. Well thought-out firewall configurations are also part of this requirement to protect the cardholder data. Configurations include those to restrict connections from untrusted networks to the network where cardholder data is present, to restrict all traffic that is not necessary for the cardholder data environment, to implement anti spoofing measures and to implement a DMZ (DeMilitarized Zone). Installing personal firewall software (or equivalent functionality) is also applicable to this requirement when using portable computing devices in and outside the Cardholder Data Environment. This provides additional protection to the cardholder data when the portable device is outside of the CDE and is not protected by a corporate firewall or router. This personal firewall must be active at all times and must not be alterable by users of the portable computer.
V3 Copyright CertiKit
Page 5
A Guide to Implementing PCI DSS
Finally, it is required that all security policies and procedures for managing firewalls and routers are documented, in use and known to all affected parties.
2.2
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Relevant Toolkit Documents • • • •
Password Policy Configuration Standard Template Cardholder Data Environment Asset Inventory Database Operational Procedure Template
Even in today’s world the use of vendor-supplied default passwords is widespread. Malicious individuals will exploit this fact which could lead to the compromise of your cardholder data. This requirement ensures organizations disable or change system default passwords on all system components within the CDE. Like requirement 1, this requirement also refers to configuration standards for all system components that are within the Cardholder Data Environment. Within each configuration standard it must state that system components address all known vulnerabilities and are consistent with industry-accepted system hardening standards, such as: • • • •
Center for Internet Security (CIS) International Organization for Standardization (ISO) SysAdmin Audit Network Security (SANS) Institute National Institute of Standards Technology (NIST)
Further security and technical controls are needed within this section to ensure the system only provides functionality to serve its purpose and nothing else. Controls include the implementation of encryption on all non-console administrative access using strong cryptography (TLS 1.2) and ensuring only those services and daemons are enabled, that are necessary to allow the correct functioning of the system. This section also covers the need to maintain an inventory of system components within scope of PCI DSS. This is important as it ensures system administrators review all system components against configuration standards and keep the integrity of the system intact. Finally, it is required that all security policies and procedures for vendor defaults and other security parameters are documented, in use and known to all affected parties.
V3 Copyright CertiKit
Page 6
A Guide to Implementing PCI DSS 2.3
Requirement 3: Protect stored cardholder data
Relevant Toolkit Documents • •
Data Retention and Protection Policy Cryptographic Policy
Protection of cardholder data by methods such as encryption, masking etc. is critical. If a malicious individual were to circumvent other security controls within your organization, then without the correct decryption keys the data would be unreadable. This requirement sets out a baseline of cryptographic processes, policies, procedures and technology to use. This section talks about keeping card holder data storage to a minimum i.e. if the organization does not need to store the cardholder data for legal, regulatory and/or business requirements then the data must be safely disposed of. Implementing data retention and disposal policies ensures the card holder data is managed, by specifically setting out retention dates and processes for secure deletion/disposal of the data when it is no longer required. Also, the policy should set out exactly what elements of the cardholder data should be retained. For example, an organization may need to retain the cardholder’s name, Primary Account Number (PAN), expiration date and service code. When there is a requirement to store cardholder data it must be kept in a secure manner using strong encryption and hashing technologies. A cryptographic policy must be implemented to highlight what encryption is being used and where. This ensures the organization can manage the encryption efficiently. Key management processes and procedures must also be implemented to ensure encryption keys are stored in a secure way with only authorized people allowed to access the keys. This ensures that keys are restricted to the fewest number of custodians necessary. Keyencrypting technologies must also be used to encrypt keys securely so no unauthorized people can access them. Finally, it is required that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.
2.4
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Relevant Toolkit Documents • • •
Personal Commitment Statement Cryptographic Policy Data Retention and Protection Policy
V3 Copyright CertiKit
Page 7
A Guide to Implementing PCI DSS Working in public areas is becoming more and more common. Therefore, it is important that cardholder data is encrypted during transmission over public networks. Without doing so a malicious individual could intercept this traffic and gain access to the data. Also, some organizations’ wireless networks may be misconfigured or have legacy equipment that potentially has vulnerabilities that are prone to attack. This requirement ensures cardholder data is secured in transmission. To do this, strong cryptography and security protocols must always be used across open/public networks. A cryptographic policy is implemented here to state what encryption technology is being used, how it is secured and how it is managed. It is also important to note that some protocols (such as SSL, SSH v1.0 and early TLS) have known vulnerabilities and therefore should not be used. Finally, it is required that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.
2.5
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Relevant Toolkit Documents •
Anti-Malware Policy
Malware is an ever-evolving threat targeting computers, software and storage devices, to name but a few. Having anti-virus software installed on all systems to reduce this threat, whilst allowing approved business activities to continue, is important in any organization. This requirement sets out a baseline of processes, policies and procedures to ensure cardholder data remains secure and reduces the threat of attack. Deploying anti-virus software is a must for this requirement. However, it is also equally important to ensure the anti-virus software is fit for purpose, regularly reviewed and maintained, and not tampered with. To do this an anti-malware policy must be implemented, which specifies in detail how the organization manages and maintains the anti-virus software so that: • • •
the anti-virus software is actively running and kept up to date periodic scans are complete audit logs are retained
Finally, it is required that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties.
V3 Copyright CertiKit
Page 8
A Guide to Implementing PCI DSS 2.6
Requirement 6: Develop and maintain secure systems and applications
Relevant Toolkit Documents • • • • •
Technical Vulnerability Management Policy Software Policy Change Management Process Change Request Form Technical Request for Change Form
Malicious individuals may use security vulnerabilities to gain access to an organization’s systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which is why it’s important to have a process in place to ensure all system patching is completed in a timely manner. This requirement ensures software patching is documented and completed on a regular basis. A technical vulnerability management policy is required which states how the organization intends to manage vulnerabilities, including: • • • •
Identifying the systems that need to be managed applying a risk ranking to vulnerabilities (for example, as high, medium or low) stating the frequency of application of patches to the systems ensuring that critical updates are applied within one month of release
Organizations that create and develop their own software must ensure that the software is written in accordance with industry standards and/or best practices. A software policy may be used to define how the organization achieves this. Within the policy it will state that all development is compliant with PCI DSS and considers information security in general throughout the softwaredevelopment life cycle. Custom code should also be reviewed prior to release to production to ensure the software is created using secure coding techniques. Strict change control processes must be in place and documented to ensure safe and secure transition of software from test to live production. The change control process must include impact, testing, back out plans and approval of the change. Also, the change must highlight checks to the security of the system to ensure it remains secure and in line with PCI DSS requirements. Upon completion of the change all PCI DSS required documentation must be updated where appropriate. Finally, it is required that all security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.
V3 Copyright CertiKit
Page 9
A Guide to Implementing PCI DSS 2.7
Requirement 7: Restrict access to cardholder data by business need to know
Relevant Toolkit Documents • • •
Access Control Policy User Access Management Process Change Request Form
Staff members need only to have access to those systems and information assets necessary to perform their job responsibilities. Enforcing this rule ensures that staff cannot accidentally or maliciously compromise cardholder data. The principle of “need to know” dictates that only those access rights needed to perform a job role, are granted. This requirement ensures effective authorization is actively being used within the organization. An access control policy will need to be implemented which defines access needs for each role within the organization, and for system components along with access level e.g. user or administrator access. Each role access will need to be justified in order to limit access to system components and cardholder data to only those individuals whose job requires it. Documented approval of access to system components must be given by authorized parties, which specifies the required privileges and why the individual needs them. Finally, it is required that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.
2.8
Requirement 8: Identify and authenticate access to system components
Relevant Toolkit Documents • • • • •
Password Policy Remote Working Policy Cryptography Policy Security Awareness Training Presentation Slides Information Security Communication Programme
Assigning a unique identification (ID) to each person allows an organization to control, monitor and trace access to systems and ensure that everyone is accountable for their actions. This requirement sets out a baseline of processes, policies and procedures to ensure access to cardholder data is controlled.
V3 Copyright CertiKit
Page 10
A Guide to Implementing PCI DSS Working in conjunction with the access control policy, a password policy is required within this section. The password policy includes password complexity requirements such as: • •
A minimum length of at least seven characters. Contains both numeric and alphabetic characters.
Also, passwords must be changed at least once every 90 days and be different from the last four used. When actioning a password reset the administrator must set the password to expire so that the user is forced to change their password upon first logon to the system component. This ensures that only the owner of the user account knows the password. Multi-factor authentication must also be used when accessing the network remotely and when accessing the cardholder data environment (CDE) on the internal network and remotely. Communication and guidance on the password policy is an important and fundamental part of this requirement. Individuals must know the importance of keeping their passwords secure and must be given guidance on selecting strong authentication credentials. A security awareness training presentation is included in the Toolkit to help with this element of the requirement. Finally, it is required that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.
2.9
Requirement 9: Restrict physical access to cardholder data
Relevant Toolkit Documents • • • • •
Physical Security Policy Procedure for Taking Assets Offsite Cardholder Data Environment Access Procedure Visitor Log Cardholder Data Environment Asset Inventory Database
Physical access considerations within a CDE are equally as important as electronic access, as it’s often the case that individuals write cardholder information down or print hard copies when they shouldn’t. This requirement ensures all appropriate controls are in place to physically secure the CDE. A physical security policy must be implemented here to set out how the organization approaches the physical security of the cardholder data environment. Within the policy it must include what entry controls the organization has to restrict access to the CDE and/or what surveillance mechanisms are in place e.g. video cameras. Physical and/or logical controls must be in place to protect the following components:
V3 Copyright CertiKit
Page 11
A Guide to Implementing PCI DSS
• • • • •
Network jacks in public locations Wireless access points Gateways Handheld devices Networking or communication lines
Asset management is also a key part of this requirement. Recording information such as make, model and serial number etc. is important to correctly identify assets. Procedures will also need to be implemented for the protection of assets going offsite, in order to keep the cardholder data environment secure. Periodic inspection of assets is also required to help the organization detect tampering which could compromise cardholder data. Training on how to inspect assets will need to be provided to the appropriate individuals. Finally, it is required that security policies and operational procedures for restricting physical access to cardholder data are documented, in use, and known to all affected parties.
2.10 Requirement 10: Track and monitor all access to network resources and cardholder data Relevant Toolkit Documents • • •
Network Security Policy Monitoring the Use of IT Systems Procedure Security Incident Response Procedure
Logging and the ability to track user activities are critical in preventing, detecting or minimizing the impact of a data compromise. This requirement sets out objectives to ensure all appropriate systems are actively logging relevant events and being reviewed on a regular basis. A procedure for the monitoring of IT systems must be in place which explains what is monitored, when and how, including: • • • • • •
Unauthorised access attempts Unusual use of privileged accounts e.g. administrator Attachment of unauthorised removable media devices Unusual patterns of activity e.g. late at night Changes to system settings Suspicious network traffic activity
Audit logging is required to detect and report on the following types of events:
V3 Copyright CertiKit
Page 12
A Guide to Implementing PCI DSS
• • • • • • •
User identification Dates and times of key events e.g. log on/log off Success and failure in systems access attempts Success and failure in data and other resource access attempts (i.e. cardholder data) Changes to system parameters and configurations Use of system utilities and applications Actions taken by users with administrative privileges
A time synchronization mechanism needs to be in place to ensure all systems are synced with an industry-accepted time source. This means that, when reviewing logs, the correct time and date of an event is shown, regardless of the device involved. Finally, it is required that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties.
2.11 Requirement 11: Regularly test security systems and processes Relevant Toolkit Documents • • • • • • • •
Technical Vulnerability Management Policy Network Security Policy Cardholder Data Environment Asset Inventory Database Security Incident Response Procedure Risk Assessment and Mitigation Process Risk Mitigation Plan Change Control Process Procedure for Monitoring the Use of IT Systems
One of the best ways to ensure the organization’s security controls are sufficient is to perform regular vulnerability testing. This requirement ensures that testing is completed frequently, and against industry-known best practices. Testing is broken down into several areas below and PCI DSS requires each test to be completed at certain times annually. Areas to be tested include: • • •
Internal and external vulnerability scans – to be completed at least quarterly by an approved scanning vendor (a list of these can be found on the PCI DSS website) External penetration scan at least annually or after any significant change that could affect the cardholder data environment Tests for the presence of unauthorized wireless access points should be completed at least quarterly
V3 Copyright CertiKit
Page 13
A Guide to Implementing PCI DSS
All testing should be completed based on industry accepted approaches. Any vulnerabilities found during testing should be recorded, risk rated and mitigated in a controlled manner. This process should be documented within a risk assessment and mitigation plan. Prevention and detection technologies should also be implemented to further improve security. These technologies and the above testing should be described within a technical vulnerability management policy and a network security policy. Finally, it is required that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties.
2.12 Requirement 12: Maintain a policy that addresses information security for all personnel Relevant Toolkit Documents • • • • • • • • • • • • • • • •
Information Security Roles Responsibilities and Authorities Information Security Communication Program Security Incident Response Procedure Service Provider and Contracts Database Employee Screening Checklist Information Security Policy for Service Provider Relationships Service Provider Due Diligence Assessment Service Provider Due Diligence Assessment Procedure Personal Commitment Statement Risk Assessment and Mitigation Process Risk Mitigation Plan Internet Acceptable Use Policy Mobile Device Policy Electronic Messaging Policy Remote Working Policy Security Awareness Training Presentation Slides
A strong security policy underpins the organization’s stance on security and informs all employees about what is expected of them. This requirement covers lots of areas that are similar to an information security management system (ISMS). It covers: • • • •
Information security roles and responsibilities Information security communication and training to all staff members New/Existing service provider due diligence processes Acceptable use policies
V3 Copyright CertiKit
Page 14
A Guide to Implementing PCI DSS • •
Employee screening Incident response process
All of the above items contribute positively to the confidentiality and integrity of cardholder data.
2.13 Appendix A: Additional PCI DSS Requirements Relevant Toolkit Documents • • • • • • • • • • •
Network Security Policy Network Diagram Example Cardholder Data Flow Diagram Example Information Security Roles Responsibilities and Authorities Risk Assessment and Mitigation Process Risk Mitigation Plan Business Impact Analysis (BIA) Process Business Impact Analysis (BIA) Tool PCI DSS Impact Assessment Problem Management Process PCI DSS Compliance Review Form
Dependent on the different types of entity your organization is defined as, additional requirements may need to be fulfilled. This appendix is broken down into three main areas: Shared Hosting Providers As referenced in requirements 2 and 12 of the standard, all service providers, including shared hosting providers, must adhere to PCI DSS. In addition, hosting providers must protect each entity’s hosted environment. Entities using SSL/early TLS After June 30th 2018, all organizations using SSL or early TLS as a security control on entities within the Cardholder Data Environment (CDE) must stop using them, and later versions of TLS must be implemented (e.g. TLS 1.2). If your organization is currently PCI DSS compliant and is still using SSL or early TLS, A risk assessment and mitigation plan with timescales must be defined. This will ensure the organization is taking appropriate action to remain complaint after June 30th 2018. Designated Entities Supplemental Validation This section applies to organizations designated by a payment brand or acquiring bank as requiring additional validation of existing PCI DSS requirements. Examples of where these would apply could include: • •
Organizations storing, processing or transmitting large volumes of cardholder data Organizations that have suffered significant or repeated breaches of cardholder data
V3 Copyright CertiKit
Page 15
A Guide to Implementing PCI DSS
If the organization falls under this section, additional items are required such as a PCI compliance program owned by an accountable role within the organization. Validation of the PCI DSS scope, and assurance that the requirements are being met in business-as-usual (BAU) activities, are also needed as part of this section.
V3 Copyright CertiKit
Page 16
A Guide to Implementing PCI DSS
3 Where to start The first, and probably most important, step towards implementing the PCI DSS standard is to understand exactly where the organization stores, processes or transmits cardholder data. The objective of this is to: • • • •
3.1
Know your network Identify cardholder and sensitive authentication data Form your cardholder data environment (CDE) Securely segment your CDE away from the rest of the organization
Knowing your network
Understanding your network sounds an obvious and easy step to complete but many organizations find that when an incident occurs, it makes them question how well they actually know their network. There are lots of ways to ‘deep dive’ into the network and one way doesn’t necessarily fit every organization. However, below is a suggested way to start: • •
•
3.1.1
Network Diagram – Starting with a diagram of your network helps visualise the infrastructure and focus on the key areas to investigate Data Discovery – Implement a data discovery methodology to identify where cardholder data is stored, processed and transmitted. Checking every bit of data is an almost impossible task without data discovery software to assist, but without checking you will never be sure where and how the cardholder data flows through your organization Interview – Interview and shadow key business areas relevant to PCI DSS to get an understanding of how card payment processing is being completed Cardholder Data Flow
Once you understand your network and the system components within it you can start to map out the flow of cardholder data around your network. This is important as it allows you to visualise your cardholder data flow and establish your Cardholder Data Environment (CDE). 3.1.2
Identifying the Cardholder Data Environment (CDE)
Remember, the Cardholder Data Environment is made up of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. Therefore, it’s important to account for all these entities when establishing the CDE. One way to achieve this is to start with the infrastructure (Network and Cardholder Data Flow Diagram) and then overlay the processes associated with taking card payments within the organization. Finally, add the people in the organization who are involved in the processes. Once you have defined the scope of your CDE then you are ready to start applying the 12 PCI DSS requirements to it.
V3 Copyright CertiKit
Page 17
A Guide to Implementing PCI DSS 3.1.3
Network Segmentation
Although not a mandatory requirement for PCI DSS compliance, often it is beneficial to segment the technical elements of the CDE away from the rest of the infrastructure. Network segmentation is the act of splitting the computer network into subnetworks with each network becoming a segment. To control and protect subnetworks, routers, switches (with appropriate Access Control List functionality) and/or firewalls are installed. From a technical perspective, the CDE will be within its own protected network segment. Without network segmentation to separate and protect the CDE from the rest of the infrastructure using firewalls or ACLs, the organization must accept that the whole infrastructure is part of the CDE and therefore must all be compliant with PCI DSS requirements.
3.2
The Prioritized Approach
The Payment Card Industry Security Standard Council (PCI SSC) offers a pragmatic approach to compliance by breaking down the task into six key milestones. These milestones allow the organization to prioritize the highest risks and threats first, while on its journey to PCI DSS compliance. The PCI DSS website has more information and clear guidance on this approach. It also offers a Prioritized Approach Tool which allows the organization to clearly define its approach and then track and report on its progress while on the road to PCI DSS compliance. We strongly recommend that you consider using this approach.
V3 Copyright CertiKit
Page 18
A Guide to Implementing PCI DSS
4 Submitting Compliance Once the organization is coming towards the end of its journey to initial compliance you will need to start thinking about submitting the appropriate documentation to your acquiring bank. How you do this depends on a number of factors. However, we suggest you start with contacting your acquiring bank to obtain their preferred method of submitting the compliance documents. Some banks ask them to email you the relevant documents, whilst other offer portals to log into and upload the relevant documents.
4.1
Qualified Security Assessor
If your organization falls with the definition of Level 1 for Merchants and Service Providers you are required to submit compliance documents produced by a Qualified Security Assessor (QSA). QSA companies are independent security organizations that have been accredited by the PCI Security Standards Council to validate an organization’s adherence to PCI DSS. A list of QSA companies can be found on the PCI DSS website.
4.2
Report on Compliance (RoC)
Completed by a QSA and only required by Level 1 merchants and service providers, a Report on Compliance (RoC) provides a comprehensive summary of all 12 PCI DSS requirements undertaken by the organization and all activities and information collected during the assessment. The report should also clearly describe how the organization validates these activities and the resultant findings.
4.3
Self-Assessment Questionnaire (SAQ)
Depending on the level of the organization, a Self-Assessment Questionnaire (SAQ) may be all that is required to be completed and submitted. SAQs are validation tools designed to assist organizations in self-evaluating their compliance with PCI DSS. There are multiple types of SAQs corresponding to the different ways card payment processing is achieved. It is important the organization selects the appropriate SAQ(s) applicable to them. Following section 3 of this document will give you a good idea about this, but we strongly recommend that you refer to the PCI DSS website for further information to select the SAQ(s) best applied to your organization.
V3 Copyright CertiKit
Page 19
A Guide to Implementing PCI DSS
5 Conclusion This implementation guide has taken you through the process of making your organization PCI DSS compliant, supported by the CertiKit PCI DSS Toolkit. Implementing and maintaining PCI DSS compliance can be a big culture change towards becoming more proactive as an organization and, with the day to day reactive pressures of delivering a product or service, it can sometimes seem daunting. However, we hope you will find that the CertiKit PCI DSS Toolkit will allow your organization to take a significant step forward on your journey to PCI DSS compliance. We wish you good luck in your work and, as always, we welcome any feedback you wish to give us via feedback@certikit.com.
V3 Copyright CertiKit
Page 20