This PCI training is provided free for use. Haekka offers a fully integrated training platform in Slack, enabling users to meet their compliance, privacy, and security training requirements using modern, relevant content delivered 100% in Slack.

Introduction to PCI

PCI, or often PCI DSS (Payment Card Industry Data Security Standard), is an industry led security standard to create a baseline for security of financial, specifically cardholder, data. PCI applies, as a requirement, to all companies that process card payments and all companies that store, process, or transmit cardholder data and/or sensitive authentication data.

The PCI DSS is made up of 12 requirements, each of which has several testing procedures to assess compliance with the requirement, as well as specific guidance behind the requirement. The guidance is most often used to help create compensating controls that do not meet the specific testing procedures for the requirements. The 12 requirements are below.

PCI DSS Requirements

Completing a PCI DSS assessment is an in depth process. The steps required are below:

1. Define the scope of the assessment. This typically involves specifying the technical environment and relevant business units.
2. Using the PCI DSS, do an assessment against all of the testing procedures.
3. Complete the proper report (i.e., Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC)) for your company's merchant level (more on that below).
4. Fill out an Attestation of Compliance for Service Providers or Merchants from the PCI SSC website.
5. Submit the SAQ or ROC, and the Attestation of Compliance, to the requestor.
6. If needed, do remediations and submit documentation of those.

PCI Terms

• PAN - Primary Account Number.
• CHD - Cardholder Data.
• SAD - Sensitive Authentication Data.
• SAQ - Self Assessment Questionnaire. This is completed by the company.
• ROC - Report on Compliance. These are completed by a QSA (approved assessor) and require an onsite assessment.
• CDE - Cardholder Data Environment
• AOC - Attestation of Compliance.
• ASV - Approved Scan Vendor.

PCI DSS is a security standard that applies to all companies that touch cardholder data, including Merchants and Service Providers that provide technology and services to support Merchant cardholder activities.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Entities under PCI

PCI defines entities as either Merchants or Service Providers. Merchants process payments and Service Providers offer services and products to transmit payments.

The number and types of service providers has grown immensely over the last 10 years. As software defined infrastructure (the cloud) has exploded, merchants have increasingly adopted and integrated products from service providers. PCI defines two level of service providers.

1. Level 1 - over 300,000 transaction transmitted per year. ROC required.
2. Level 2 - less than 300,000 transactions transmitted per year. SAQ required.

PCI defines merchants by annual volume of transactions. PCI merchant levels are below.

1. Merchant Level 1 - over 6M card transactions per year. ROC required.
2. Merchant Level 3 - between 20,000 and 1M transactions per year. SAQ required.
3. Merchant Level 2 - between 1M and 6M transactions per year. SAQ required.
4. Merchant Level 4 - less than 20,000 transactions per year. SAQ required.

If you're a technology company and your product is used by merchants to process card payments, you are a service provider under PCI.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Best Practices for PCI

PCI, as a part of their guidance on PCI DSS, provides specific guidance on best practices. The basis of their guidance states that security controls implemented into business-as-usual (BAU). This is similar to the concept of data protection by default and design from GDPR Article 25.

The best practices are broken down into 6 recommendations, which at a high level are best practices for any information security management system (ISMS).

1. Monitoring. Security systems that have been put in place, such as firewalls and access controls, need to be reviewed to ensure they are working as expected.
2. Detect and Mitigate. Failures in security systems should be detected, documented, and mitigated.
3. Change Management. Changes in infrastructure (hardware and virtual), software, and networks need to be evaluated for impact on security and compliance with PCI DSS.
4. Changes in Organization Structure. Similar to the above, but focused on changes to the organization such as acquisitions and mergers, to assess impact on PCI DSS controls and scope.
5. Review and Communicate with Employees. Employees are the operational layer of security. Regular communication with employees and review of implementation of security controls needs to be done.
6. Reviewing Vendor Technologies. On a periodic basis, at least annually, vendor technologies need to be assessed to ensure they continue to be supported by the vendor.

