PCI DSS Tips, by James DeLuccia IV

If you have not heard of PCI DSS you are either not involved with payment transactions, do not have any consumer facing outlets / websites, or have artfully avoided the general flurry of Federal and Industry activity last year. In short, PCI DSS stands for the Payment Card Industry Data Security Standard. The following entry represents some of the best ways to reduce the scope of the PCI Audit, limit data exposure, and minimize the impact to your business…

PCI is an association that represents and encompasses what was once VISA CISP, MasterCard SDP, now including the separate programs from American Express, JCB, and Discover. The intent of the standard is to provide compliance requirements that dictate how CardHolderData (CHD) should be protected in environments that store, process, or transmit this data. Unfortunately, if you have a flat network (30% of Merchants / Providers) or have grown through acquisitions (50% of the same group) then these systems are interconnected and likely not secured as well as they could be given the sensitive nature of the data.

In order to help organizations manage these extreme challenges I have compiled the following to ensure that, at least, the major PCI DSS violations are eliminated and the extent of the audit is reasonable and appropriate.

1. Network Segmentation – By far the best thing that could be done to limit the scope of any audit (PCI or otherwise). Please migrate all CHD devices to dedicated systems and secure this zone with firewalls. This segmentation should restrict only need-to-know personnel and limit all non-business essential traffic to and from the environment. Segmentation limits the scope of the audit for Merchants and Service Providers. This segmentation must be done so while respecting the other PCI requirements as listed on the PCI Audit procedures document. Segmentation may include a dedicated Check Point firewall with IP level permissions (addresses and protocols) and user access restrictions.

2. Separation of Duties – I mentioned this requirement above and it was a strong favorite for the number one slot. All privileges (into the CHD zone since we have appropriately limited the scope) must require approval and be documented. Those that have access should logon through a system that logs sufficient data to determine who, when, and what was done in the environment. By limiting access we reduce the number of procedures that must be in place, and hence the amount that must be audited. While whole books have been written on this topic, it is important to remember that no one person should be able to grant access, use access, and monitor / edit logs of access. Keep that rule in mind and the rest should fall into place.

3. Encryption – As simple as it sounds, encrypt the data when it is in motion and when it is at rest. Be aware of how programs error and the type of data included in the logs that follow a standard application / windows operating system crash. While encryption does not eliminate our need to destroy certain CHD, there is plenty of remaining data that must be protected. For situations where applications are processing the data in real-time, ATM networks, we must be sure that the data at rest is encrypted. For those instances where data is queued, encrypt it. For all other situations, put in sufficient compensating controls and the intent is addressed.

For each environment there is always additional customization that can and should be done to match the business. By remembering the intent of PCI DSS we can appropriately and adequately secure CHD. If you have additional tips, comments, or general questions please post them below. Depending on interest I will post more comprehensive PCI DSS tips. (Disclaimer: The numbers stated above are approximations based on my experience)

Best regards,

James

A Desert island and a Standard

My current conundrum that is keeping my productivity at an unacceptable level is on the recent trend of questions that clients are asking around standards, frameworks, and methodologies. Broadly my clients are seeking a swiss army knife document that provides all the answers for IT Controls / Risk Management / Compliance / and other such security concerns. Off the the cuff I am sure we would all say, "It Depends". This, of course, is worthless to anyone truly seeking an answer.

So, I pose the question to the world…with some conditions, of course.

"If you were stuck on a desert island and had to have one structured approach to managing risk at an organization, what would you want?"

James

If you were stuck on a desert island and had to have one structured approach to managing risk at an organization, what would you have in your sun burned hands. Of course, ignoring the complete absurdity of being without the “life line” known as a blackberry and the fact that even using smoke signals as a meaningful communication protocol will not provide sufficient response time to be a sufficient answer to this challenge.

So, without any means of outside communications and trying to not be blinded by the ball of fire above our heads (read: sun) that we haven’t seen in nearly a dozen years, what is the best approach? Of course, scope comes to mind and intent. I would propose that we only consider an enterprise that has to address multiple regulations (SOX, PCI) in the United States and a few international (Basel II, etc…).

Ok, so we have a pseudo company with pseudo requirements and a truly dire situation. If we focused on a broad framework perhaps we would choose ISO 17799. This one is a bit out of date, but does provide us some structure without any specifics. COSO is widely publicized and why not – it is only 14 years out of date! COBIT 4.0 is sufficiently thick to at least provide good fire starting materials, but is also the newest iteration of a broadly accepted framework. How about ITIL or is it ITEL? Then again the US government has done a fairly thorough, in verbose government fashion, publication series of NIST and FFIEC structures that cover nearly every Financial and government system. Alright so what do we choose? Today if I am looking for a structured standard that delineates a measurable improvement plan I would select COBIT 4.0. The clarity in 4.0 is unique across all the available standards as it is timely, quantitative and qualitative with the use of CMMi, and is specific enough to allow our enterprise to meet the requirements. Perhaps a giant discussion on this new standard is warranted? Another time…

Thoughts? Comments? Dissents?

James DeLuccia IV

Hello World, James DeLuccia IV

Ahh, blogs. Personal vents where casual conversations are captured and the running thoughts of individuals are recorded online, forever. First off, I am passionate about risk management, technology, business solutions, and have been consulting for the greater part of my life. I appreciate the chance to seek the opinions, thoughts, and criticisms from the world on all topics ranging from compliance / audit to PCI, SOX, HIPAA, ISO 17799 / 27001, COBIT, and such.

As this is my first post, I feel a bit of an introduction is appropriate. In the relative short time on this planet, I have had the privilege of being a risk manager for a major cell phone company, developed and built a proprietary network protocol, programmed secure software – authentication and access control systems, created and trained around the world on information technology, conducted all levels of technical assessments, managed and delivered assurance services (WebTrust, SAS, etc…), developed integrated action plans on cross regulation requirements, and now have the privilege to work with a talented group of individuals on a range of strategic business and industry challenges. On a more specific, and personal level, I enjoy a home in Atlanta GA and have the incredible fortune of having fooled a most forgiving and loving woman to be my wife.

Again, I look forward to sharing my thoughts, experiences, and challenges with the world, and hope you will share your ideas with us too.

James