Security Controls and Processes for PCI DSS Requirements

We already have a post called PCI-DSS that you can read it here. Now, in this post, we are going to get acquainted with the security controls and processes required for a PCI-DSS implementation. This post presents the objectives of PCI DSS and related 12 requirements.

This article is a summary from of the pcisecuritystandards.org website. With the following link:

PCI DSS Quick Reference Guide

For more info please refer to pcisecuritystandards.org

The goal of the PCI Data Security Standard (PCI DSS) is to protect cardholder data and sensitive authentication data wherever it is processed, stored or transmitted. The security controls and processes required by PCI DSS are vital for protecting all payment card account data, including the PAN – the primary account number printed on the front of a payment card. This includes the 3- or 4- digit security code printed on the front or back of a card, the data stored on a card’s magnetic stripe or chip (also called “Full Track Data”) – and personal identification numbers (PIN) entered by the cardholder.

 

 

Firewalls are devices that control computer traffic allowed into and out of an organization’s network, and into sensitive areas within its internal network.

Routers are hardware or software that connects two or more networks.

1. Establish and implement firewall and router configuration standards in such a way that the following items are observed in them: (1) These configurations standards formalize test whenever configurations change; (2) These configurations standards identify all connections between the cardholder data environment and other networks (including wireless) with documentation and diagrams; (3) These configurations standards will document business justification and various technical settings for each implementation; (4) These configurations standards will diagram all cardholder data flows across systems and networks; (5) These configurations standards will stipulate a review of configuration rule sets at least every six months.
2. Build firewall and router configurations that restrict all traffic, inbound and outbound, from “untrusted” networks (including wireless) and hosts, and specifically deny all other traffic except for protocols necessary for the cardholder data environment.
3. Prohibit direct public access between the Internet and any system component in the cardholder data environment.
4. Install personal firewall software or equivalent functionality on any devices that connect to the Internet when outside the network, and which are also used to access the cardholder data environment.
5. Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

 

 

The easiest way for a hacker to access your internal network is to try default passwords or exploits based on default system software settings in your payment card infrastructure. Default passwords and settings for most network devices are widely known.

• Always change ALL vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.
• Develop configuration standards for all system components that address all known security vulnerabilities and are consistent with industry-accepted definitions.
• Using strong cryptography, encrypt all non-console administrative access.
• Maintain an inventory of system components that are in scope for PCI DSS.
• Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.
• Shared hosting providers must protect each entity’s hosted environment and cardholder data.

 

 

Cardholder data should not be stored unless it’s necessary to meet the needs of the business. Sensitive data on the magnetic stripe or chip must never be stored after authorization.

1. Limit cardholder data storage and retention time to that which is required for business, legal, and/or regulatory purposes. Purge unnecessary stored data at least quarterly.
2. Do not store sensitive authentication data after authorization.
3. Mask PAN when displayed (the first six and last four digits are the maximum number of digits you may display), so that only authorized people with a legitimate business need can see more than the first six/last four digits of the PAN.
4. Render PAN unreadable anywhere it is stored – including on portable digital media, backup media, in logs, and data received from or stored by wireless networks.
5. Document and implement procedures to protect any keys used for encryption of cardholder data from disclosure and misuse.
6. Fully document and implement key management processes and procedures for cryptographic keys used for encryption of cardholder data.
7. Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

 

 

Encryption is one technology that can be used to render transmitted data unreadable by any unauthorized person.

1. Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
2. Never send unprotected PANs by end user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.).
3. Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

 

 

Malware exploits system vulnerabilities after entering the network via users’ email and other online business activities. So, anti-virus software must be used on all systems commonly affected by malware.

1. For systems not affected commonly by malicious software, perform periodic evaluations to evaluate evolving malware threats and confirm whether such systems continue to not require anti-virus software.
2. Ensure that all anti-virus mechanisms are kept current, perform periodic scans, and generate audit logs, which are retained per PCI DSS Requirement 10.7.
3. Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users.
4. Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

 

 

Security vulnerabilities in systems and applications may allow criminals to access PAN and other cardholder data. Many of these vulnerabilities are eliminated by installing vendor-provided security patches, which perform a quick-repair job for a specific piece of programming code.

1. Establish a process to identify security vulnerabilities, using reputable outside sources, and assign a risk ranking to newly discovered security vulnerabilities.
2. Protect all system components and software from known vulnerabilities by installing applicable vendor-supplied security patches.
3. Develop internal and external software applications including web-based administrative access to applications in accordance with PCI DSS and based on industry best practices.
4. Ensure all relevant PCI DSS requirements are implemented on new or changed systems and networks after significant changes.
5. Prevent common coding vulnerabilities in software development processes by training developers.
6. Ensure all public-facing web applications are protected against known attacks, either by performing application vulnerability assessment at least annually and after any changes, or by installing an automated technical solution.
7. Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

 

 

————————-

This article is a summary from of the pcisecuritystandards.org website. With the following link:

PCI DSS Quick Reference Guide

For more info please refer to pcisecuritystandards.org

————————-

 

 

To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.

1. Limit access to system components and cardholder data to only those individuals whose job requires such access.
2. Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.
3. Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

 

 

