Chapter 9: Step 9 – Maintaining And Demonstrating Compliance – PCI DSS: A Practical Guide to implementing and maintaining compliance, Third Edition

CHAPTER 9: STEP 9 – MAINTAINING AND DEMONSTRATING COMPLIANCE

Maintaining regulatory compliance requires your entity to be able to demonstrate that the systems are secure, and that adequate processes and procedures are in place to quickly address any gaps in your security posture. For publicly traded entities, this can include detailed reports for financial systems as required by Sarbanes-Oxley (SOX) and corporate governance requirements detailed in the Combined Code 2006.

All entities need to contend with the growing in number and complexity of legal and regulatory compliance – irrespective of size. FISMA (US), SoX, the Data Protection Act40, the European Directive, California SB 1386 (US); and of course the Payment Card Data Security Standard (PCI DSS). All require significant commitment that controls are being employed and that these controls are adequate and appropriate to the risks identified and managed.

This, effectively, means that almost every entity – irrespective of the complexity, size, or contractual/regulatory requirements – has to ensure that a set of rigorous security requirements are addressed, maintained, monitored and improved.

In essence, you will need to seriously consider what mechanisms you plan to use to manage all of this information. It is therefore recommended that you consider using best practice guidance in the form of ISO27002 (ISO17799) Code of Practice to formulate the basis of this management system.

Before you consider some of the solutions that will help deliver compliance, it is worth reminding ourselves of the validation requirements as ultimately this drives all the PCI requirements in the first place.

Items such as log storage size and what reporting is required deserve careful consideration and may need a project set up specifically for this requirement.

Validation requirements

Implementing the compliance requirements is only the start of the process. PCI contains a set of validation requirements that are required to ensure that entities continue to meet the PCI Standard on an ongoing basis. The validation required for PCI DSS is described in Figures 11 and 12.

Figure 11 – Validation action table (levels are based on volume and/or risk)

Level

Validation action

Validation by

1

Annual on-site PCI data security assessment and quarterly network scan

Qualified security assessor or internal auditor if signed by officer of the entity

2

Annual PCI self-assessment questionnaire and quarterly network scan

Approved scanning vendor Merchant

3

Annual PCI self-assessment questionnaire and quarterly network scan

Approved scanning vendor Merchant

4

Annual PCI self-assessment questionnaire and quarterly network scan

Approved scanning vendor Merchant

Figure 12 – Merchant/service provider category table

Level

Description

Merchant Level 1

Any merchant – regardless of acceptance channel – processing over 6,000,000 Visa transactions per year.

Any merchant that has suffered a hack or an attack that resulted in an account data compromise.

Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimise risk to the Visa system.

Any merchant identified by any other payment card brand as Level 1.

Merchant Level 2

Any merchant – regardless of acceptance channel – processing 1,000,000 to 6,000,000 Visa transactions per year.

Merchant Level 3

Any merchant processing 20,000 to 1,000,000 Visa e-commerce transactions per year.

Merchant Level 4

Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants – regardless of acceptance channel – processing up to 1,000,000 Visa transactions per year.

Service provider Level 1

All Visa Net processors (member and non-member) and all payment gateways.

Service provider Level 2

Any service provider that is not in Level 1 and stores, processes, or transmits more than 1,000,000 Visa accounts/transactions annually.

Service provider Level 3

Any service provider that is not in Level 1 and stores, processes, or transmits fewer than 1,000,000 Visa accounts/transactions annually.

How to meet these requirements

This is possibly one of the more difficult (and sometimes neglected) requirements of PCI compliance. Vast swathes of information are required to remain compliant and an entire log management and SAN solution may be required just to ensure the appropriate log information is readily available at the time of audit. That is to say, that despite having all the basic elements of an operational ISMS in place, such as:

  • IS policy set.
  • Scope.
  • Gap analysis mechanism.
  • Risk management documentation (risk register).
  • Security improvement plan.
  • Problem and incident management.
  • Change management.
  • Documented operational procedures.
  • Audit schedules.
  • Business continuity plans.

