Maintaining PCI DSS Compliance!

  • Time to read 7 minutes
Maintaining PCI DSS Compliance

Protecting Credit Card Data

Once your business has already become compliant with the Payment Card Industry Data Security Standard (PCI DSS), it's often harder to maintain compliance, especially during the first year of becoming compliant! Our experience has shown that important tasks can easily get missed during the course of the first year or changes are made to the environment which impact compliance and before you realise, it's too late to do anything about it.

If you didn't already know PCI DSS version 3.2 has specific requirements which have become active for any assessment conducted after 31st January 2018. Previously these requirements were purely classed as best practice and therefore didn't need to be assessed as part of an annual assessment. Now that this date has passed, it's important that all business entities review their systems and processes to ensure that they have met these requirements and that nothing is missed. Hopefully, thought your business maintains a close relationship with a Qualified Security Assessor (QSA) to ensure advice is requested whenever there is any confusion or ambiguity about the intent of a requirement.  After all your QSA's opinion is important come audit time, so having guidance throughout the year can only help you maintain compliance. 

Most of the introduced changes relate mainly to entities that are classified as a Service Providers rather than a Merchant, but either way action is required by both. The following tables help to summarise and identify all relevant requirements affected by this change, together with the intent and suggested action required. 

PCI DSS Merchants

The definition of a Merchant is any entity that accepts payment cards bearing the logos of any of the five members of Payment Card Industry Security Standards Council (PCI SSC); namely American Express, Discover, JCB, MasterCard or Visa for payment of goods and/or services. 

Requirement 6.4.6:

Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.

Intent:

To protect the in-scope environment when significant change occurs within an  at any point throughout the year, an entity should ensure that all appropriate PCI DSS controls are applied to the systems or networks that have been changed or added.

Actions:

There are various actions that may be needed for this requirement however, primarily it's important to ensure that the change management processes has a validation process included. This will ensure that any implemented changes are reviewed and assessed to determine which relevant PCI DSS requirements have been affected. The following tasks are common areas that could need reviewing after a significant change:

  • Device inventories and configuration standards;
  • Network diagrams;
  • Systems are still configured as per configuration standards;
  • Systems are still protected with required controls— e.g. File-Integrity Monitoring (FIM), Anti-Virus, Security Patches, Audit Logging etc.;
  • No Sensitive Authentication Data (SAD) is stored;
  • If cardholder data storage is affected document appropriately and incorporated into data- retention policy and procedures; and
  • All new systems introduced are included in the quarterly vulnerability scanning process.

Requirement 8.3.1

Incorporate multi-factor authentication for all non-console access into the Cardholder Data Environment (CDE) for personnel with administrative access.

Intent:

Protect the CDE against unauthorised network access from malicious individuals who may have infiltrated an administrative user account or machine. NOTE: This does not apply to application or system accounts performing automated functions.

Actions:

Ensure all administrative user access to the CDE use a multi-factor authentication mechanism when connecting over a network. for non-console access to the CDE; it does not apply to application or system accounts performing automated functions. Multi-factor authentication can be implemented at network level or at system/application level; it does not have to be both.

PCI DSS Service Providers

The definition of a Service Provider is a business entity that is not a payment brand who are directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data; such as managed service providers that provide managed firewalls, IDS and other security related services as well as hosting providers and other entities.

Requirement 3.5.1:

Maintain a documented description of the cryptographic architecture that includes:

  • Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date;
  • Description of the key usage for each key; and
  • Inventory of any HSMs and other SCDs used for key management.

Intent:

Maintaining such documentation allows an entity to detect lost or missing keys or key-management devices, and identify unauthorised additions to the cryptographic architecture.

Actions:

NOTE: This is only relevant if the business entity is storing cardholder data. 

Ensure that the cryptographic architecture design is documented accurately and includes all relevant information pertaining to the solution in place.

Requirement 6.4.6:

Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.

Intent:

To protect the in-scope environment when significant change occurs within an  at any point throughout the year, an entity should ensure that all appropriate PCI DSS controls are applied to the systems or networks that have been changed or added.

Actions:

There are various actions that may be needed for this requirement however, primarily it's important to ensure that the change management processes has a validation process included. This will ensure that any implemented changes are reviewed and assessed to determine which relevant PCI DSS requirements have been affected. The following tasks are common areas that could need reviewing after a significant change:

  • Device inventories and configuration standards;
  • Network diagrams;
  • Systems are still configured as per configuration standards;
  • Systems are still protected with required controls— e.g. File-Integrity Monitoring (FIM), Anti-Virus, Security Patches, Audit Logging etc.;
  • No Sensitive Authentication Data (SAD) is stored;
  • If cardholder data storage is affected document appropriately and incorporated into data- retention policy and procedures; and
  • All new systems introduced are included in the quarterly vulnerability scanning process.

