Home > blog > castlin > 2009 > 11

Slouching towards PCI Compliance

November 19th, 2009
in

I'm starting work to bring a drupal site towards PCI compliance and I thought it might prove handy to document it.

Sadly, I must work towards Self-Assessment Questionnaire D, which is not short. This post is going to focus on Requirement 8: Assign a unique ID to each person with computer access.

  1. Assign a unique ID to each person with computer access
    1. Are all users assigned a unique ID before allowing them to access system components or cardholder data? - Handled through core roles.
    2. In addition to assigning a unique ID, is one or more of the following methods employed to authenticate all users?
      • Password or passphrase
      • Two-factor authentication (for example, token devices, smart cards, biometrics, or public keys)

      - core passwords seem sufficient, but see the md5 concerns below.

    3. Is two-factor authentication incorporated for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties?

      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. - core authentication over forced SSL. for this site, everything runs in SSL which is accomplished in .htaccess via mod_rewrite

    4. Are all passwords rendered unreadable during transmission and storage on all system components using strong cryptography (defined in PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms)? - transmission is over SSL. storage is looking problematic since D6 core does MD5 hashes instead of SHA1 and overriding it doesn't look trivial.
    5. Are proper user authentication and password management controls in place for non-consumer users and administrators on all system components, as follows?
      1. Are addition, deletion, and modification of user IDs, credentials, and other identifier objects controlled? - yes, via core
      2. Is user identity verified before performing password resets? - via emailed reset link in core
      3. Are first-time passwords set to a unique value for each user and must each user change their password immediately after the first use? - well, right now we only have 2 user accounts, and they've already logged in. so i'm not sure if this applies in our situation.
      4. Is access for any terminated users immediately revoked? - this is administrative, but easy to do (just block the user account).
      5. Are inactive user accounts removed or disabled at least every 90 days? - again, with 2 users, i'm not looking into an automated way to do this, but i imagine it could be automated via hook_cron() pretty easily.
      6. Are accounts used by vendors for remote maintenance enabled only during the time period needed? - N/A for this project, but could be handled administratively.
      7. Are password procedures and policies communicated to all users who have access to cardholder data? - managerial, but yes
      8. Are group, shared, or generic accounts and passwords prohibited? - i'm not sure how this would be coded against, but policy states that they are.
      9. Must user passwords be changed at least every 90 days? - This, and several others below, are accomplished by use of the lifesaving Password policy module. My only wish is for the capacity to import/export policies.
        Password Expiration = 90
      10. Is a minimum password length of at least seven characters required? - Password Policy: Length = 7
      11. Must passwords contain both numeric and alphabetic characters? - Password Policy: Digit = 1, Letter =1
      12. Must an individual submit a new password that is different from any of the last four passwords he or she has used? - Password Policy: History = 4. This was a great relief to see in the module.
      13. Are repeated access attempts limited by locking out the user ID after no more than six attempts? - Here we turn to the Login Security Module. Set "Maximum number of login failures before blocking a user:" = 6.
      14. Is the lockout duration set to a minimum of 30 minutes or until administrator enables the user ID? - Left Login Security's "Track Time" at 1 hour.
      15. If a session has been idle for more than 15 minutes, must the user re-enter the password to re-activate the terminal? - Ye Olde Automated Logout module, 900 seconds at /admin/user/settings.
      16. Is all access to any database containing cardholder data authenticated? (This includes access by applications, administrators, and all other users.) - yes, it is all being controlled through core's menu system, and general DB security.

So the outstanding problems are with md5 storage of passwords and finding out if initial login stuff applies to our situation. Password policy was an amazing help and tackled several of these points in one configuration screen.

Throwing Password change confirm in for good measure.