Certikit a guide to implementing pci dss

A Guide to Implementing the Payment Card Industry Data Security Standard (PCI DSS)

V2 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 ................................... 8 2.7 REQUIREMENT 7: RESTRICT ACCESS TO CARDHOLDER DATA BY BUSINESS NEED TO KNOW ...................... 9 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 3

WHERE TO START ................................................................................................................................ 15 3.1 KNOWING YOUR NETWORK ..................................................................................................................... 15 3.1.1 Cardholder Data Flow.................................................................................................................. 15 3.1.2 Identifying the Cardholder Data Environment (CDE) .................................................................. 15 3.1.3 Network Segmentation .................................................................................................................. 16 3.2 THE PRIORITIZED APPROACH .................................................................................................................. 16

4

SUBMITTING COMPLIANCE .............................................................................................................. 17 4.1 4.2 4.3

5

QUALIFIED SECURITY ASSESSOR ............................................................................................................ 17 REPORT ON COMPLIANCE (ROC)............................................................................................................. 17 SELF-ASSESSMENT QUESTIONNAIRE (SAQ) ........................................................................................... 17

CONCLUSION.......................................................................................................................................... 18

V2 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

V2 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.

V2 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.

V2 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

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 that there is 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 effectively change management.

Effective firewall configurations are also part of this requirement to protect the cardholder data.

Configurations include restricting connections from untrusted networks to the network where cardholder data is present, restrict all traffic that is not necessary for the cardholder data environment, implement anti spoofing measures and implement a DMZ. 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 actively on at all times and is not alterable by users of the portable computer.

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.

Relevant Toolkit Documents • • • •

Network Security Policy Configuration Standard Template Network Diagram Example Cardholder Data Flow Diagram Example

V2 Copyright CertiKit

Page 5

A Guide to Implementing PCI DSS • •

2.2

Mobile Device Policy Configuration Review Form

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Even in today’s world the use of vendor-supplied default passwords is significant. 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 states that system components address all known vulnerabilities and are consistent with industryaccepted system hardening standards. These include, but are not limited to: • • • •

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 a 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 services and deamons are enabled to allow the function 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 to 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.

Relevant Toolkit Documents • • • •

Password Policy Configuration Standard Template Cardholder Data Environment Asset Inventory Database Operational Procedure Template

V2 Copyright CertiKit

Page 6

A Guide to Implementing PCI DSS 2.3

Requirement 3: Protect stored cardholder data

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 cardholders name, Primary Account Number (PAN), expiration data 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 key 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.

Relevant Toolkit Documents • •

2.4

Data Retention and Protection Policy Cryptographic Policy

Requirement 4: Encrypt transmission of cardholder data across open, public networks

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, organizations’ wireless networks are often misconfigured or have legacy equipment that potentially have vulnerabilities that are prone to attack.

This requirement ensures cardholder data is secured in transmission. To do this, strong cryptography and security protocols must be used always 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

V2 Copyright CertiKit

Page 7

A Guide to Implementing PCI DSS 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.

Relevant Toolkit Documents • • •

2.5

Personal Commitment Statement Cryptographic Policy Data Retention and Protection Policy

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs

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 activates 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. Within the policy it must detail how the Organization achieves the managing and maintaining of anti-virus software covering off items such as: • • •

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.

Relevant Toolkit Documents •

2.6

Anti-Malware Policy

Requirement 6: Develop and maintain secure systems and applications

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

V2 Copyright CertiKit

Page 8

A Guide to Implementing PCI DSS 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.

It is required to implement a technical vulnerability management policy. This allows the Organization to state how they intend to manage vulnerabilities. Items included to manage these are: • • • •

Identifying what systems need to be vulnerability managed Applying a risk ranking to vulnerabilities (for example, as high, medium or low) Stating the frequency of when the Organization applies the vulnerability patches to the systems Ensuring that critical updates are applied within one month of release

Organizations that create and development their own software must ensure that the software is developed in accordance with industry standards and/or best practices. A software policy is implemented here to state how the Organization achieves this. Within the policy it will state that all development is within the PCI DSS compliance and incorporates information security in general throughout the software-development life cycle. Custom code should also be reviewed prior to release to production to ensure the software is coded 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 mst 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.

Relevant Toolkit Documents • • • • •

2.7

Technical Vulnerability Management Policy Software Policy Change Management Process Change Request Form Technical Request for Change Form

Requirement 7: Restrict access to cardholder data by business need to know

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 access rights

V2 Copyright CertiKit

Page 9

A Guide to Implementing PCI DSS are granted to only the least amount of data and privileges needed to perform a job role. This requirement ensures effective authorization is actively being used within the organization.