Requirement 8.3.1

Incorporate multi-factor authentication for all non-console access into the Cardholder Data Environment (CDE) for personnel with administrative access.

Intent:

Protect the CDE against unauthorised network access from malicious individuals who may have infiltrated an administrative user account or machine. NOTE: This does not apply to application or system accounts performing automated functions.

Actions:

Ensure all administrative user access to the CDE use a multi-factor authentication mechanism when connecting over a network. for non-console access to the CDE; it does not apply to application or system accounts performing automated functions. Multi-factor authentication can be implemented at network level or at system/application level; it does not have to be both.

Requirement 10.8:

Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:

  • Firewalls;
  • IDS/IPS;
  • FIM;
  • Anti-virus;
  • Physical access controls;
  • Logical access controls;
  • Audit logging mechanisms;
  • Segmentation controls (if used).

Intent:

To prevent critical security controls from being undetected for extended time periods allowing attackers ample time to compromise systems and steal sensitive data from the Cardholder Data Environment (CDE).

Actions:

Implement a process to ensure the detection, alerting and reporting of any critical security control systems failures is conducted in a timely fashion. 

Requirement 10.8.1:

Respond to failures of any critical security controls in a timely manner.  Processes for responding to failures in security controls must include:

  • Restoring security functions;
  • Identifying and documenting the duration (date and time start to end) of the security failure;
  • Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause;
  • Identifying and addressing any security issues that arose during the failure;
  • Performing a risk assessment to determine whether further actions are required as a result of the security failure;
  • Implementing controls to prevent cause of failure from reoccurring; and
  • Resuming monitoring of security controls.

Intent:

To ensure personnel are aware of their responsibilities in the event of a critical security control failure; and they are able to maintain a documented timeline of their actions and responses, to the issues encountered.

Actions:

Implement processes for responding to critical security control failures, they must include:

  • Restoring security functions;
  • Identifying and documenting the duration (date and time start to end) of the security failure;
  • Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause;
  • Identifying and addressing any security issues that arose during the failure;
  • Performing a risk assessment to determine whether further actions are required as a result of the security failure;
  • Implementing controls to prevent cause of failure from reoccurring; and
  • Resuming monitoring of security controls.

Requirement 11.3.4.1:

If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.

Intent:

To ensure that PCI DSS scope is validated frequently and remains up to date and aligned with changing business objectives.

Actions:

Conduct tests used in the initial stages of a network penetration test (i.e., host discovery, port scanning, etc.) to verify that all out-of-scope LANs truly have no access to the Cardholder Data Environment (CDE). If the results of the segmentation test identify that out of scope environments have access to the CDE, it is recommended that a full network layer penetration test be performed to access the impact on the scope of the PCI DSS CDE.

Requirement 12.4.1:

Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:

  • Overall accountability for maintaining PCI DSS compliance
  • Defining a charter for a PCI DSS compliance program and communication to executive management

Intent:

Ensure the responsibility for the PCI DSS compliance program has been assigned by executive management. This provides the opportunity foe executive management to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities.

Actions:

Ensure documentation has been created which verifies that executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance and verify that there is documentation which outlines the conditions under which the PCI DSS compliance program is organised and communicated to executive management.

Requirement 12.11:

Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:

  • Daily log reviews
  • Firewall rule-set reviews
  • Applying configuration standards to new systems
  • Responding to security alerts
  • Change management processes

Intent:

Provides assurance that the expected controls are active and working as intended. The objective of these reviews is not to re-perform other PCI DSS requirements, but to confirm whether procedures are being followed as expected.

Actions:

Create an internal quarterly audit plan to review processes for the following:

  • Daily log reviews;
  • Firewall rule-set reviews;
  • Applying configuration standards to new systems;
  • Responding to security alerts; and
  • Change management processes.

Document results of quarterly audit plan. 

Requirement 12.11.1:

Maintain documentation of quarterly review process to include:

  • Documenting results of the reviews; and
  • Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program.

Intent:

The intent of these independent checks is to confirm whether security activities are being performed on an ongoing basis. These reviews can also be used to verify that appropriate evidence is being maintained— for example, audit logs, vulnerability scan reports, firewall reviews, etc.—to assist the entity’s preparation for its next PCI DSS assessment.

Actions:

Document results of quarterly audit plan and ensure they have been signed off by the person responsible for the PCI DSS compliance program.

This article was written by a QSA registered with the PCI SSC. For further information or advice on PCI DSS please use our web contact form.

PCI DSS Qualified Security Assessor Company