You still need to consider the use of log management and automation tools in order to help generate compliance and log reports. This is basically because managing PCI compliance and capturing appropriate log information across your IT estate can be extremely difficult. In fact it can make or break your compliance!

Using log management information for PCI compliance

A comprehensive log management information41 (often referred to as LMI) solution that can collect, aggregate and centrally store all data from network devices and server entities could be extremely beneficial to meet the goals of the PCI Standard.

LMI should help provide security, identity access and change management, and monitoring capabilities necessary to comply with PCI and other similar standards ISO27001, ITIL, COBIT.

To implement a log management solution capable of satisfying PCI requirements, it is worth considering the following:

  • Does the log management strategy align with corporate business objectives and IT goals?
  • Will establishing IT controls and processes that enforce these goals help or hinder the PCI compliance programme?
  • How will your entity securely transmit all data collected from these logs to a central repository?
  • Is there a solution that offers the ability to easily search through, report on and set alerts on the data?
  • Will automating the log management processes and reporting requirement actually benefit your entity?
  • Store data in its original, unaltered format, so that it is more credible in legal and compliance investigations.
  • Encrypt data at rest to ensure it is tamper-proof.

Regular monitoring and testing

In either case, you will need to sit down and seriously consider how your PCI compliance will be maintained. This is no easy task, as PCI necessitates ongoing monitoring of the network activity to validate that processes and policies for security, change and access management, and user validation are in place and up to date.

The trick to an operational and successful management system is its risk management, logging, auditing and monitoring. These basic functions will ensure ongoing compliance, by providing a management system designed to take live feeds from all three functions.

The testing of all these basic requirements should be laid down in a document, this could be a simple table (similar to Figure 11 – Validation action table, but could include some of the monitoring, review, audit and testing cycles required).

Figure 13 – Examples of testing schedule (levels are based on defined volume and/or PCI requirements)

Test Number

Validation action

Validation by

Occurrence

1

On-site PCI data security assessment

Qualified Security Assessor or Internal Auditor if signed by officer of the entity

Annually or quarterly

2

Annual PCI self-assessment questionnaire

Audit if signed by officer of the entity and Internal Audit Team

Annually

3

Quarterly network scan

ASV or part of internal PEN Test Team

Quarterly

4

Test change management back out procedures

Internal Security Team

Annually

5

Test problem and incident management procedures

Internal Security Team

Annually

6

Auditing schedules

Internal Audit Team

Monthly

7

Review risk register

Internal Security Team

Monthly

8

Review set of defined logs

Internal Security Team

Weekly

9

Monitor network, IDS, IPS

Internal Security Team

Daily

10

Test BCM and DR plans

Internal Audit Team

Quarterly

The net effect is that you should have a management system that closely aligns with Figure 14. Of course, each implementation will change from where and when key inputs and outputs are taken, but the essence should be the same.

Figure 14 – PCI compliant information security management system (ISMS)

Arriving where you want to be: PCI compliant

The previous tables make it clear that most of the challenge in implementing PCI lies in the technical and administrative aspects of the Standard. This is not surprising, given that most of the risk to cardholder data arises from exploits that target technical and administrative weaknesses in procedural and operational based security.

The fact that PCI requires ongoing validation of security efforts, coupled with the fact that security exploits are constantly changing, makes it clear that your entity cannot implement ‘install and forget’ solutions.

Even the best security efforts will fail occasionally. However, this is often made worse if they are not co-ordinated and integrated within the overall business processes/model, and can ensure that people or departments within the entity are not changing security safeguards or avoiding difficult policies and/or procedures.

You need to be prepared to back up your PCI validation efforts with records that can demonstrate compliance (i.e. evidence of audit findings and log management info). In addition, PCI contains numerous requirements for logging, tracking and the ability to present auditable records. This includes measures that will detect whether, how and when unauthorised changes are made to systems or records.

Section 10.5.5 of PCI requires the use of ‘file integrity monitoring/change detection software on logs to ensure that existing log data cannot be changed without generating alerts’. In other words, when the third party, independent assessors who have been certified by the credit card entity drop by to perform the annual on-site audit, entities must be prepared to produce clear, comprehensive and reliable records demonstrating compliance.

Demonstrating compliance – ROC

