Any company that accepts credit cards for its business is subject to the Payment Card Industry Data Security Standard (PCI DSS). As it is with other regulations, such as the Sarbanes-Oxley Act,the biggest component of being compliant is proving you're compliant.
Though PCI is an industry standard -- not a government regulation -- it can still be enforced with equal weight as a regulation by the credit card industry. The PCI Security Standards Council LLC is governed by the five largest credit card companies: Visa International, MasterCard International Inc., American Express Co., Discover Financial Services LLC and JCB Co.
While it's unlikely a credit card company would make the effort to catch a midmarket company in the act, it can cut a business off at the knees for noncompliance. A business can be fined, or worse -- cut off completely from being able to process credit cards.
Better to have and not need, than to need and not have.
A PCI audit is something you can do without hiring an outside consultant. Your secret weapon: Documentation.
Auditors have a mystical attachment to paperwork, and if it isn't in writing in front of them, they won't see it. The only way to prove to an auditor that your company is compliant with PCI is to document every control required by the standard. In the eyes of the auditor, if a control isn't documented, it isn't compliant.
First, appoint someone to be the contact person for PCI auditors. This isn't a full-time job and doesn't necessarily even have to be someone from the IT department. The important thing is that this person has a suff...
To continue reading for free, register below or login
To read more you must become a member of SearchCIO-Midmarket.com
icient background in IT and understands the technical terminology in the standard.
Next, go to the PCI Security Standards Council website and download three documents: the standard requirements, the self-assessment questionnaire and the security audit procedures.
PCI defines four levels of merchants. Any merchant processing fewer than 6 million transactions annually falls into the lowest three categories (levels two, three and four). Only level-one merchants are required to have an on-site audits. All the others, which include the majority of midmarket companies, can complete the self-assessment questionnaire annually on their own.
The standard documentation is to be used as a guide and final reference to how you fill out the questionnaire. The questionnaire is a series of check boxes that you must fill out and have on hand if the credit card companies come calling. The security audit procedure is a 50-page manual that instructs you on what do to and how to do it.
Going through these three documents thoroughly, checking off each item and providing documentation for each item will soothe even the most aggressive auditors.
There are 12 overarching requirements you will have to meet when filling out the documentation. Some of the requirements are no-brainers. But there are some that might need some explanation:
Requirement: Install and maintain firewalls. Make sure to have a network diagram documenting all connections to cardholder data. Also, make sure to have a firewall configuration standard that outlines all users and groups with firewall access, all services and ports open on the firewall and justification for the use of protocols other than HTTP, such as FTP, SSL, SSH and VPN.
Requirement: Protect cardholder data. This is one of the most difficult requirements for midmarket companies to meet. Here, make sure to have a written policy describing data retention and disposal policies and procedures. This should include how long data is held, for what purpose and how often it's disposed of.
Another pain point here is encryption of cardholder data. Be able to produce documentation describing encryption methods and systems with the names of algorithms and their bit strengths.
Requirement: Develop and maintain secure systems and applications. Keep lists of security patches installed on systems and be able to show they are current with the patches issued by vendors. Be able to document software development practices and prove that they include security reviews during the development lifecycle.
Requirement: Restrict access to cardholder data. Be ready to produce a written policy showing that access to systems is based on the principle of least privilege and that there are systems in place for auditing provisioning of user access.
Requirement: Require users to have unique IDs to access the system. Documentation should be available describing authentication methods. Auditors may even ask for verification of all user IDs to make sure they're unique and have the appropriate level of privileges.
Requirement: Track and monitor access to networks and cardholder data. The requirement states that audit trails be turned on for network systems. Be able to produce copies of these trails for auditors.
Requirement: Schedule quarterly security scans by an outside vendor. This is a cornerstone of PCI. These vendors, called approved scanning vendors by the PCI council, conduct vulnerability assessments. Have copies of the last four assessments available for review by auditors.
Requirement: Maintain an information security policy. The policy should define responsibilities for employees and contractors. Also, make sure to have documentation of a security awareness program and an incident response plan.
Note that if you outsource any functions, such as processing and transmission of card data, you should identify those specific functions and who is handling them. Those vendors will be responsible for their own PCI compliance.
Ultimately, the key to PCI audits for companies of any size is to have documentation available of processes, policies and procedures. So, when auditors call, make sure to have your documentation in order.
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP specializing in Web and application security, and is the author of The Little Black Book of Computer Security, available from Amazon.com. He has a regular radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at www.theitsecurityguy.com.
