PCI DSS Compliance (Part 2)

If you missed the previous article in this series please read PCI DSS Compliance (Part 1).

$33.9 billion worth of ecommerce transactions were made in Quarter 4 of 2006, with a quarter of this revenue attributed to fraud. The most common form of identity fraud for 2007 is credit card identity theft. In part two of the PCI DSS series we will cover, maintaining a vulnerability management program, implementing strong access control measures and maintaining an information security policy.

Who needs to do what?

* Most level 2 and level 3 merchants will not meet the Dec 07 deadline… Level 4 merchants that I have consulted are already in breach of the July 07 validation deadline… So what now? Banks have confirmed that the PCI DSS is a requirement and that if non-compliance persists, repercussions will follow…

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update antivirus software

Updating and using antivirus may sound like the defacto standard, however I still find that many organisations either do not have antivirus or have not implemented the antivirus in the correct way. The organisations in question typically have poor update strategies and or misconfigured antivirus that because of bad configuration does not update or alert the respective support personnel if an update does not take place. A good antivirus is not as effective as an updated antivirus.

Requirement 6: Develop and maintain secure systems and applications

Many exploits occur because of software not being patched or updated. Most of the time security updates are a result of poor software design and or poor coding practice. Furthermore when software is patched, seldom are the patches tested. The result could be downtime or unwanted feature changes that impede the delivery of the application. Deploying and maintaining secure applications, involves testing the updates in test environments and applying these to the production environment only until the functionality and performance have been tested thoroughly.

Proper development of applications and following the Software Development Lifecycle is not only best practice but now a requirement of the PCI DSS. Included in this is the separation of the development and live environment. Without this the solution can go horribly wrong and problems can occur whenever changes are made to the application. Before the solution goes live all residual credentials like, usernames and other identification needs to be removed so that the live application does not contain sensitive information. This sanitisation component, if forgotten, can result in a system compromise that will allow for the attacker to elevate their privileges and will potentially expose the system user details.

Change control

If you cannot measure you cannot manage; how do you know where the problems originated if there are no details on what changes have taken place when updating the software? If you have to reverse the update there is no way of telling which of the 101 updates caused the problem.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know

This requirement aims to enforce the need to know or least privilege security canon. The reason for this is because only authorised personnel should have access to sensitive data protected by PCI DSS. The best way to do this is the Deny all, white list approach. How do you do this? Start by revoking all privileges in a controlled way and only allowing access to the resources and data as required by authorised personnel. This access control can be documented to establish an ACL that is maintained and monitored by environmental systems controls. Easier said than done… More information about Deny All here.

Requirement 8: Assign a unique ID to each person with computer access

The eighth requirement is to assign unique IDs to each person that will access the sensitive data. This requirement forms part of the non-repudiation and adaptability component of the standard and is in place to help solve problems that occur when multiple users access the same resources with the same credentials. Two factor authentication is a requirement and needs to be implemented to counter weak access control like passwords. Solutions that implement strong authentication are useful when identifying who accessed the system and when and invariably without a doubt you are able to tell who accessed the environment.

Remote access attracts a more secure authentication mechanism leveraging technologies like RADIUS, and TACACS+. Again, encryption plays a role and all credentials need to stay encrypted, especially during transmission.  Strict password management will help with PCI compliance. Best practice around passwords are a must in this requirement segment. More information about two factor authentication here. 

Requirement 9: Restrict physical access to cardholder data

In this requirement there is need for technical controls and physical controls that restrict access to card holder information. To help reduce security vulnerabilities, process the card information in a secure environment and store the details securely. If this is not an option many physical technical controls will need to be applied. Data classification and physically secured paper records fall under this requirement.

Requirement 9 requires extensive physical security as customer details are at risk. These are all necessary and missing one of these controls may result in the card details being disclosed to unauthorised personnel.

Disposal of card material is also important, attacks like dumpster diving are not uncommon and for this reason physical destruction of card details is important.

Requirement 10: Track and monitor all access to network resources and cardholder data

Auditing and logging are key components of PCI compliance. It helps in proving what user accessed the credit card data and if unauthorised users are attempting unauthorised access. Monitoring and auditing access to card information is a requirement that logs: date, time, access, success, failure and log access. More detailed variables that need to be monitored can be found in the standard. Typically I recommend that access to the information is proxied though an application layer firewall.

Requirement 11: Regularly test security systems and processes

To regularly test systems for vulnerabilities is part of the PCI standard. This is why the PCI compliance team have made it a prerequisite that periodic scans are performed on the networks that house card information.

The bare minimum for a penetration test is once every year, quarterly scans must be performed by vendors qualified by the PCI. The use of IDS to detect threats and vulnerable systems helps in the prevention of exploits. IDS use pattern files to keep current and this is a requirement of PCI. The use of file integrity verification software will help insure that the files have not been changed.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

The last requirement of the PCI DSS is maintaining a security policy. A policy without teeth is useless and the security policy must be able to address all of the requirements set out in the PCI DSS.

Following best practice and keeping within the guidelines in the ISO 17799 now known as the ISO 27001 will help in keeping within the PCI DSS. The twelfth requirement has many in-depth requirements and because of its extensive nature it is best to refer to the PCI DSS itself.

In summary this series of documents should serve as a guide to help you and your organisation decide on how to comply with PCI DSS. The standard has been designed to protect both consumers and the organisations that hold card information from losing billions of dollars yearly. In short, the PCI standard helps organisations become more secure, it should not be the only reason to implement an appropriate security solution.

If you missed the previous article in this series please read PCI DSS Compliance (Part 1).