For earlier 9 points kindly refer to my earlier blog at Considerations for PA-DSS Compliant Solution Development – Part 1
- Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes, to include the following:
a. Documentation of impact: document the impact of change in code or customization of software.
b. Documented change approval by authorized parties.
c. Functionality testing to verify that the change does not adversely impact the security of the system.
d. Back out Procedures
- Testing should be done to avoid any flaws like SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws, Buffer overflows, cross site scripting attacks and cross site request forgery (CSRF).
- Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
- Un-validated input
- Broken access control (for example, malicious use of user IDs)
- Broken authentication and session management (use of account credentials and session cookies)
- Cross-site scripting (XSS) attacks
- Buffer overflows
- Injection flaws (for example, structured query language (SQL) injection)
- Improper error handling
- Insecure storage (cryptographic or otherwise)
- Denial of service
- Security Misconfiguration
- Insecure Direct Object References
- Cross-Site Request Forgery (CSRF)
- Failure to Restrict URL Access
- Insufficient Transport Layer Protection
- Unvalidated Redirects and Forwards
- SSL protects data that is transmitted between a browser and web server. It is critical that you have SSL enabled on the web server, and this should be among the first steps taken after installation.
- Web server must be configured to use SSL v3 or TLS v1 protocols with strong encryption (128-bit or longer key is required)
- Install SSL certificate issued for specified web domain.
- PCI compliance requires that you use unique user names and secure authentication to access any PCs, servers, and databases with payment applications and/or cardholder data. This means that you should use different user names/passwords:
a. For your Web hosting account administration area (Web hosting account where your online store is hosted)
b. For FTP access to the Web server
c. For Remote Desktop Connection to the Web server (if available)
d. To connect to the MySQL server that contains your store data.
- Audit trails
Audit trails/logs are should be automatically enabled with the default installation of software solution. There should be no option to disable audit logging.
The following types of activity should be logged:a. All actions taken by any individual with root or administrative privileges
b. Initialization of the audit logs
c. User sign in and sign out.
Individual access to cardholder data is not logged, because cardholder data is not stored before and after authentication. Access to audit trails must be provided on the operating system level.
Each log event includes:
1. Type of event
2. Date and time of event
3. Username and IP address
4. Success or failure indication
5. Action which led to the event
6. Component which led to the event
- Wireless communications
a. If you use wireless networking to access software, it is your responsibility to ensure your wireless security con figuration follows the PCI DSS requirements.
b. Personal firewall software should be installed on any mobile and employee-owned computers that have direct access to the internet and are also used to access your network.
c. Change wireless vendor defaults, including but not limited to, wired equivalent privacy (WEP) keys, default service set identifier (SSID), passwords and SNMP community strings. Disable SSID broadcasts. Enable WiFi protected access (WPA and WPA2) technology for encryption and authentication when WPA-capable.
d. Encrypt wireless transmissions by using WiFi protected access (WPA or WPA2) technology, IPSEC VPN, or SSL/TLS.
e. Never rely exclusively on wired equivalent privacy (WEP) to protect confidentiality and access to a wireless LAN. If WEP is used, do the following:
f. Use with a minimum 104-bit encryption key and 24 bit-initialization value
g. Use ONLY in conjunction with WiFi protected access (WPA or WPA2) technology, VPN, or SSL/TLS
h. Rotate shared WEP keys quarterly (or automatically if the technology permits)
i. Rotate shared WEP keys whenever there are changes in personnel with access to keys
j. Restrict access based on media access cod e (MAC) address.
k. Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny any traffic from the wireless environment or to control any traffic if it is necessary for business purposes.
- Remote access
Software provides web-based access using two-factor authentication based on one-time PIN codes.a. If you enable remote access to your network and the cardholder data environment, you must implement two-factor authentication. Use technologies such as remote authentication and dial-in service (RADIUS) or terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates. You should make sure that any remote access software is securely configured by keeping in mind the following:
b. Change default settings in the remote access software (for example, change default passwords and use unique passwords for each customer)
c. Allow connections only from specific (known) IP/MAC addresses
d. Use strong authentication or complex passwords for logins
e. Enable encrypted data transmission
f. Enable account lockout after a certain number of failed login attempts
g. Configure the system so a remote user must establish a Virtual Private Network (“VPN”) connection via a firewall before access is allowed
h. Enable any logging or auditing functions
i. Restrict access to customer passwords to authorized reseller/integrator personnel
j. Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup).
