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
Summary
Article Name
PCI DSS Principles
Description
Some notes from various Payment PCI DSS (Payment Card Industry Data Security Standard) Literature/Books. This is a long post and covers multiple books.
Author
Mark WH
Publisher Name
OIC Solutions