Taking the IT out of Security
Implementing PCI DSS v1.2 - the Vendor Independent way
INTRODUCTION
The PCI DSS is a broad standard which aims to put effective human and technological controls in place to mitigate the risk of dealing with sensitive payment card data. Such data is considered 'cash'. You wouldn't leave cash lying around and likewise you shouldn't leave card data lying around. Lock it away, protect it and make sure only authorised personnel can access it.
The standard is split into 251 controls. Each has an equal weighting and is spread across 6 major sections. It is important to maintain a high level approach as quite often a single solution can address multiple controls (usually in disparate sections). Each control addresses a risk and it's also important to understand what that risk is and how exposed you are before putting mitigation into place. A section summary follows:
PCI 1,2: BUILD AND MAINTAIN A SECURE NETWORK
PCI DSS requires a secure perimeter around your payment network and an additional perimeter (DMZ) around servers that store cardholder information. Keeping these perimeters as tight as possible ensures that minimal assets fall into scope. A smaller scope means a smaller cost. Shared firewalls, VLANs, router/switch based firewalls and host-based firewalls (including the default Windows firewall) are all acceptable means of segregation and this section can typically be addressed without any capital expenditure.
PCI 3,4: PROTECT CARDHOLDER DATA
There are a number of solutions out there that all claim to address encryption for the PCI DSS - RSA, Ingrian, Safenet, nCipher, Protegrity and various Open Source PKCS APIs. There are two key things to bear in mind:
» Whatever encryption you use is redundant if you don't manage the encryption keys properly
» Most databases already support encryption - you don't have to buy additional solutions
The risks PCI Section 3 attempts to address are that of physical theft and unauthorized access. Encryption renders data useless to both thieves and nosey DBAs.
Microsoft SQL Server, Oracle and DB/2 all support encryption natively. Chances are you're using one of these systems and you can address encryption without further expenditure. A key management process is a must, but you don't need a Hardware Security Module (HSM) for PCI DSS. A simple process is more than effective, as is the storage of data encryption keys on USB fobs or other removable media (as long as they're encrypted).
PCI 5,6: MAINTAIN A VULNERABILITY MANAGEMENT PROGRAM
All software is at risk of becoming compromised at one stage in it's lifecycle, be it fault of the application, fault of the operating system, or fault of another application that inadvertently dumps malicious code into your memory space.
By far the best means to combat vulnerabilities is to address at source and ensure security is built in to the Software Development Life Cycle (SDLC). The OWASP Testing Guide v3 is the most recent guide in the community and comes highly recommended.
If time-constrained, Web Application Firewalls (WAFs) can provide temporary protection, but code issues should always be addressed at source. That way, developers are less likely to make the same error twice. WAFs do have value, but why complicate your network if the problems can be fixed at source? If you can carry out all testing in house and ensure your developers are security savvy, then no expenditure required.
PCI 7,8,9: IMPLEMENT STRONG ACCESS CONTROL MEASURES
Should the guys in the mail room have access to your card holder database? Hopefully not. Access control is a broad topic, that covers physical security and CCTV through to employment contracts defining data access/destruction policies. Technology plays an important part, but there's a lot more to access control than just Active Directory and NTFS. Card data should be masked or removed wherever possible and there really shouldn't be any business reason why more than one or two people in your organisation need to actually see it. Policies and procedures are very good at addressing Access Control, but additional hardware doesn't help as you need additional policies and procedures and a different set of user accounts to manage it.
PCI 10/11: REGULARLY MONITOR AND TEST NETWORKS
Security Monitoring
Security controls must be monitored and tested in order to remain effective. An independent audit trail must also be kept to ensure logfile integrity in the case of system compromise. Collecting logfiles is usually quite trivial (ie setting up a SYSLOG server), but trawling through millions of events is certainly not. On larger networks some means of correlation and analysis is typically needed. Head toward Splunk for both your Event Logging needs. As long as your event data does not exceed 500Mb daily, the product does not require a license.
Intrusion Detection and Intrusion Prevention Systems (IDS/IPS) are required wherever a perimeter is present. If you combine IDS/IPS with your segmentation project, you'll save time and money. IDS/IPS is bundled into pretty much every firewall on the market now. You don't need a separate device for PCI DSS and shared solutions are more than acceptable.
File integrity monitoring (FIM) is often overstated. Tripwire even got a mention in PCI DSS v1.0, which helped them make a lot of money. A simple comparative MD5 checksum of critical system files on a weekly basis is more than adequate to meet this requirement. Microsoft even give you a free tool to do this. FIM is usually bundled in with another product (eg event logging solution like Splunk or anti-virus), so address this control holistically and do NOT break it out into a separate project as money will be wasted.
Security Testing
Vulnerability scans are not rocket science. Pick a scanner (Qualys, Nessus, eEye, RandomStorm, Secunia etc). Use it. Patch what it finds! Tim would be happy to come and do this for you, but the real legwork is interpreting results and implementing patches without causing downtime or unpredicatable system results. Tune your scanner to reduce false positives, ensure you have a testing environment and do not roll untested patches out to a live environment. Even Tim has no idea if a patch will break your systems.
Tim has used a range of tools for penetration tests (Rational AppScan, WebInspect, ExploitMe, BurpSuite, GrendelScan, Firebug and pretty much everything and anything from OWASP). The automated testing component is straightforward, but the interpretation does require skill. If AppScan finds a critical coding flaw in an application, should the customer pull out all stops to fix it? Is payment card data at risk? A healthy dose of practicality is a must. If in doubt, conduct a Risk Assessment to determine business impact.
Unfortunately for PCI DSS, the Penetration Test industry is COMPLETELY unregulated. Testing reports from other suppliers vary hugely in quality and worryingly, certain results do not appear reproducible. Many organisations use their QSA to run penetration tests but this can provide a false sense of security as most are typically not up to scratch. Tim would recommend organisations conduct their own penetration tests - in time of economic recession companies should certainly look at turning investment inward and nominating an Application Security Specialist within your organisation will help improve your security posture.
PCI 12: MAINTAIN AND INFORMATION SECURITY POLICY (ISP)
Devloping an ISP is not always easy. Many clients have come to Tim with policies that do not meet the requirement. SANS is a good place to start, but please don't just download their templates and swap the names over - it doesn't work! An ISP is the evolving result of a Risk Assessment process. It must be practical, workable and evidence seen in the form of defined written procedures and working processes. An ISP is not there to give your organisation a tick in the box for compliance. It's there to tell you and your staff HOW to meet compliance and has tentacles reaching into all parts of your organisation (the board, human resources, network team, server team, 3rd parties, legal team).
THE NEXT STEPS
If your company has been informed by your acquiring bank, card scheme or service provider that you may be subject to PCI DSS compliance, then this problem will not go away and the following steps are suggested:
» Take immediate steps to identify where card holder data is stored, processed and transmitted in your organisation
» Pay attention to 3rd parties, paper records and backup tapes
» Create an up to date network diagram and detailed asset list
» Engage an independent QSA early on if you have the slightest doubt (most will provide a free first hour)
» Divert vendor calls to voicemail. More often than not, controls can be addressed without buying anything and complicating your infrastructure with additional 'solutions'.
» Last, but not least, you have a business to run and compensating controls can often be used if the expense of implementing controls has a measurable impact on your business
If you need a helping hand, please feel to get in touch using the Contact link above