PCI-DSS – It’s not rocket science.

PCI-DSS – It’s not rocket science.

 

For nearly two years, I worked on a PCI-DSS project for one of the worlds most recognisable brands.

What is PCI-DSS?

PCI-DSS is a mandatory compliance standard for all companies, who process, store or transmit payment card information.

There is a sliding scale of compliance and reporting of compliance is primarily based on the number of credit card transactions completed in a year.

See https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml for further details.

My Experience

Within days of starting the PCI-DSS project it soon became apparent to me and the rest of the project team, that what the standard was asking for was indeed not rocket science – but a series of best practices that in reality – you should be doing anyway.

Scope

Before you go off and spend thousands of £’s $’s or €’s to become compliant – take a step back and look at your scope of compliance, what do I mean by that?

If you have 10000 PC’s in your environment, but only 500 process credit card information – then that’s your target for compliance – making 500 PC’s compliant not 10000 as this would potentially have huge cost implications and huge management overheads.

The rule that our QSA gave us to work with for our audit was:

Any PC or server that processes card holder data; stores card holder data; or can access (or influence access) to card holder data is in scope.

If the network is encrypted then that is out of scope – if no encryption is present then the network is in scope.

Once you have the scope – speak to your QSA and have the scope ratified, agreed and signed off.

It is worth noting that at this stage – be totally honest with your QSA and do not try to hide anything under the carpet; as if there is a payment card security breach within your organisation, the kept secret may just be the cause of the breach and the ultimate punishment for a breach is that the ability to process payment cards of any type can is withdrawn.

Translating the rules into plain English and from an infrastructure prospective (summarised and not exhaustive)

Requirement 1: Install and maintain a firewall configuration to protect cardholder data

Document all firewall rules
Diagram all network flows
Remove any legacy rules
Justify all rules in the firewall
Review all firewall rules every six months
Segment the network (if possible)
Secure all router configuration files
All firewalls must be stateful packet inspection firewalls
Implement or confirm a rigid change control process for any new rules or when modifying existing rules

There are other considerations but it depends where your cardholder data is located.

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

Reset all vendor supplied defaults including passwords on all servers, applications, operating systems, networking equipment (SNMP) etc
Implement configuration hardening standards (such as CIS – Center for Internet Security)
Implement only one primary function per server (excludes virtualisation and Active Directory integrated DNS)

Requirement 3: Protect stored cardholder data

Encrypt all stored card holder data
Permission data so that access is only given to people or applications that need access
Develop data retention standards
Do NOT store sensitive authentication data after authorisation (even if encrypted)
Mask PAN when the number is displayed

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Encrypt the network or encrypt the data as it ‘travels’ over the network
Wireless networks have been banned from transmitting credit card data over WEP encrypted networks since 31st March 2009

Requirement 5: Use and regularly update anti-virus software

Have a valid anti-virus application installed on all systems in scope
Ensure the anti-virus can be updated on demand
Ensure the anti-virus can provide audit logs
Ensure your anti-virus also include a HIPS firewall   

Requirement 6: Develop and maintain secure systems and applications

Apply all security patches regularly and within 3 months of release (on a priority basis)
Establish a process to identify all new vulnerabilities
Test all vulnerability patched before application

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

Ensure only personnel who need to access the data can. Through for example file permissioning or two factor authentication
Ensure the default access to credit card holder data is set to “deny all”

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

Remove all generic logons, ensuring all personnel use names or personably identifiable accounts
Ensure that two factor authentication is utilised for remote access
Ensure you have a compliant password policy
Ensure you have a compliant leavers and joiners policy

Requirement 9: Restrict physical access to cardholder data

Implement or validate security cameras on all servers in scope
Implement a guest register in the equipment rooms in scope
Ensure no PC’s in scope are in an area accessible to the general public
Restrict access to publicly accessible network points
Ensure all visitors to locations with equipment in scope are easily identifiable from employees
Securely store all backups, offsite if possible
Classify all backup media – so card holder data can be identified as confidential

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

Implement audit logging to a secured and centralised log server so that all systems can be analysed in the event of a security breach
Ensure the required minimum is actually logged
Synchronise time across all systems
Use file integrity monitoring or change detection software on all systems in scope

Requirement 11: Regularly test security systems and processes

Scan for wireless networks regularly
Run internal and external vulnerability scans at least quarterly and after significant network changes or application modifications
Run internal and external penetration tests at least once a year and after significant network changes or application modifications
Use IPS or IDS to monitor all traffic in the cardholder data environment
Use file integrity monitoring or change detection software on all systems in scope

Requirement 12: Maintain a policy that addresses information security

Maintain and publish an Information Security policy for your organisation – Review at least annually or after significant network changes or application modifications
Maintain and publish an acceptable use policy and ensure all personnel are aware of the policy and have signed up to it
Develop daily operational procedures to review log files, IDS/IPS out put on a daily basis
Label all equipment
Develop a software catalogue of approved applications
Develop an incident response team to respond to a system breach and test annually
Develop a program to monitor your service providers PCI-DSS status (if they are not compliant, you are not compliant)

In a nutshell, that’s it  – if you complete or have completed these tasks, you will be well on the road to PCI-DSS compliance, of course this is only the beginning, as once you are compliant you have to stay compliant and that’s when the fun really starts.

2 thoughts on “PCI-DSS – It’s not rocket science.

  1. There you have it. An internally inconsistent grab bag of tech buzzwords being called a standard, and a bunch of “certified” assessors using their “common sense” to interpret it.

    Where is the appendix to the DSS with the formal proof that it even works, if somehow implemented?

    The elephant in the room is that compliance by pros is impossible due to its complexity and its susceptibility to simple human error, compliance by mainstream companies is impossible due to the technical level of knowledge required to motivate compliance and the labor shortage. Compliance by individual companies is impossible due to the simple shortage of hours in the day.

    If RSA, Sony, Twitter, LinkedIn, and many other large companies specializing in technology and security can’t successfully protect their networks, what kind of arrogance leads PCI to think its rule dissemination provides even a shred of security to the credit card holder?

    I suggest stepping back yet another step and asking “why should merchants ever have, process, or store any key authorizing access to customer assets?”

    Ordinary humans should be able to lock their doors without calling a locksmith. So, as far as I’m concerned, the credit card issuers and the Congress that gave them a total ‘bye need to go all the way back to the drawing board.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s