Additionally, though not explicitly included in PCI best practice guidance, segmenting networks so that cardholder data is isolated from other networks is a way to reduce the scope of a PCI assessment and the risk to cardholder data.

Though the requirements themselves go into great detail, PCI DSS is about following best practices for security.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 1] Install a Firewall

A firewall is a device that controls traffic flows into and out of networks. A firewall, in the requirements of PCI, is used to limit access to cardholder data and networks that contain or can access cardholder data. Firewalls exist in many forms today from hardware to virtual / cloud to software, including personal firewalls for end user devices.

The firewall requirement of PCI, like most of PCI and other data protection frameworks, is more than simply install and manage a firewall. There are actually 5 specific requirements for firewalls under PCI, most of which have multiple sub-requirements.

1. Develop firewall standards. Companies need to implement standards for firewalls, including documenting all network diagrams with data flows, creating justifications for all connections between networks, establishing groups and roles for firewall management, and testing firewall settings and configurations every 6 months.
2. Use firewall configurations to restrict network access. This is straightforward as it's the purpose of a firewall. PCI states that firewalls should limit access to connections that are necessary, so deny by default, and to synchronize connections across devices.
3. Prohibit direct access from public networks (the Internet). Companies should implement a DMZ to manage public connectivity to and from its networks that contain cardholder data. The firewall should have rules in place to identify and no allow spoofed, or fake, IP address traffic.
4. Install personal firewalls. For all personal devices that access both the Internet and networks with cardholder data, firewalls need to be installed and running. These firewalls, including on company-owned and employee-owned devices, cannot be alterable by the employees.
5. Ensure firewall security policies are implemented. Companies need to ensure individuals that security policies are in use and that relevant personnel are aware of them.

A firewall is a device used to limit traffic to limit the risk of unauthorized connections into cardholder data environments. Whether hardware or software based, it is a requirement of PCI.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 2] Change System and Vendor Defaults

It is common practice to use third party software, both those under commercial license and open source, in product environments. Their are inherent risks and advantages to this. One of the risks, which is addressed in this PCI requirement, is that 3rd party tools often have known defaults that are commonly exploited if not changed.

1. Change vendor defaults. With both software packages and wireless systems, default passwords and configurations need to be changed.
2. Develop and implement a system standard. Using best practices, establish a system standard, or configuration standard, that ensures vendor defaults are changed, unneeded services, ports, and scripts are removed or inactivated, and that each server only has one primary function.
3. Encrypt all non-console access. Any remote, or non-console access, must be encrypted.
4. Keep a system inventory. Hardware and software needs to be inventoried and that inventory needs to be kept up to date.
5. Policies for changing vendor defaults. Policies and procedures need to be created and implemented for changing vendor and 3rd party defaults. These policies and procedures need to be communicated to relevant staff.
6. Shared hosting providers must protect cardholder data. Hosting providers for environments with cardholder data need to follow requirements of PCI. Specific requirements for hosting providers include restricting processes and access to individual entities and being able to assist in forensics in the case of security incidents and data breaches.

Secure system standards need to be created and followed to ensure common and known vulnerabilities are disabled.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 3] Protect Cardholder Data

Protecting cardholder data seems obvious given the nature and goals of PCI. This specific requirement, which contains 7 sub-requirements, focuses on 2 main strategies for protecting cardholder data - 1) limit the cardholder data you store and / or retain and 2) secure stored cardholder data with strong encryption.

