Select language:

Latest Articles

Stay Updated With The Latest Articles & News With Contact Advisory Services


23.07.2015

Scoping the Cardholder Data Environment


PCI DSS has been around for some time now but till this day there still seems to be a general lack of appreciation of what PCI DSS aims to achieve. PCI DSS is an information security standard, but one which unlike other standards like ISO27001, is very specific in its objectives. PCI DSS is a standard designed to provide a minimum benchmark of controls in protecting credit card data. The twelve requirements are intended to touch, in some way or another, on all those risks areas which could lead to a compromise of card data. Because of the fact that the objective is so specific, so can the required technical and procedural controls.

What many people fail to understand is that the value derived from PCI DSS is not in the individual requirements but in the collection of all the requirements put together. Some requirements may seem trivial when one analyses it in isolation but in the grand scheme of things the absence of that insignificant control could be what an attacker was hoping for to get a foothold onto your system.  It is therefore no surprise that the PCI Security Council requires that 100% of requirements needs to be in place before someone can be considered compliant or certified.

Another concept which is very often misunderstood is the scope of PCI, which is referred to as the Cardholder Data Environment (CDE). This may be the most important term in the entire PCI vocabulary because it is what determines those systems, applications, processes and procedures which are considered relevant to PCI and which therefore need to be protected.

Contrary to what many people may think, the scope is not determined solely by whether a particular system handles, processes or stores credit card data. This is where many get it wrong and as a result focus all their compliance efforts on the wrong scope or what should otherwise be described as a subset of the real scope.  One could think of the scope as an imaginary chalk line which is drawn around those systems which are involved in the credit card transaction, from the processing of the card, to its storage and also its retrieval and reuse. The scope goes beyond this and should also be extended to all those systems that could affect the security of those systems that are directly involved in processing card data. This definition casts a wider net on those systems previously thought to be exempt from PCI requirements. The scope is not technology dependent but it also is not focused solely on servers, applications and firewalls. Processes and procedures may also form part of the scope as they could affect the security of card data.

As the scope grows, so does the complexity. It is therefore in anyone’s interest to keep the scope as small as possible. This is where problems start and where merchants or service providers have very different, if not conflicting, views to their auditors on where the line should be drawn. A common term which is used in determining whether something is in scope or not is to assess whether it is ‘connected’ or not. Connected implies that it is either on the same network or else on a completely separate network with access to or from the CDE. Systems on the same network segment as the CDE are automatically in scope, even if there is no communication or have no part in credit card data handling or storage. The mere presence of a system on the same network as other in-scope systems renders it in scope and therefore part of the CDE.

The scoping exercise becomes complicated when one contemplates whether systems on different network segments are actually connected systems or not. Needless to say, any system on any network which is involved in the transaction process or in the storing or retrieval of card data is in scope. By the same definition of connected systems, any system on the same network as a connected system will also be dragged into the PCI scope. In the absence of proper network segmentation, the scope could potentially extend to the entire network infrastructure. Segmentation by way of routers, firewalls, VLANs and other methods could ensure that a system is not considered connected and therefore be scoped out of PCI. With the same reasoning, system on the same network segment as an in-scope system could be moved out of the network segment for the sole purpose of reducing the scope.

 

The effort spent in reducing the size of the CDE is well worth it, when one considers that requirements such as Intrusion detection, file integrity checking, vulnerability scanning, antivirus, centralized logging, patch management and a multitude of other controls need to be applied to all systems that fall within the chalk line. Entities that have been audited regularly know this very well, but others, especially those filling in annual Self-Assessment Questionnaires may have been making wrong assumptions on their scope all this time.

 

Prepared by Trevor Axiak, Director of Kyte Consultants Ltd

Featured on www.igacademy.com - 22nd July 2015

 

© Kyte Consultants Ltd 2008 - 2015


Back to Latest News