Well, as we hinted, it is a baseline security standard designed to reduce the risk of credit card data theft. There are 12 requirements comprising over 240 individual controls. As we stated, you can’t be mostly compliant. It’s an all-or-nothing standard developed and maintained by the PCI Security Standards Council (www.pcisecuritystandards.org/index.shtml).
The 12 requirements of the standard are:
- Install and maintain a firewall configuration to protect cardholder data
- Do not use vendor-supplied defaults for system passwords and other security parameters
- Protect stored cardholder data
- Encrypt transmission of cardholder data across open, public networks
- Use and regularly update anti-virus software or programs
- Develop and maintain secure systems and applications
- Restrict access to cardholder data by business need to know
- Assign a unique ID to each person with computer access
- Restrict physical access to cardholder data
- Track and monitor all access to network resources and cardholder data
- Regularly test security systems and processes
- Maintain a policy that addresses information security for employees and contractors.
We’re sure you’ll agree that those are pretty sensible requirements, but don’t underestimate the PCI DSS. You may well be doing a lot of what is required, but the devil is in the detail. Arm yourself with the Council document entitled ‘Navigating PCI DSS – Understanding the Intent of the Requirements’ which can be downloaded at tinyurl.com/mv76cr. This additional guidance will help clarify each of the controls and what each control is meant to achieve.
Ultimately, if there is any doubt, the controls have one of two intents:
- Prevent inappropriate disclosure of cardholder data
- Detect when inappropriate disclosure occurs, allowing quick remediation.
Our first piece of advice regarding cardholder data (CHD) is "If you don’t need it, don’t store it!”. The more components that are in scope of your assessment, the more your compliance is going to cost. From the Standard: "The PCI DSS security requirements apply to all system components, defined as any network component, server, or application that is included in or connected to the CHD environment. The CHD environment is that part of the network that possesses cardholder or sensitive
authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time (NTP), and domain name (DNS). Applications include all purchased and custom applications, including internal and external (Internet) applications.”
One of the easiest ways to limit your PCI compliance cost is to limit the systems and components that ‘touch’ CHD. In the course of our business, we have come across many companies that store years of data. Someone at some point thought it was necessary, but if you start asking tough questions like "Are you willing to pay for the compliance?” you will more than likely find out that not all the data is needed.
If you do need CHD, can your business process survive with a truncated number such as 4123 45xx xxxx 2345? This is no longer considered to be CHD and is out of scope of your assessment. In addition, all the systems and components linked to where the truncated numbers are stored may also be out of scope.
The second piece of advice is to draw yourself a high-level diagram of where all the CHD in your business exists. If you don’t know where the data is, how would you even start to reduce the scope? Without fail, CHD gets everywhere: email, fax, call recordings, spread sheets, scanned documents, paper statements, paper forms, databases, computer logs, backups…
Next month we will briefly discuss the ‘Prioritised Approach’: the grey areas of the Standard and the controls that are likely to be costly to implement.