1. Minimize cardholder data storage. Only store cardholder data that is required, delete data when it is not needed, and review cardholder data quarterly to ensure it is being deleted once passed its retention date.
2. Do not store card authentication data. Data that is used to authenticate cardholders includes full track (from the magnetic strip on a card), PIN, and card verification (3 digit code on card) data after authorization. This is sensitive data that is meant to be used at the point of authorization.
3. Mask the PAN when displayed. The personal account number (PAN) should not be shown on screens or receipts or anywhere unless absolutely necessary. The PAN should be masked to only display the first 6 or last 4 digits.
4. Secure stored PANs. Stored PAN need to be encrypted using strong cryptography. Additionally, logical access to stored PANs, such as in a database, needs to be restricted with specific accounts and logical controls beyond system (OS) and network accounts.
5. Secure encryption keys. Cryptographic keys need to be protected. Limit who has access to them and the number of places they are stored. With managed encryption and key services, ensure the service provider follows rules to meet this PCI requirement.
6. Key management. Fully document key management policies and procedures and ensure they meed the requirements of PCI.
7. Communicate to staff. Ensure relevant staff are aware of the key management policies and procedures from above.

In order to protect cardholder data, only store data that is required and secure all cardholder data using strong encryption.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 4] Encrypt Data on Public Networks

The last PCI requirement focused on securing cardholder data that is stored. This requirement mandates that cardholder data transmitted over public or open networks must be encrypted.

1. Encrypt data in transit. Encrypt data in transit over open networks, including wireless networks. Only accept trusted keys and certificates.
2. Do not send PANs over user messaging services. Do not send unprotected cardholder data using technologies such as email, SMS, messaging, and chat.
3. Document and communicate policies and procedures. Clearly document and communicate policies and procedures to relevant staff.

Cardholder data needs to be secured when in transit over open and public networks like the Internet.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 5] Use Anti-Malware and Anti-Virus Software

Malware and viruses are common causes of breaches of networks and systems. PCI mandates the use of anti-virus software that is centrally administered (not modifiable by end users).

1. Deploy anti-virus software. Anti-virus software needs to be installed on personal computers and servers. The software needs to be capable of detecting, removing, and protecting against all known types of malicious software.
2. Keep anti-virus software up to date. Anti-virus software needs to be up to date and periodically tested to ensure it is running and functioning as expected.
3. Do not allow users to disable anti-virus software. Users of systems, in particular end users and their own devices, should not be able to modify or disable anti-virus software.
4. Document and communicate policies and procedures. Clearly document and communicate anti-virus policies and procedures to relevant staff.

In order to meet this PCI requirement, anti-virus software needs to be installed and maintained on all personal computers and servers.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 6] Build Secure Systems and Applications

Software applications and systems in environments with cardholder data or which have access to environments with cardholder data need to be secured against vulnerabilities, both those inherent in the software systems being used and those that emerge through software development.

1. Create a process to identify and catalog vulnerabilities. Identify and catalogue security vulnerabilities according to risk .
2. Keep systems up to date. Install vendor security patches in a timely manner. Critical security patches need to be installed within 1 month of their release.
3. Follow secure development processes. Software development should incorporate security into the development process. Code reviews should be conducted and any test or development accounts should be removed before software is used in production.
4. Implement a software change control process. A change control process needs to be established that includes separate testing and production environments where no testing is down on real customer data. All changes to systems and environments needs to be assessed for impact and approval.
5. Address vulnerabilities in software development. Software developers need to be trained on secure development practices and secure development guidelines need to be created. The specific content of developer software training should be updated based on current best practices and known development vulnerabilities.
6. Protect public-facing web applications. For public facing applications, companies must assess vulnerabilities annually and install a web application firewall (WAF) to continuously monitor web applications.
7. Document and communicate policies and procedures. Clearly document and communicate vulnerability and secure software development policies and procedures to relevant staff.

Securing systems and software is multi-pronged, including a vulnerability management and secure software development.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 7] Need to Know Access

Cardholder data should only be accessed on a need to know basis, meaning the minimum possible access based on individuals and roles.

1. Limit access to those whose job requires it. Define access needs of each role, restrict access to privileged accounts, and document all access requests.
2. Implement access controls with deny all by default. Access controls need to be implemented on all systems. Access privileges are granted based on job roles and functions.
3. Document and communicate policies and procedures. Clearly document and communicate access control policies and procedures to relevant staff.

