PCI DSS | What It Is and How to Comply

Firewalls control data transmission between an organisation’s trusted internal networks and untrusted external networks and traffic between sensitive areas of the internal networks themselves. Systems must use firewalls to prevent unauthorised access. Where other system components provide a firewall's functionality, they must also be included in the scope and assessment of this requirement.

The default settings of many commonly used systems are well known, easily exploitable and often used by criminal hackers to compromise them. Vendor-supplied default settings must. Therefore, vendor-supplied default settings must be changed, and unnecessary default accounts disabled or removed before any system is installed on a network. This applies to all default passwords, without exception. If firewalls are correctly implemented according to Requirement 1, they should also comply with Requirement 2.

The storage of cardholder data should be kept to a minimum, and appropriate data retention and disposal policies, procedures and processes should be implemented.

Certain data – such as the full contents of the chip or magnetic strip, the CVN (card verification number) or the PIN (personal identification number) – should never be stored. When data is stored, it should be stored securely.

Encryption, truncation, masking and hashing are critical components of cardholder data protection. Without access to the proper cryptographic keys, encrypted data will be unreadable and unusable by criminal hackers, even if they manage to circumvent other security controls.

Cryptographic keys should therefore be stored securely and access restricted to the fewest custodians necessary. Other data protection methods should also be considered.

Strong cryptography and security protocols (e.g. TLS, IPSec, SSH, etc.) should be used to safeguard sensitive cardholder data during transmission over open, public networks that malicious individuals could easily access.

Examples of open, public networks include the Internet, wireless technologies (e.g. Bluetooth), GPRS (general packet radio service) and satellite communications. Industry best practices must be followed to implement strong encryption for authentication and transmission.

Security policies and procedures for encrypting cardholder data transmission must be documented and made known to all affected parties.

Antivirus software capable of detecting, removing and protecting against all known malware types (e.g. viruses, worms and Trojans) must be used on all systems commonly affected by malware, to protect them from threats. For systems not commonly affected by malware, evolving malware threats should be periodically evaluated to determine if antivirus software is needed. Antivirus mechanisms must be maintained and kept actively running. They should only be disabled if formally authorised for a specific purpose.

Patches issued by software vendors fix many security vulnerabilities. Organisations should establish a process to identify security vulnerabilities and rank them according to their level of risk. Relevant security patches should be installed within a month of their release to protect against cardholder data compromise.

Whether developed internally or externally, all software applications should be developed securely in accordance with the PCI DSS. They should also be based on industry standards and/or best practices and incorporate information security throughout their development life cycle.

Exploiting authorised accounts and abusing user privileges is one of the easiest ways for criminal hackers to access a system. It is also one of the most difficult types of attack to detect.

Therefore, documented systems and processes should be put in place to limit access rights to critical data. Access control systems should deny all access by default. Access should be granted on a need-to-know basis and according to authorised personnel's clearly defined job responsibilities. ‘Need to know’ is defined in the PCI DSS as “when access rights are granted to only the least amount [sic] of data and privileges needed to perform a job”.

The ability to identify individual users not only ensures that system access is limited to those with the proper authorisation, and it also establishes an audit trail that can be analysed following an incident.

Therefore, documented policies and procedures must be implemented to ensure proper user identification management for non-consumer users and administrators on all system components. All users must be assigned a unique ID, which must be managed according to specific guidelines.

Controlled user-authentication management (e.g. the use of passwords, smart cards or biometrics) should also be implemented and 2FA (two-factor authentication) must be used for remote network access.

Electronic data breaches are not the only source of data loss; physical access to systems should also be limited and monitored using appropriate controls.

Procedures should be implemented to distinguish between on-site personnel and visitors. Physical access to sensitive areas (e.g. server rooms and data centres) should be restricted accordingly.

All media should be physically secured, and its storage, access and distribution controlled. Media should be destroyed in specific ways when no longer required.

Devices that capture payment card data via direct physical interaction with the card must be protected from tampering and substitution should be periodically inspected. An up-to-date list of these devices should be maintained.

The use of logging mechanisms is critical in preventing, detecting and minimising the impact of data compromise. If system usage is not logged, potential breaches cannot be identified.

Therefore, secure, controlled audit trails must be implemented that link all access to system components with individual users and log their actions. This includes:

• Access to cardholder data
• Actions taken by individuals with root or administrative privileges
• Access to audit trails
• Invalid logical access attempts
• Use of and changes to identification and authentication mechanisms
• The initialising, stopping or pausing of audit logs
• The creation and deletion of system-level objects.

An audit trail history should be retained for at least a year, with a minimum of three months’ logs immediately available for analysis. Logs and security events should be regularly reviewed to identify anomalous or suspicious activity.

New vulnerabilities are regularly found and exploited, so it is essential that system components, processes and custom software are regularly tested.

Documented processes must be implemented to detect and identify all unauthorised wireless access points every quarter. Internal and external network vulnerability scans must be performed by qualified personnel at least quarterly and after any significant network changes (e.g. new system component installations, changes in network topology, firewall rule modifications and product upgrades).

Intrusion detection/prevention techniques should be used to identify and/or prevent unauthorised network activity,. A change detection mechanism should be employed to perform weekly critical file comparisons, and alert personnel to unauthorised system modifications.

To comply with the PCI DSS, organisations must establish, publish, maintain and disseminate a security policy, which must be reviewed annually and updated according to the changing risk environment. A risk assessment process must be implemented to identify threats and vulnerabilities, usage policies for critical technologies must be developed, security responsibilities for all personnel must be clearly defined, and a formal awareness programme must be implemented. Organisations must also implement an incident response plan so that they can respond immediately to any system breach.