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)