Default deny access to cardholder data and document all access requests to data.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 8] Identify and Authenticate Access

Each person accessing a system with cardholder data should have a unique identifier. This makes it possible to better monitor access and hold individuals accountable for their actions.

1. Develop policies based on best practices for identification and authentication. All user account need unique IDs. There needs to be a process and documentation when IDs are requested and created. IDs need to be disabled when employees are terminated and locked out after repeated failed attempts.
2. Implement strong password controls. Passwords need to be secured in storage. Passwords, at a minimum, need to be 7 characters and have letters and numbers. Passwords should be rotated every 90 days; this is not best practice security though it remains in PCI.
3. Use multi-factor authentication. All remote access to systems that could lead to access to cardholder data needs to have multi-factor authentication enabled.
4. Educate workforce on authentication policies. Provide best practice education to employees for the creation, management, and use of passwords.
5. Disable generic and group IDs. All generic IDs and group IDs should be deleted or disabled. No users, including privileged users, should be able to use group IDs.
6. Any other non-password authentication must assigned individual accounts. Non-password authentication, such as tokens or key cards, need to individually assigned.
7. Restrict database access. Only programmatic access to databases should be allowed. Individuals should not have direct access to databases.
8. Document and communicate policies and procedures. Clearly document and communicate authentication policies and procedures to relevant staff.

Identification and authentication policies are essential to reducing the risk of unauthorized access to cardholder data and to auditing and forensics.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 9] Restrict Physical Access

Physical access to media, both paper and digital, needs to be restricted under PCI. With the widespread adoption of the cloud and the increased amount of work being done remotely, the dynamics of physical access are changing quickly. In the case of the cloud, the cloud provider, most commonly Amazon, Microsoft, or Google, house the physical systems.

1. Use physical entry controls. Restrict access to facilities that house systems with cardholder data. Use cameras to monitor access. Restrict access to network jacks and wireless networks.
2. Differentiate between personnel and visitors. A badging system should be used to differentiate visitors and personnel.
3. Use physical access controls to limit personnel access. Only personnel with roles that need access should be granted physical access. Access should be revoked upon change in role or termination. Records of access granted and revoked should be maintained.
4. Identify and authorize visitors. Visitors need to be approved before entering, need to use a badge when in a facility, return the badge when they leave, and a log of all visitor activity needs to be maintained.
5. Secure all media. Physical media with cardholder data needs to be protected. This requirement is extended to backups.
6. Control movement of media. Classify all storage media. If media is to be transported, use a secure courier and a documented approval process.
7. Track storage media. Maintain inventory logs of storage media and check inventory at least annually.
8. Destroy media that is no longer needed. For digital media, the cardholder data needs to be rendered unreadable or the physical storage media needs to be destroyed.
9. Protect physical devices that capture card data. These devices are often close to customers and more easily accessible than servers or databases. Special care should be taken in monitoring these devices and educating relevant staff about securing these devices.
10. Document and communicate policies and procedures. Clearly document and communicate physical access policies and procedures to relevant staff.

Physical access controls need to mirror logical access controls. Increasingly, physical controls are pushed onto cloud providers as they manage physical devices.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 10] Monitor and Log Access

The first step to effective monitoring access to networks and systems is to log activity. This data can then be analyzed and use for proactive identification of threats and investigation of potential unauthorized access of data.

