PCI DSS Principles

Some notes from various Payment PCI DSS (Payment Card Industry Data Security Standard) Literature/Books

This is a long post and covers multiple books. 

This is synopsis of the synopsis. Implement all this and you will have a good secure network, remember it will be point in time secure.

• PCI DSS is Not Law

• Companies that store, transmit or process Credit Card/Debit Card data must comply

• Merchant and Service level define whether you can self audit or need to external audit annually

• Remember it is a moment in time audit

• QSA’s (Qualified Security Assessor) cannot automatically do Vulnerability Scans unless they are also an ASV (Approved Scanning Vendor)

• QSA’s (Qualified Security Assessor) have to re-certify annually

• QSA’s (Qualified Security Assessor) need really good insurance

• Requirements overview

• Firewalls with default passwords changed

• Encrypt data at rest and in transport

• Anti Virus Software and patching

• Least privilege access

• Unique logins

• Restrict physical access

• Logging

• Test security

• Information Security policies

• If can’t meet exact requirements listed above, you have to be able to demonstrate you have tried. Same as principle as GDPR.

• Change management process required

• Network diagram required

• Open ports on Firewalls must be documented and justified, also a potential risk assessment performed.

• You can open the port, but need to be able to justify it.

• Firewalls between DMZ and internal network

• Review rules every six months

• Firewalls to only allow the minimum of traffic required

• Critical servers must be on their own “hardware” not shared

• Can use virtualization

• Stop unnecessary services running

• SSH, never Telnet

• Firewalls – start with deny all, then consider allowing certain traffic types

• Card holders data based on “need to know” access

• RBAC Role based access control

• Unique logins

• 2-Factor authentication for remote users

• Passwords must not sent in clear text

• Passwords must be encrypted at rest

• Password reset by Social Engineering – quite common technique

• Change password at first login

• After 90 days of no access, account  should be removed or disabled

• Remote support/vendor accounts only enabled at point of use

• Customer DB should not be in DMZ or touchable from the Internet

• Firewalls must be statefull

• Don’t have two NICs on customer db machine

• Host firewalls required that cannot be disable by the user

• Harden routers so running config is protected

• Wireless network should be separated from card holder data systems

• Must change default passwords

• Must change SNMP defaults

• Data physically sent externally must be labelled Confidential/Classified. Must be sent by secure courier

• Must have a log tracking movements of sent data

• Shred bins or locked bin required

• Secure disposal, Degaussing of USBs etc

• POS kit should never store data for more than a couple of days

• Only display the last 4 digits of card details

• Don’t store information you don’t need

• Don’t hard code keys into strings

• Keys themselves must be encrypted

• Keys in general

• Symmetric keys need changing more frequently, every couple of weeks

• Asymmetric keys changed every few months

• Data encrypted in transport

• TLS 1.2 at a minimum, no SSLv2

• No WEP

• Train staff never to disclose passwords

• Password life time 90 days

• Must be different from last 4

• 7 elements/chars min. but at least 1 number required

• PCI DSS Does not require special chars, #@ etc, but they are a good idea anyway

• Automatic lockout after 6 failed attempts

• Locked out for at least 30 mins

• Sessions end after 15 mins of idle time

• Whitelist based access

• Physical access security

• Disable publicly accessible switch ports

• Escort visitors

• Wear badges that identify staff and visitors. Visitors must return badges when they leave

• Visitors must sign in

• Off site backups must be secured

• WPA2 Enterprise not personal and never WEP

• Physically secure Access Points

• Centralized logging of/for APs

• Check for rogue Access Points

• IT Security policies required

• Risk assessment required

• Daily operational checklist

• Named CSO/CISO

• Annual staff training

• Staff must sign Security Policies document

• Written contract/agreements with service providers

• IRP (Incident response plan) required

• Must test plan annually

• Must include a Wireless IRP

• Applications not running under admin/root

• Vulnerability scanning at a minimum quarterly basis but better monthly

• Scan after patching

• Scan servers during off peak hours

• Annual penetration testing and after significant infrastructure or application changes

• Monitoring and logging vital

• Segment and control the CDE (Card data environment)

• Base vulnerability management on Risk

• Report non vulnerable systems as well

• CVSS – any score => 4.0 must be fixed

• Update Anti Virus/Anti Malware

• Anti Virus Running and logging

• Logs are critical for compliance

• Can apply a Risk based approach to patching, not a patch in 30 days rule

