PCI DSS

This is a copy of a blog I wrote for IT Governance, where I will be publishing a series of blog entries that will be looking at the PCI DSS and the 12 requirements contained within it; the series is starting by looking at the scoping of the cardholder data.

This is really a general overview of the standard and its requirements.

Compliance with PCI DSS should be considered the minimal level of security that should be implemented and does not ensure that an organisation is secure; however compliance should ensure that an organisation has in place the procedures, policies and work practices that will reduce the possibility of a cardholder data breach and improve the effectiveness of an investigation of a breach. It is important an organisation that is PCI DSS compliant maintains the compliance at all times.

Within the PCI DSS standard it refers to a ‘trusted’ network, which is the environment within which the cardholder’s data is identified as being either processed, stored or transmitted. A key point about the standard and its related standards and guidelines is that they have been written to protect cardholder data as it is processed, stored or transmitted and not necessarily to protect the entire infrastructure of an organisation from all security threats as it is a very specifically focused standard.

For an organisation the best methodology for making the process of implementing and gaining compliance with the PCI DSS standard easier, is to reduce the scope of the implementation, which is the size of the environment involved with cardholder data. This can be achieved by reducing the footprint of cardholder data within your organisation’s environment by analysis of where cardholder data is stored, processed or transmitted and reducing the locations within the environment where it is handled, segregating the cardholder data from the rest of the organisations environment, creating a trusted environment and a non-trusted environment reduces the scope for implementing the standard. In fact if it is possible to completely remove cardholder data from the environment which will make the environment become completely out of scope, however if 3^rd parties are handling cardholder data for you, the responsibility for ensuring they are doing so within the requirements of the standard remains with your organisation.

Any part of an organisation including its infrastructure where cardholder data is processed, stored or transmitted will be within scope and is known as the cardholder data environment (CDE) and is required to be protected (becomes trusted), any part of the organisation and infrastructure that is out of scope and also the public internet is considered untrusted.

The standard looks at the protection between the CDE and the untrusted environment; it covers all aspects of providing that protection, not only technical controls but includes policies about those employees who have access to the cardholder data and the trusted environment as well as measures to help with the investigation of breaches.

In order to identify where cardholder data is within you environment it is necessary to track the flow of data across the infrastructure which requires up to date network documentation and knowledge of the processes within the organisation. Examining the data flow, starting from where it enters your environment, this can be through a gateway from the internet onto the network, via phone lines, the postal system or via fax. Following the movement of the data from its entry point(s) through the organisation until it permanently leaves organisation or is destroyed will identify all the components that are involved in the processing, storage and transmission of the cardholder data.

At this point I like to give a reminder that the systems involved in handling cardholder data not only include the hardware and software of the infrastructure, but everything connected to the CDE and also includes the employees of the organisation who handle the data processing, phone calls, post, fax, maintenance of the infrastructure, administration of servers etc, It will also cover not only your own organisation but any 3^rd party organisations (know as service providers), who may be processing, storing or transmission cardholder data on your behalf or providing a service that effects the processing, storing or transmission cardholder data within your organisation such as an IT support company who have administrator rights to firewalls, routers or servers.

Analysis of the data flow should not only cover the active processing, storage or transmission of cardholder data but include the storage and processing of the backup media that may contain cardholder data including when these are stored off-site.

Upon completion of the analysis of the flow of cardholder data through the organisation, it would be desirable to reduce the scope of the CDE by segregating the environment where the cardholder data is from the rest of the environment and also reducing the number of systems and processes where cardholder data is handled.

In addition to identifying where cardholder data is expected to be, steps should be taken to ensure that cardholder data is not located in places where it is not expected to be, i.e. in a spreadsheet on the desktop of a data analyst who generated a report on a database containing cardholder data. In order to examine the whole environment of an organisation for unknown locations of cardholder data, techniques from e-Discovery can be used to identify the locations of cardholder data, hopefully all the identified locations will match the data flow analysis results, any mismatch shows cardholder data is being held in unidentified locations that are likely not part of the normal data flow.

Conducting a scoping exercise is only part of the story, the documentation of the reasons for identifying the CDE and reducing the scope from covering the whole organisation to a sub-set of the organisation (trusted network) needs to be kept for reference by any auditor. This is typical of the PCI DSS standard in that includes requirements that the documentation of the business reasons for implementing a control or deciding it is not applicable need to be part of the PCI-DSS documentation.

In the following blog entries I will be examining the requirements of the PCI DSS in turn and other issues affecting PCI DSS.