Assigning a unique identification (ID) to each person with access ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

1. Assign all users a unique user name before allowing them to access system components or cardholder data.
2. Use two-factor authentication or multi-factor authentication to authenticate all users. Also render all passwords/passphrases unreadable during transmission and storage using strong cryptography.
3. Secure all individual non-console administrative access and all remote access to the cardholder data environment using multi-factor authentication.
4. Develop, implement, and communicate authentication policies and procedures to all users.
5. Do not use group, shared, or generic IDs, or other authentication methods.
6. Use of other authentication mechanisms such as physical security tokens, smart cards, and certificates must be assigned to an individual account.
7. All access to any database containing cardholder data must be restricted: (1) all user access must be through programmatic methods; (2) only database administrators can have direct or query access; (3) application IDs for database applications can only be used by the applications (and not by users or non-application processes).
8. Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

 

 

Any physical access to data or systems that house cardholder data provides the opportunity for persons to access and/or remove devices, data, systems or hardcopies, and should be appropriately restricted.

“Onsite personnel” are full- and part-time employees, temporary employees, contractors, and consultants who are physically present on the entity’s premises.

“Visitors” are vendors and guests that enter the facility for a short duration – usually up to one day. “Media” is all paper and electronic media containing cardholder data.

1. Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment.
2. Develop procedures to easily distinguish between onsite personnel and visitors, such as assigning ID badges.
3. Control physical access for onsite personnel to the sensitive areas. Access must be authorized and based on individual job function and access must be revoked immediately upon termination.
4. Ensure all visitors are authorized before entering areas where cardholder data is processed or maintained, given a physical badge or other identification that expires and identifies visitors as not onsite personnel, and are asked to surrender the physical badge before leaving the facility or at the date of expiration.
5. Physically secure all media; store media back-ups in a secure location, preferably off site.
6. Maintain strict control over the internal or external distribution of any kind of media.
7. Maintain strict control over the storage and accessibility of media.
8. Destroy media when it is no longer needed for business or legal reasons.
9. Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.
10. Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

 

 

Logging mechanisms and the ability to track user activities are critical for effective forensics and vulnerability management. The presence of logs in all environments allows thorough tracking and analysis if something goes wrong.

1. Implement audit trails to link all access to system components to each individual user.
2. Implement automated audit trails for all system components for reconstructing these events: (1) all individual user accesses to cardholder data; (2) all actions taken by any individual with root or administrative privileges; (3) access to all audit trails; invalid logical access attempts; (4) use of and changes to identification and authentication mechanisms (5) all changes, additions, deletions to accounts with root or administrative privileges; (6) initialization, stopping or pausing of the audit logs and (7) creation and deletion of system-level objects.
3. Record audit trail entries for all system components for each event, including at a minimum: (1) user identification, (2) type of event, date and time, (3) success or failure indication, origination of event, and (4) identity or name of affected data, system component or resource.
4. Synchronize all critical system clocks and times and implement controls for acquiring, distributing, and storing time.
5. Secure audit trails so they cannot be altered.
6. Review logs and security events for all system components to identify anomalies or suspicious activity.
7. Retain audit trail history for at least one year.
8. Service providers must implement a process for timely detection and reporting of failures of critical security control systems.
9. Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

 

 

System components, processes, and custom software should be tested frequently to ensure security is maintained over time.

1. Implement processes to test for the presence of wireless access points (802.11) and detect and identify all authorized and unauthorized wireless access points on a quarterly basis.
2. Run internal and external network vulnerability scans at least quarterly and after any significant change in the network.
3. Develop and implement a methodology for penetration testing that includes external and internal penetration testing at least annually and after any significant upgrade or modification.
4. Use network intrusion detection and/or intrusion prevention techniques to detect and/or prevent intrusions into the network. IDS/IPS engines, baselines, and signatures must be kept up to date.
5. Deploy a change detection mechanism (for example, file integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files or content files. Configure the software to perform critical file comparisons at least weekly.
6. Ensure that related security policies and operational procedures are documented, in use, and known to all affected parties.

 

 

1. Establish, publish, maintain, and disseminate a security policy; review the security policy at least annually and update when the environment changes.
2. Implement a risk assessment process that is performed at least annually.
3. Develop usage policies for critical technologies (like remote access, wireless, removable electronic media, laptops, tablets, handheld devices, email and Internet) to define their proper use by all personnel.
4. Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.
5. Assign to an individual or team information security responsibilities defined by 12.5 subsections.
6. Implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures.
7. Screen potential personnel prior to hire to minimize the risk of attacks from internal sources.
8. Maintain and implement policies and procedures to manage service providers with which cardholder data is shared.
9. Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data that they possess or otherwise store, process, or transmit on behalf of the customer, or to the extent they could impact the security of the customer’s cardholder data environment.
10. Implement an incident response plan. Be prepared to respond immediately to a system breach.
11. Service providers must perform and document reviews at least quarterly to confirm personnel are following security policies and operational procedures.

 

 

 

————————-

Source:

This article is a summary from of the pcisecuritystandards.org website. With the following link:

PCI DSS Quick Reference Guide

For more info please refer to pcisecuritystandards.org