• Should actively monitor the web for new exploits/vulnerabilities

• Secure development best practices

• Separate development/testing and productions environments

• Don’t use Live data in testing

• Code review before use of custom applications

• XSS very common in PCI scanning

• Key reason for failure

• Tune IPS, reduce false positives

• Quarterly scans by ASV

• After infrastructure changes, scans can be done by internal staff

• ASV will use CVSS

• Fail if using SSL V2.0 or older or vulnerabilities found that could produce SQLi or XSS

• Vulnerabilities leading to DOS attacks are not an automatic failure

• Key point – compliance is about data protection, not availability

• Secure Logs – IDS, AAA, must review them daily, must protect from tamper and deletion. Retain for 1 year, last 3 months must be immediately available. Sync Clocks, AV logs, Event Viewer logs

• HTTP, SSL, SSH, VPN, FTP, Telnet logs retained

• No sensitive information to be stored in logs

• Access controls to logs

• Restrict access to logs

• Log changes, creation and deletion of user accounts

• Visitors log

• Use HIPS, NIDS, IPS/IDS with alerts and rules/signatures kept updated

• Logs that connect to systems that handle credit card data are more important

• Logs connected to user accounts, not computers

• Consistent times across logs – clocks synced

• Secure logs/audit trails

• Backup logs to central secured location

• Security patches applied within 1 month

• Can take a risk based approach to patching

• Can mitigate risk without patching is acceptable

• Automate 90 day old/inactive account removal

• Automate/force password updates requirement

• File/software integrity checking – hash comparisons

• Need to justify that you are looking at log alerts, checking for vulnerabilities, threat hunting

• Security Training – minimum once a year, but that is not really enough in the real world

• Annual testing of IRP (Incident Response Plan)

• Network segmentation not required, but good idea and makes life easier

• Can use ACLs (Access Control Lists) internally

• Difficult to prove you are secure, only really possible to prove you are insecure. Same as cryptography – you can only prove that existing techniques are no good

• User training

• Frequent and brief training sessions

• Firewall and router review every six months, must be able to show the results of the check

• Don’t use MAC address filtering for VLAN segmentation. too easy to bypass

• Don’t have a weak descriptive SSID

PCI DSS is Not Law

Companies that store, transmit or process Credit Card/Debit Card data must comply

Merchant Service/Payment providers

Areas that you need to address and protect

Merchant levels

Service level providers

Merchant and Service level define whether you can self audit or need to external audit annually

Remember it is a moment in time audit

QSA’s cannot automatically do Vulnerability Scans unless they are also an ASV

QSA’s have to re-certify annually

QSA’s need really good insurance

Requirements overview

• Firewalls with default passwords changed
• Encrypt at rest and in transport
• Anti Virus Software and patching
• Least privilege access
• Unique logins
• Restrict physical access
• Logging
• Test security
• Information Security policies

If can’t meet exact requirements listed above, you have to be able to demonstrate you have tried. Same as principle as GDPR.

Costs of compromise

Change management process

Network diagram required

Open ports on Firewalls must be documented and justified, also a potential risk assessment performed.

You can open the port, but need to be able to justify it.

Firewalls between DMZ and internal network

Review rules every six months

Firewalls to only allow the minimum of traffic required

Critical servers must be on their own “hardware” not shared

Can use virtualization

Stop unnecessary services running

SSH, never Telnet

Firewalls – start with deny all, then consider allowing certain traffic types

Card holders data based on “need to know” access

RBAC Role based access control

Unique logins

2-Factor authentication for remote users

Passwords must not sent in clear text

Passwords must be encrypted at rest

Password reset Social Engineering – quite common technique

Change password at first login

After 90 days of no access, account  should be removed or disabled

Remote support/vendor accounts only enabled at point of use

Customer DB should not be in DMZ or touchable from the Internet

Firewalls must be statefull

Don’t have two NICs on customer db machine

Host firewalls required that cannot be disable by the user

Harden routers so running config is protected

Wireless network should be separated from card holder data systems

Must change default passwords

Must change SNMP defaults

Accounts to check and secure

Data physically sent externally must be labelled Confidential/Classified. Must be sent by secure courier

Must have a log tracking movements of sent data

Shred bins or locked bin required

Secure disposal, Degaussing of USBs etc

POS kit should never store data for more than a couple of days

Data you cannot ever permanently store

Only display the last 4 digits of card details

Don’t store information you don’t need

Don’t hard code keys into strings