PCI compliance also provides details on the expected content that should form part of the annual submission report – the ‘report on compliance’ (ROC) or ‘executive summary report’.

Instructions and content for report on compliance

The ROC document should be used by auditors as the template for creating the report on compliance. The audited entity should follow each payment card entity’s respective reporting requirements to ensure each payment card entity acknowledges the entity’s compliance status. Contact with each payment card entity to determine each entity’s reporting requirements and instructions is well worth the effort.

All assessors must follow the instructions for report content and format when completing a report on compliance:

 

Contact information and report date

  • Include contact information for merchant or service provider and assessor.
  • Date of report.

Executive summary

Include the following:

  • Business description.
  • List service providers and other entities with which the entity shares cardholder data.
  • List processor relationships.
  • Describe whether entity is directly connected to payment card entity.
  • For merchants, POS products used.
  • Any wholly-owned entities that require compliance with the PCI DSS.
  • Any international entities that require compliance with the PCI DSS.
  • Any wireless LANs and/or wireless POS terminals connected to the cardholder environment.

Description of scope of work and approach taken

  • Version of the security audit procedures document used to conduct the assessment.
  • Time-frame of assessment.
  • Environment on which assessment focused (for example, entity’s Internet access points, internal corporate network, processing points for the payment card entity).
  • Any areas excluded from the review.
  • Brief description or high-level drawing of network topology and controls.
  • List of individuals interviewed.
  • List of documentation reviewed.

Maintaining your PCI compliance

The following sections have been provided to help you maintain your compliance with the PCI Standard. The sections are, in effect, mapping examples that will help you remain compliant to PCI DSS, by creating a table which can be measured, monitored and reported against. I have found this a considerably easier way to track what is required for each area of PCI scope. For simplicity, I have broken this down into the three minimum areas of compliance (which yet cause maximum problems):

1  Example compliance mapping for the current environment – this looks holistically across all the areas of scope.

2  Example compliance mapping for the ‘application’ environment – clearly this depends on your web application, but nonetheless, a useful tool to help comply and drive results from your third party vendors.

3  Example compliance mapping for the POS environment – again a difficult area to demonstrate, so hopefully this will help focus your compliance efforts.

Example compliance mapping for your current environment

The example compliance mapping will help you remain compliant to PCI DSS. It details the processes that will need to be completed regularly to maintain PCI DSS compliance across all scope areas and applications. Use this to ensure your overall compliance programme is operational and effective.

The key:

  • PCI control # references the control number within the PCI Standard associated with the activity.
  • Frequency indicates how often the activity is performed.
  • Action indicates the general area and action required by the Actor.
  • Owner indicates who will be performing the action.
  • Description provides supplementary information for the activity.

Future PCI compliance considerations

The discipline of fully evaluating new processes, applications, or significant changes to the environment is beyond the scope of this book. However, the following are considerations as entities’ payment environments grow:

• Will new processes/applications store, process, or transmit cardholder data?

  • If the answer is no, then the process and application is out of scope for PCI.
  • If the answer is yes, is it absolutely necessary that the process/application does so with the full PAN?
    • If the answer is no, then a decision must be made weighing the costs (compliance, security risk, etc.) vs. benefits (business functionality) of using full PAN.
    • If full PAN is required (or it is determined that the benefit outweighs the cost/risk), then the application should be placed within the PCI zones to isolate the ChD and, therefore, maintain a minimal scope.
  • If a payment application is a part of the settlement or authorisation process, then the application should be certified PA-DSS compliant.
    • Most payment software applications will provide an Implementation or Best Practice Guide with steps to configure the application to be PA-DSS compliant that when followed, reduces the PCI compliance burden for entity.
    • The infrastructure will need the full breadth of requirements, but the application can follow the Implementation Guide or Best Practice Guide provided by the vendor.
    • This also applies to upgrades, as each version of an application must be certified.
    • Do not implement a payment application that is not certified PA-DSS.
  • Entities Security Risk Assessment methodology and processes should be used to evaluate the risks associated with bringing the application online.
  • The new application or process should be evaluated against the latest version of the PCI DSS. The security processes applied to other application areas and designed to be scalable will likely need to be applied to the new or changed infrastructure and will contribute significantly to meeting many of the PCI requirements.
  • Will there be third parties involved? If so, please see the section Third Party Considerations.
  • PCI required documentation will need to be updated (e.g. ChD flows, inventories).
  • If the application or process is not PA-DSS (i.e. not a payment application), non-standard, or otherwise complex, outside third party subject matter experts can provide additional guidance to help [Entity] navigate the nuances of PCI compliance through the viewpoint of the Assessor community.