An access control policy will need to be implemented here. Within the policy it must define access needs for each role within the Organization for system components along with access level. For example, user or administrator access. Justification will be needed per role access as it is a requirement to state access to system components. This limits access to system components and cardholder data to only those individuals whose job requires such access. Documented approval of access to system components is needed 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.

Relevant Toolkit Documents • • •

2.8

Access Control Policy User Access Management Process Change Request Form

Requirement 8: Identify and authenticate access to system components

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.

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 ensure the one-time password is used so the user can change their password upon first logon to the system component. This ensures that only the individual 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 important and fundamental part of this requirement. Individuals must know the importance of keeping their passwords secure and been

V2 Copyright CertiKit

Page 10

A Guide to Implementing PCI DSS given guidance on selecting strong authentication credentials. The toolkits Security Awareness Training slides can 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.

Relevant Toolkit Documents • • • • •

2.9

Password Policy Remote Working Policy Cryptography Policy Security Awareness Training Presentation Slides Information Security Communication Programme

Requirement 9: Restrict physical access to cardholder data

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 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. For example, video cameras.

Physical and/or logically controls must be in place to protect the following components: • • • • •

Network jacks in public locations Wireless access points Gateways Handheld devices Networking or communication lines

Asset management is also a key part to this requirement. Recording assists, including make, model and serial numbers etc. is important to correctly identify assets. Procedures will also need to be implemented for the safe harbor of assets going offsite. In doing this the Organization can ensure the protection of assets within the cardholder data environment. Periodically inspection of assets is also required. This helps the Organization prevent the risk of an asset being tampered with that cause compromise to 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.

V2 Copyright CertiKit

Page 11

A Guide to Implementing PCI DSS Relevant Toolkit Documents • • • • •

Physical Security Policy Procedure for Taking Assets Offsite Cardholder Data Environment Access Procedure Visitor Log Cardholder Data Environment Asset Inventory Database

2.10 Requirement 10: Track and monitor all access to network resources and cardholder data 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 all events and being reviewed on a regular basis.

A procedure for the monitoring of IT systems must be in place here. Within the procedure it must explain what actions are needed to take place to monitor all IT systems. These actions include: • • • • • •

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 it required when monitoring the systems. The following areas are needed to fufil this requirement: • • • • • • •

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 industry accepted time sources. This way when reviewing logs, you can ensure it’s the correct time and date when an event occurred.

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.

V2 Copyright CertiKit

Page 12

A Guide to Implementing PCI DSS Relevant Toolkit Documents • • •

Network Security Policy Monitoring the Use of IT Systems Procedure Security Incident Response Procedure

2.11 Requirement 11: Regularly test security systems and processes One of the best ways to ensure the organization’s security controls are sufficient is to perform regular vulnerability testing. This requirement ensures testing in completed frequently 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 include: • • •

Internal and external vulnerability scans – To be completed at least quarterly by an approved scanning vendor. This list can be found on the PCI DSS website.

External penetration scan at least annually or after and significant change that could affect the cardholder data environment Test for the presence pf unauthorized wireless access points. These tests should be completed at least quarterly.

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 treatment plan.

Prevention and detection technologies should also be implemented to further improve security.

These technologies and the above testing should me 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.

Relevant Toolkit Documents • • • • • • • •

Technical Vulnerability Management Policy Network Security Policy Cardholder Data Environment Asset Inventory Database Security Incident Response Procedure Risk Assessment and Treatment Process Risk Treatment Plan Change Control Process Procedure for Monitoring the Use of IT Systems

V2 Copyright CertiKit

Page 13

A Guide to Implementing PCI DSS 2.12 Requirement 12: Maintain a policy that addresses information security for all personnel 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 bring similarities 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 Employee screening Incident response process

All of the above items contribute positively to the confidentiality and integrity to cardholder data.

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 Treatment Process Risk Treatment Plan Internet Acceptable Use Policy Mobile Device Policy Electronic Messaging Policy Remote Working Policy Security Awareness Training Presentation Slides

V2 Copyright CertiKit

Page 14

A Guide to Implementing PCI DSS

3 Where to start The first, and probably most important, step towards implementing the 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 organisation

Knowing your network

Understanding your network sounds an obvious and easy step to complete but many organizations who think they do, 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 Check Data – Checking every bit of data is an almost impossible task without tools to assist but without checking you will never be sure what types of data are stored and where 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.

V2 Copyright CertiKit

Page 15

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 ACL’s, 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.

V2 Copyright CertiKit

Page 16

A Guide to Implementing PCI DSS

4 Submitting Compliance Once the organization is coming towards the end of its compliance journey you will need to start thinking about submitting the appropriate documentation to your acquiring bank. How you do this depends on a few factors, which this section covers. 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.

V2 Copyright CertiKit

Page 17

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.

V2 Copyright CertiKit

Page 18