Keys themselves must be encrypted

Keys in general

• Symmetric keys need changing more frequently, every couple of weeks

• Asymmetric keys changed every few months

Data encrypted in transport

TLS 1.2 at a minimum, no SSLv2

No WEP

Passwords

Train staff never to disclose passwords

Password life time 90 days

Must be different from last 4

7 elements/chars min. but at least 1 number required

PCI DSS Does not require special chars, #@ etc, but they are a good idea anyway

Automatic lockout after 6 failed attempts

Locked out for at least 30 mins

Sessions end after 15 mins of idle time

White list based access

Physical access security

Disable publicly accessible switch ports

Escort visitors

Wear badges that identify staff and visitors. Visitors must return badges when they leave

Visitors must sign in

Off site backups must be secured

WPA2 Enterprise not personal and never WEP

Physically secure Access Points

Centralized logging of/for APs

Check for rogue Access Points

Vulnerability management

IT Sec policies required

Risk assessment required

Daily operational checklist

Named CSO/CISO

Annual staff training

Staff must sign Security Policies document

Written contract/agreements with service providers

IRP (Incident response plan) required

Must test plan annually

Must include a Wireless IRP

Applications not running under admin/root

More logging

Risk Assessment/information handling policies

Key leakage

Wireless

No WEP

Minimum Wireless requirements

Vulnerability scanning at a minimum quarterly basis but better monthly

Scan after patching

Internal and external scanning

external – any Internet facing IP Address

Internal – all systems that relate to PCI

Scan servers during off peak hours

Change management/network changes

Annual penetration testing and after significant infrastructure or application changes

Monitoring and logging vital

Segment and control the CDE (Card data environment)

Base vulnerability management on Risk

Report non vulnerable systems as well

CVSS – any score => 4.0 must be fixed

Update Anti Virus/Anti Malware

Anti Virus Running and logging

Logs are critical for compliance

Anti Malware updated daily

Logging required

Can apply a Risk based approach to patching, not a patch in 30 days

Should actively monitor the web for new exploits/vulnerabilities

Secure development best practices

Separate development/testing and productions environments

Don’t use Live data in testing

Code review before use of custom applications

Change management

OWASP

Types of vulnerabilities

XSS very common in PCI scanning

Key reason for failure

Tune IPS, reduce false positives

Quarterly scans by ASV

After infrastructure changes, scans can be done by internal staff

Choosing ASV provider considerations

ASV will use CVSS

Fail if using SSL V2.0 or older or vulnerabilities found that could produce SQLi or XSS

Vulnerabilities leading to DOS attacks are not an automatic failure

Key point – about data protection, not availability

Change management

Secure Logs – IDS, AAA, must review them daily, must protect from tamper and deletion. Retain for 1 year, last 3 months must be immediately available. Sync Clocks, AV logs, Event Viewer logs

More Logging

HTTP, SSL, SSH, VPN, FTP, Telnet logs retained

More Key Management

No sensitive information to be stored in logs

Access controls to logs

Restrict access to logs

Log changes, creation and deletion of user accounts

Visitors log

Use HIPS, NIDS, IPS/IDS with alerts and rules/signatures kept updated

IRP

Logs that connect to systems that handle credit card data are more important

More logging

Logs connected to user accounts, not computers

Must log

Consistent times across logs – clocks synced

Clock synchronization

Secure logs/audit trails

Backup logs to central secured location

Security patches applied within 1 month

Can take a risk based approach to patching

Can mitigate risk without patching is acceptable

Automate 90 day old/inactive account removal

Automate/force password updates requirement

Penetration Testing areas that should be covered

File/software integrity checking – hash comparisons

Need to justify that you are looking at log alerts, checking for vulnerabilities, threat hunting

Security Training – minimum once a year, but that is not really enough in the real world

Annual testing of IRP (Incident Response Plan)

ISO Standards

File integrity checking

More logging

Network segmentation not required, but good idea and makes life easier

Can use ACLs (Access Control Lists) internally

Difficult to prove you are secure, only really possible to prove you are insecure. Same as cryptography – you can only prove that existing techniques are no good.

Ongoing checking

User training

Frequent and brief training sessions

Firewall and router review every six months, must be able to show the results of the check

Scan systems once a month

General hardening

More PCI DSS Notes, Specifically about WiFi

Don’t use MAC address filtering for VLAN segmentation. too easy to bypass

Access Points/Wireless

Don’t have a weak descriptive SSID