bizEDGE NZ - Credit card safety part3

Warning: This story was published more than a year ago.

Credit card safety part3

Last month we provided an overview of the ’Payment Card Industry Data Security Standard’ or PCI DSS. We encouraged you to draw yourself a high-level diagram of your cardholder data (CHD) environment.  
As we also said, the bigger the scope of your environment, the more your compliance will cost. You will need to work through the entire Standard and make sure you meet all the controls. A control that can be demonstrated to be ’Not Applicable’ is considered ’In Place’.
Our next piece of advice is ’Segment the Network’. This means using a firewall or other appropriate technology to logically separate the CHD environment from your other IT infrastructure. This is the most effective way (other than not having CHD) of reducing the scope of your environment.
The CHD must be protected when it is stored. This is usually achieved by using well-known encryption techniques. You need to make sure that only those within your business that have a legitimate need to see and work with the full CHD have access to it. This implies implementing some sort of role-based access control (RBAC).
To help you, the Secrity Standards Council has developed a Prioritized Approach’ to working through the Standard as you work towards compliance. The ’Prioritized Approach’ provides six security milestones that will help merchants incrementally protect against the highest risk factors and threats while on the road to PCI DSS compliance. The Council’s opinion is that the greatest impact on the reduction of CHD breaches will be achieved early in the compliance process if the higher ranked controls are addressed first. However, you still have to work through and meet all of the controls. The ’Prioritized Approach’ can be downloaded here:
Meeting compliance is just the start. Once you have met all of the controls, you have to maintain them ’24 x 7’ for 365 days of the year.
No standard could ever hope to cover all possible business situations. For this reason, some of the controls may appear confusing or contradictory in your particular situation. Remember, last month we said that the controls normally have one of two intents, and if you refer back to them when in doubt, you can normally work out what the control means in your situation, ie:
1.    Prevent inappropriate disclosure of cardholder data
2.    Detect when inappropriate disclosure occurs, allowing quick remediation.
The Standard is also evolving. This is why we encourage all merchants to take a ’Security’ view rather than a ’Compliance’ view. What’s the difference between Secure and Complaint? To use an analogy, "Secure” is the designated driver who doesn’t drink for the evening. "Compliant” asks the bartender how many drinks he can have and still get away with driving home. If you are secure, compliance should occur as a result. You may be 100% compliant, but still not be secure. If you take the view of just doing enough to satisfy the Standard, then you will more than likely get caught out when the Standard changes (each revision gets tougher). Version 2.0 of the Standard was released in October 2010. If you have a copy of version 1.2 as a result of reading our earlier articles, make sure you get the latest copy.
Some of the controls have the potential to be quite costly to implement for smaller merchants. These include but are not limited to:

  • intrusion detection or prevention systems (IDS/IPS)

  • file integrity monitoring (FIM),

  • centralised log monitoring, and

  • annual penetration testing.

If you are in any doubt about any aspect of the Standard, we encourage you to speak to your bank (acquirer) or QSA. Ask your bank to confirm what level merchant you are and what your validation requirements are (SAQ, onsite audit etc).

Are you keen to hear from an expert in this field?

Follow Us


next-story-thumb Scroll down to read: