Considerations for PCI-DSS Compliant Solution Development — Part 2

Lalit Kale Lalit Kale
Part of the series: PCI-DSS Compliance
PCIPCI-DSSsecuritycompliancesoftware development

In Part 1, we covered the first nine considerations for building software in a PCI-DSS compliant environment. This post continues with considerations 10 through 17, where the requirements get more technically specific—touching secure coding practices, data protection, audit logging, wireless security, and remote access.

10. Use documented change management for code changes

All application changes must follow a documented change management process. This includes impact documentation (a clear description of what the change does and what it affects), approval by authorized parties before being applied, functionality testing to confirm the change does not degrade or bypass existing security controls, and a defined back-out procedure in case the change needs to be reversed.

The intent is that every code change is deliberate, traceable, and verified—not just correct in function, but safe in terms of security posture.

11. Prevent common application vulnerabilities

Applications must be developed to guard against well-known classes of vulnerabilities. At a minimum, the following attack vectors must be considered and mitigated:

  • SQL injection
  • OS command injection
  • LDAP and XPath injection flaws
  • Buffer overflows
  • Cross-site scripting (XSS)
  • Cross-site request forgery (CSRF)

These are not theoretical concerns. They are among the most frequently exploited vulnerabilities in payment applications and are specifically called out by the PCI-DSS standard.

12. Follow secure coding guidelines (e.g., OWASP)

Web applications must be built in accordance with established secure coding standards, such as the OWASP Top Ten. Code reviews should actively look for the following vulnerabilities:

  • Unvalidated input
  • Broken access control
  • Broken authentication and session management
  • Cross-site scripting (XSS)
  • Buffer overflows
  • Injection flaws (SQL, LDAP, OS command)
  • Improper error handling
  • Insecure data storage
  • Denial of service vulnerabilities
  • Security misconfiguration
  • Insecure direct object references
  • Cross-site request forgery (CSRF)
  • Failure to restrict URL access
  • Insufficient transport layer protection
  • Unvalidated redirects and forwards

A systematic approach to code review—informed by a checklist like this—is far more effective than ad hoc security checks.

13. Enforce SSL/TLS for data in transit

Web servers must be configured to use SSL v3 or TLS v1 (or later) with strong encryption—a minimum of 128-bit key length. Valid SSL/TLS certificates must be installed for all domains handling payment data.

Transmitting cardholder data over unencrypted channels, even on internal networks, is a compliance violation and a serious security risk.

14. Use unique credentials for every system access point

Every system that handles payment data must require unique usernames and secure authentication. Shared credentials are not permitted. This applies separately to each of the following access points:

  • Web hosting administration consoles
  • FTP access
  • Remote desktop (RDP) connections
  • Database connections

Using distinct credentials per access type ensures that a compromise of one credential set does not automatically expose all other access paths.

15. Implement automatic, tamper-evident audit logging

Audit trail logging must be enabled automatically and must not be possible to disable by regular users. Logs must capture the following for each relevant event:

  • The action performed (e.g., sign-in, sign-out, configuration change)
  • Timestamp
  • Username
  • IP address
  • Success or failure indicator

The categories of events that must be logged include:

  • All administrative actions
  • Authentication events (successful and failed logins)
  • Access to cardholder data
  • Changes to audit log settings

Logs must be retained for a minimum of one year, with at least three months immediately available for analysis.

16. Secure wireless networks to PCI-DSS standards

If wireless networking is used anywhere in the cardholder data environment, the following controls are required:

  • Enable WPA or WPA2 encryption—WEP must never be used as the sole wireless protection mechanism
  • Implement MAC address filtering to restrict which devices can connect
  • Change all default wireless network names (SSIDs), passwords, and settings
  • Enable personal firewalls on all devices that connect to the wireless network

Any wireless network in scope for PCI-DSS must be treated with the same rigor as a wired network segment containing cardholder data.

17. Require two-factor authentication for remote access

All remote access into the cardholder data environment must use two-factor authentication. Acceptable mechanisms include:

  • RADIUS with two-factor support
  • TACACS with two-factor support
  • VPN with SSL/TLS

Additional remote access controls include:

  • Change all default remote access credentials and settings
  • Restrict access by IP address and/or MAC address where feasible
  • Enable encryption for all remote sessions
  • Enforce account lockout after repeated failed authentication attempts
  • Require VPN connections for all remote access—direct unencrypted connections are not permitted
  • Enable logging of all remote access sessions
  • Retain remote access audit history for a minimum of one year

Compliance built from the start looks very different from compliance retrofitted onto a system already in production. The delta is usually measured in months of rework and uncomfortable conversations with auditors. The 17 considerations across both parts of this series won’t make those conversations disappear—but they’ll ensure you’re walking into them with evidence rather than apologies.