Tag Archives: PCI-DSS

Considerations for PCI-DSS Compliant Solution Development – Part 2

For earlier 9 points kindly refer to my earlier blog at Considerations for PCI-DSS Compliant Solution Development – Part 1

  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
  2. 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).
  3. 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
  4. 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.
  5. 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 serverc. For Remote Desktop Connection to the Web server (if available)d. To connect to the MySQL server that contains your store data.
  6. 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 privilegesb. Initialization of the audit logsc. 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

  7. Wireless communicationsa. 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.

  8. 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 addressesd. Use strong authentication or complex passwords for loginse. Enable encrypted data transmissionf. 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).

Considerations for PCI-DSS Compliant Solution Development – Part 1

Following are the considerations for the development and Implementation of software solutions in a PCI-DSS Compliant Environment. These should be treated as functional and/or quality requirements while developing PCI DSS Compliant solution.

  1. Ensure that all system components and software are protected from known vulnerabilities by having the latest vendor supplied security patches installed. Install critical security patches within one month of release. This applies to all frameworks as well as operating systems and other software installed in production environment.
  2. The PCI-DSS requires that access to all systems in the payment processing environment be protected through use of unique users and complex passwords. Unique user accounts indicate that every account used is associated with an individual user with no use of generic group accounts used by more than one user. Additionally any default accounts provided with operating systems, databases and/or devices should be removed/disabled/renamed as soon as possible.E.g. Default administrator accounts include “administrator” (Windows systems), “sa” (SQL/MSDE), and “root” (UNIX/Linux) should be disabled or removed.The PCI-DSS standard requires the following password complexity for compliance (often referred to as using “strong passwords”):

    a. Passwords must be at least 7 characters

    b. Passwords must include both numeric and alphabetic characters

    c. Passwords must be changed at least every 90 days

    d. New passwords can’t be the same as the last 4 passwords

    The PCI-DSS user account requirements beyond uniqueness and password complexity are as follows:

    a. If an incorrect password is provided 6 times the account should be locked out

    b. Account lock out duration should be at least 30 min. (or until an administrator resets it)

    c. Sessions idle for more than 15 minutes should require re-entry of username and password to reactivate the session.

    d. Do not use group, shared or generic user accounts

     

  3. PCI DSS applies wherever account data is stored, processed or transmitted. The primary account number is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed or transmitted, PCI DSS requirements do not apply.The following table illustrates commonly used elements of cardholder and sensitive authentication data, whether storage of each data element is permitted or prohibited, and whether each data element must be protected. This table is not exhaustive, but is presented to illustrate the different types of requirements that apply to each data element.

     

  4. Removal of custom application accounts, user IDs, and passwords before applications become active or are released to customers.
  5. Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability.
  6. There should be separate development/test and production environments.
  7. Reduce the number of personnel with access to the production environment and cardholder data minimizes risk and helps ensure that access is limited to those individuals with a business need to know.
  8. Production data (live PANs) are not used for testing or development.
  9. Test data and accounts should be removed from production code before the application becomes active.

PCI Compliance Overview

 

PCI DSS version 2.0 must be adopted by all organizations with payment card data by 1 January 2011, and from 1 January 2012 all assessments must be against version 2.0 of the standard.

It specifies the 12 requirements for compliance, organized into six logically-related groups, which are called “control objectives”.

Control Objectives PCI DSS Requirements
Build and Maintain a Secure Network 1. Install and maintain a firewall configuration to protect cardholder data

2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data 3. Protect stored cardholder data

4. Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program 5. Use and regularly update anti-virus software on all systems commonly affected by malware

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures 7. Restrict access to cardholder data by business need-to-know

8. Assign a unique ID to each person with computer access

9. Restrict physical access to cardholder data

Regularly Monitor and Test Networks 10. Track and monitor all access to network resources and cardholder data

11. Regularly test security systems and processes

Maintain an Information Security Policy 12. Maintain a policy that addresses information security

Eligibility for PA-DSS Validation:

Applications won’t be considered for PA-DSS Validation, if the ANY of the following point is “TRUE”:

  1. Application is released in beta version.
  2. Application handle cardholder data, but the application itself does not facilitate authorization or settlement.
  3. Application facilitates authorization or settlement, but has no access to cardholder data or sensitive authentication data.
  4. Application require source code customization or significant configuration by the customer (as opposed to being sold and installed “off the shelf”) such that the changes impact one or more PA-DSS requirements.
  5. Application a back-office system that stores cardholder data but does not facilitate authorization or settlement of credit card transactions. For example:
    • Reporting and CRM
    • Rewards or fraud scoring
  6. The application developed in-house and only used by the company that developed the application.
  7. The application developed and sold to a single customer for the sole use of that customer.
  8. The application function as a shared library (such as a DLL) that must be implemented with another software component in order to function, but that is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software components.
  9. The application function as a shared library (such as a DLL) that must be implemented with another software component in order to function, but that is not bundled (that is, sold, licensed and/or distributed as a single package) with the supporting software components.
  10. The application a single module that is not submitted as part of a suite, and that does not facilitate authorization or settlement on its own.
  11. The application offered only as software as a service (SAAS) that is not sold, distributed, or licensed to third parties.
  12. The application an operating system, database or platform; even one that may store, process, or transmit cardholder data.
  13. The application operates on any consumer electronic handheld device (e.g., smart phone, tablet or PDA) that is not solely dedicated to payment acceptance for transaction processing.

For custom software development projects, “Requirement 6: Develop and maintain secure systems and applications” section is more applicable and needs to be taken care while doing the system design and in coding.

PCI Compliance Introduction

The Payment Card Industry (PCI) has developed security standards for handling cardholder information in a published standard called the PCI-DSS Data Security Standard (DSS). The security requirements defined in the DSS apply to all members, merchants, and service providers that store, process or transmit cardholder data.

The PCI-DSS requirements apply to all system components within the payment application environment which is defined as any network device, host, or application included in, or connected to, a network segment where cardholder data is stored, processed or transmitted.

The purpose of this document is to guide help software development of project which require PCI-DSS compliance implementation.

This document also explains the Payment Card Industry (PCI) initiative and the Payment Application Data Security Standard (PA-DSS) guidelines. The document then provides specific installation, configuration, and on-going management best practices for PA-DSS Certified application operating in a PCI-DSS compliant environment.

Difference between PCI-DSS Compliance and PA-DSS Validation:

As a software vendor, our responsibility is to ensure that our solution does conform to industry best practices when handling, managing and storing payment related information.

PA-DSS is the standard against which Solutions has been tested, assessed, and certified.

PCI-DSS Compliance is then later obtained by the merchant, and is an assessment of end-client’s actual server (or hosting) environment.

Obtaining “PCI-DSS Compliance” is the responsibility of the merchant and client’s hosting provider, working together, using PCI-DSS compliant server architecture with proper hardware & software configurations and access control procedures.

The PA-DSS Certification is intended to ensure that the solutions will help you achieve and maintain PCI-DSS Compliance with respect to how solutions handles user accounts, passwords, encryption, and other payment data related information.

PCI Security Standards Council Reference Documents:

The following documents provide additional detail surrounding the PCI SSC and related security programs (PA-DSS, PCI-DSS)