Audit Serve, Inc.

The Premier Audit, Security and Sarbanes-Oxley Consulting Company

  
            An Insider’s View on How to Become
                 Level 1 PCI Compliant   (Part 3 of 3)
                      By: Mitchell H. Levine, CISA - Audit Serve, Inc.

                                            

This is the third part of a three part article intended to provide insights on how to navigate through the PCI project components.

The PCI project is a costly undertaking for most organizations because it requires changes to an organization's system architecture and requires significant changes to the PCI inscope applications.  Unlike other standards, an organization needs to pass all 300+ testing requirements defined in the PCI standards in order to receive their PCI certification.  

Many organizations have designed their applications in which users connect via Telnet which is not allowed within PCI because passwords are sent over the network in clear text.  Organizations are forced to implement a SSH (Secure Shell) client instead which provides a secure encrypted communication between the Server and the user workstations.

The rollout of SSH is huge since all users which connect to inscope PCI applications needs to have the software loaded on their desktop along with the servers which host the inscope PCI application.  In addition, any host-to-host communications which involve inscope PCI applications would require all connecting hosts to have the SSH client loaded.  In addition, there maybe automated scripts executed in which connections occurs via telnet which would require the scripts to be rewritten to conform to the syntax used by the SSH software used.

Since Telnet would then be turned off on the PCI inscope servers, any user which does not connect via the SSH client will not be able to access the system.  In addition, the communication interchange with the newly deployed SSH client needs to be thoroughly tested to ensure that all messages are received by the user and they are able to perform all critical functions using the SSH client.  One of the common problems with the deployment of the SSH clients is the ability for users to receive messages that their passwords have expired and being able to change their passwords based on the newly deployed communication interchange.

The encryption of data at rest and while it is in transit are the most significant, difficult and time consuming requirements within PCI.  Organizations need to perform an end-to-end analysis of the data flow of their PCI  inscope data components to identify each system in which the PCI inscope data passes and the amount of time in which data is stored.  A case could be made with PCI QSA (Qualified Security Assessors) that if data is stored for a few hours and there are automated processes to delete the PCI inscope data, then the data does not need to be encrypted at rest.

It is important to understand the difference in PCI requirements between data which is transported and data which is stored. Within an organization's internal network there is not a requirement to encrypt the transmission using wither Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL).  This requirement is needed if an organization does not properly segment their network environment and for data interchanges with external organizations.  If FTP is used, the PCI transmission requirements applies when an external organizations push data to the PCI organization’s FTP server and when a PCI organization allows and external organization to fetch files from its FTP server.

Encrypting data at rest requires an analysis of the various alternatives for encrypting data.  OS level encryption is not a practical alternative based on the design of most applications and databases.  Therefore, most organizations are deploying encryption at the database level which is offered by most database vendors.  Database vendors offer the encryption of the entire database or at the field level. However, besides the performance impact and storage requirements for deploying encryption at the database level, there are significant number of application changes which need to be made to encrypt and decrypt the data.  When database encryption is deployed, the ability to perform adhoc queries will be prevented since PCI does not allow the distribution of private keys to individual users to decrypt data.  

An alternative to database level encryption is to deploy the database server on a separate SAN which has an encryption device sitting between the application server and the database server.  

The last PCI component in which there are unpublished alternatives for achieving PCI compliance is the need to have all external parties which handle an organization’s cardholder data to also become PCI compliant.  Since every organization is not willing to invest in a project to become PCI certified by a QSA, depending on the volume of credit card data the vendor handles, they could self certify themselves as a Level 4 vendor.  This would only require a Network Vulnerability scan to be run by a qualified vendor or an organization which uses a scanning tool which is PCI compliant.

________________ _________________________________________________________

Mitchell Levine is the founder of Audit Serve, Inc. Audit Serve performs PCI Assessment and Remediation Project Management consulting services. Audit Serve also conducts Integrated & IT Audits, SOX Control Design & Testing.    Email Mr. Levine at Levinemh@auditserve.com if you would like to discuss your organization's specific project requirements in order to establish a proposal of services.

Copyright  2008, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

This article appeared in a past issue of the Audit Vision E-Mail Newsletter.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.