Example compliance mapping for applications

Example sustainability mapping for applications within your PCI environment is outlined in the table below.

The key:

  • PCI control # references the control number within the PCI Standard associated with the activity.
  • Frequency indicates how often the activity is performed.
  • Action indicates the general area and action required by the Actor.
  • Owner indicates who will be performing the action.
  • Description provides supplementary information for the activity.
  • Other related process maps the activity to other relevant activities within this document.

Payment Application Data Security Standard (PA-DSS) Application

For the application layer, software that is PA-DSS certified reduces the PCI compliance burden for the merchant, if implemented under the software vendor’s PA-DSS certified configuration. Most payment software applications will provide an implementation guide with steps to configure the application to be PA-DSS compliant.

If the entity has configured their application layer according to the vendor’s implementation guide54 to meet the Payment Application Data Security Standard, and thus, PCI compliance for that application, this configuration will need to be maintained to ensure continued compliance.

PA-DSS applications must be recertified to ensure continued compliance. If the entity’s installed version becomes no longer compliant, the application must be upgraded to a version, or alternate software, that is. The Information Security Team will monitor the compliance, posted on the PCI SSC’s website, annually and alert to changes.

 

Application operating systems

PA-DSS, however, does not address the OS layer, and thus, the responsibility remains on the merchant for compliance at that layer. If the entity has implemented the following control areas in the OS layer (i.e. iSeries, Windows®), then appropriate evidence of compliance must be maintained in the following:

  • Hardening
  • Access controls
  • Logging and monitoring
  • Antivirus.

Note: Antivirus is not always implemented on certain OS, because this particular OS is not commonly susceptible to viruses.

Example compliance mapping for POS

Compliance mapping for the POS environment is outlined in the table below. The table has the following description columns:

  • PCI control # references the control number within the PCI Standard associated with the activity.
  • Frequency indicates how often the activity is performed.
  • Action indicates the general area and action required by the Actor.
  • Owner indicates who will be performing the action.
  • Description provides supplementary information for the activity.

_______________

40 Data Protection Act: www.ico.gov.uk/what_we_cover.aspx.

41 There are various LMI products available: LogLogic and Guidance Software have similar tools to help analyse data, either of which can help simplify your PCI compliance requirements, www.loglogic.com or Guidance Software EnCase eDiscovery tool - www.guidancesoftware.com/ediscovery-software-frcp-inside-counsel.htm?.

42 Please see the POS PA-DSS Implementation Guide in the PCI Relevant Documents section - www.pcisecuritystandards.org/security_standards/documents.php.

43 Please see the [Application] Key Rotation document in the PCI Relevant Documents section - www.pcisecuritystandards.org/security_standards/documents.php.

44 Please see the Patch Management and Vulnerability Scanning process documents in the PCI Relevant Documents section.

45 Please see Compensating Control document in the PCI Relevant Documents section - www.pcisecuritystandards.org/security_standards/documents.php

46Please see the Vulnerability Scanning process document in the PCI Relevant Documents section - www.pcisecuritystandards.org/security_standards/documents.php.

47 Please see the Risk Assessment policy document in the PCI Relevant Documents section.

48 Please see CSIRTs - www.cert.org/csirts/.

49 Please see the Data Loss Prevention document in the PCI Relevant Documents section

50 Please see End User Policy at www.sans.org/security-resources/policies/computer.php.

51 Please see Change Control at www.sans.org/security-resources/policies/computer.php.

52 Please see www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf.

53 See www.first.org/cvss/cvss-guide.html.

54 Please see PA-DSS Implementation Guide at www.pcisecuritystandards.org/security_standards/documents.php.