PCI DSS Compliance (Part 1)

 

If you would like to read the next part in this article series please go to PCI DSS Compliance (Part 2)

In a recent survey performed by a leading PCI website it was found that the main reason for becoming PCI compliant was to meet industry standards, the second biggest driver was because the compliance was required by the credit card processor, the third reason was to secure the network. The data speaks for itself; organisations are securing themselves because they have to, not because they want to.

As a credit card user PCI DSS is good news as the standard introduces a higher level of security to the credit card industry.

The following is a list of requirements that the PCI DSS standard set out for audit purposes.

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data.
This requirement is elaborated on later in the standard and points to the need for an application firewall, like ISA. Without such firewalls, session layer attacks are possible and new age, next generation code can be run against websites and systems that cannot be protected by weaker solutions. From a customer’s perspective this is key, as application layer firewalls make it a lot more difficult to compromise a hosted environment. The age of the application layer firewall is here. The protection of credit card data is vital in this standard; isolating the environment that stores credit card data is a good option, as it may negate the need to implement stringent security techniques throughout the entire network.

Documentation

The standard seeks to identify key change control procedures that log changes to the firewalls that guard the network that hosts the credit card data. My recommendation is to keep the credit card data system separate from the internal production network. Other documents like network diagrams need to be produced and maintained. If the firewall is used for internet access by the organisation the outbound and inbound ports need to be justified. This helps the organisation to think about why the ports are opened but some dangerous ports are not reported on. In the audits I perform I highly recommend that all outbound ports are blocked and that only the service ports, like port 80, are opened for the web service. A reverse proxy solution like the one offered by Microsoft ISA is an ideal solution in this case. In this way the IIS port is not exposed directly to the Internet.

Exposure of credit card data also needs to be closely managed and the standard seeks to highlight that the credit card data should not be exposed to the open Internet at any time. When reviewing existing credit card storage software for a large utility company in the region I consult in, it was found that all the credit card data was not stored in an encrypted form and that if a user knew where to look, details could be downloaded on the LAN or remotely though a website. This should not happen in any circumstance and by isolating the Credit card data, encrypting it, and applying strong access control solutions to the database all was secured efficiently.

Other networks

To avoid complications and extensive security work it is highly recommended that the system holding the credit card details not be connected to any other network, including a wireless network. Strong hardening techniques should be applied to systems that hold sensitive client information and additional services and protocols should be removed from the machine housing he sensitive data as to better secure the environment.

Any client machine that does connect to the now secured network should have a host based firewall, or personal firewall as to prevent infection or compromise once off the secure network, or when roaming.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
This requirement is a no-brainer, but you will be surprised how many organisations fail this simple task and worse still how many third party service providers install and manage solutions with default passwords. Step one is to always change the default credentials, these credentials should be stored in an encrypted state and only authorised personnel should have access to this information. A recent audit I performed revealed that over 60% of the organisations have default passwords on network critical equipment.

Real data

In a recent audit performed on wireless networks 1,300 wireless access points were found in half an hour, 400+ of these had the default insecure security settings and were exploitable. More than 18 of these were confirmed to be connected to well known commercial organisations that had some valuable data stored on their network.

Harden everything, TCB included

TCB, Trusted Computing Base, is what it’s all about! The TCB is all the hardware, software and firmware. This in turn means all the operating systems, applications, and firmware and hardware components. Operating systems and applications typically get addressed by auto update software like WSUS. Again it is surprising how many organisations do not take this seriously and have not updated their solutions since installation. Typically software and applications are updated. The real problem in 80%+ of environments is the firmware, once installed the firmware based products are left to run for years to come and are often neglected and never updated. Hackers know this and it is one of their first attack points.

A further point that the standard makes that is typical of neglect and yet many organisations still have to implement is… encrypting administrative access to the environment especially remote administrative access. Technology like IPSec, SSTP, SSL, SSH, SSL/TLS help in keeping the connection secure.

Protect Cardholder Data

Requirement 3: Protect stored cardholder data.
This requirement defines how stored card holder information should be stored. To keep data confidential encryption must be used; my recommendation is the moment any data is recorded it should be recorded in an encrypted state and stored in an encrypted form. Technical access control solutions help in securing these credentials. The standard clearly states “NEVER store the card verification code or value or PIN verification value data elements,” again this is what is stated but in my experience not what is practised.

Sensitive authentication data must not be stored, this includes a copy of the magnetic stripe, or chip information or elsewhere. To reduce the risk to the customer only the minimum information required to conduct business needs to be used and stored. If data is stored, it must be in an encrypted form and any readable form of the data must be masked, for example 5412**************1345. Something I have noticed that will need to be changed is that, information is now being displayed in this way but when the batch is transmitted to the bank or card processor site the information is sent in an unmasked state.

Requirement 4: Encrypt transmission of cardholder data across open, public networks.
This requirement follows on from my previous finding and is very necessary in today’s trading environment as organisations trade in a virtual realm real-time. The standard is very clear in how the encryption needs to be managed and how the encryption keys need to be generated, distributed, secured, stored, replaced, exchanged and disposed of. For more information on this topic I have written an article on encryption key management, there are out-sourced services that mange the key information for you and these come very highly recommended to avoid sticky situations.

In the part two of this series we will cover the following requirements.

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software

Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

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

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

Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

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

Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

Summary

For too long have customers had their details compromised, this standard is long overdue and now with the standard becoming a requirement by most credit card processors and banks, vendors have little choice but to implement stringent security solutions that they should have been using. Consumers are now starting to get the protection required because of this standard.

If you would like to read the next part in this article series please go to PCI DSS Compliance (Part 2)

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top