1. Enable logging based on individual access. Audit logs need to be created across networks and systems that store or process cardholder data.
2. Automate log reporting for specific use case. PCI requires that certain events are logged. These are events such as user access to cardholder data, access to logs, privileged credential use, and failed login attempts.
3. Record specific data about events. PCI is prescriptive about the minimum data that needs to be logged - user, date, event, system, and origination of event.
4. Synchronize clocks across systems. System times are maintained against industry-accepted time sources.
5. Secure audit trails from tampering. Access to log data needs to be secured and any changes to logs needs to be tracked.
6. Review logs regularly. Daily review is required for security events and systems that store cardholder data. The log review requirement can be addressed with software tools that monitor logs.
7. Retain audit trail for one year. In addition to the requirement of retaining audit logs for a year, the last three months of audit logs must be immediately available.
8. [Service Providers] Detect and report failures. This is a unique requirement for service providers. Service providers must detect and report failures for the devices which they control. Some examples include firewalls, access control mechanisms, and anti-virus software.
9. Document and communicate policies and procedures. Clearly document and communicate monitoring policies and procedures to relevant staff.

Logging data about system access and activity, and monitoring this data, is an essential requirement of PCI.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 11] Test Systems and Processes

The pace of change of technology is only increasing. The dynamic technology environment mandates regular testing to ensure consistency of security controls and manage risk to cardholder data.

1. Test wireless access point. Create an inventory of authorized wireless access points and then regular test for access points to ensure only authorized access points are present.
2. Scan for vulnerabilities. Internal and external vulnerability scans need to be run quarterly or when significant changes are made to networks that process or transmit cardholder data. Vulnerabilities found need to be documented and remediated or mitigated. External scans need to be performed quarterly by an Approved Scanning Vendor (ASV).
3. Penetration testing. Perform internal and external penetration testing at least annually and with significant changes to the CDE environment. A best practice methodology, such as those from NIST, should be used. A special sub-requirement for Service Providers that are using network segmentation is that they need to penetration test segmentation controls at least every 6 months.
4. Intrusion detection. Companies need to run intrusion detection systems (IDS) to detect unauthorized access to network with cardholder data. IDS systems need to be kept up to date.
5. File integrity. Run file integrity software to detect changes to configuration and other critical files. Software needs to run each week to detect changes in critical files.
6. Document and communicate policies and procedures. Clearly document and communicate testing policies and procedures to relevant staff.

Continually testing is crucial to ensuring an information security program is implemented as expected. Testing is multi-pronged and PCI requires several types of testing.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Requirement 12] Conduct Security Training for Entire Workforce

Your workforce, including both employees and contractors, are your perimeter and most important line of defense. Effective employee training is essential to operationalize a security program. Additionally, managing risk internally and through Service Providers is a necessary part of a security program.

1. Create a security policy. This policy needs to be reviewed annually and provided to all employees, vendors, and business partners.
2. Implement a risk assessment process. Using a best practice methodology such as NIST, conduct and document a formal risk assessment annually or with significant changes to cardholder environments.
3. Develop proper use policy for technologies. Inventory and catalog critical technologies by owner, function and proper usage. Document explicit approval for access to critical technologies.
4. Assign responsibility to personnel. All personnel need to be informed of their roles and responsibilities under the security program. Service Providers must create a charter for PCI DSS.
5. Assign an owner for the security program. Assign an individual or team to be responsible for the policies and procedures of the security program.
6. Create and implement a security awareness program. Personnel should receive security training ar hire and at least annually. Personnel should also acknowledge they understand the security policy.
7. Screen personnel prior to hire. Background checks, employment references, and credit checks are different types of screening for prospective hires. These screenings should be performed before granting access to cardholder data and systems.
8. Create a program to manage 3rd party Service Providers. Managing 3rd parties through documented data agreements that clearly outline responsibilities for components of cardholder environments.
9. [Service Providers] Acknowledge responsibility in writing. Service providers must provide written documentation of their responsibility for the security of cardholder data.
10. Implement an incident response plan. Create a plan with clear steps and roles. Inform all personell responsible. And test the plan at least annually.
11. [Service Providers] Review personnel activities follow policies. At least quarterly, ensure personnel are following security policies and procedures.

Managing risk and Service Providers, as well as educating all staff, helps to protect the perimeter of your network.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

© 2020 DayZero Inc. All rights reserved.

Questions? Reach out to us - hello@haekka.com

‍