Skip to Content

Common Pitfalls and Tips to Meet PCI DSS Compliance Network Environment

While compliance is assessed and declared on an annual basis, there are daily, weekly, monthly, and quarterly acts, such as patching systems and implementation of compensating controls, that must also be carried out by governance and security experts in order to simply maintain compliance.

Common Pitfalls and Tips to Meet PCI DSS Compliance Network Environment. Source: SecureWorks

Common Pitfalls and Tips to Meet PCI DSS Compliance Network Environment. Source: SecureWorks

With these recurring tasks come common pitfalls that can impact an organization’s ability to maintain a complaint in-scope network.

Based on Secureworks’ experience helping clients meet and maintain PCI DSS compliance, we have outlined the five most common pitfalls and key recommendations to help you mitigate the risk of a failed compliance audit.

What You Will Learn:

  • Common pitfalls associated with PCI DSS include:
    • Patching systems
    • Understanding and implementing compensating controls
    • Sourcing credible answers, and more
  • Tips to mitigating the risk of a failed audit include:
    • Utilizing segmentation
    • Using PA-DSS approved applications
    • Implementing change tracking

Content Summary

Typical Pitfalls Complying with PCI DSS
Mitigating the Risk of a Failed Compliance Audit

Typical Pitfalls Complying with PCI DSS

Maintaining a compliant PCI DSS network environment is an everyday battle. While compliance is assessed and attested to on an annual basis, there are daily, weekly, monthly and quarterly acts that must also be carried out in order to meet specific requirements. With these tasks come common pitfalls, whether technical or procedural that can affect an entities ability to maintain a complaint in-scope network.

Based on SecureWorks’ experience helping clients meet and maintain PCI DSS compliance, the following are five common pitfalls recently observed:

Patching Systems

The description that defines the scope of the network is confusing. According to the definition, it includes system components which store, process, or transmit cardholder data and all the systems connected to those systems. Deciding which devices are in the network and need to be patched on a regular basis adds stress to the networking and systems administration teams. If it is in-scope, it needs to be patched on a regular basis.

The only exception to this rule is third-party applications which the entity does not manage, examples include payment or web applications like Java or Silverlight which are not owned nor maintained by the entity.

PCI DSS Requirement 10: Meeting each logging requirement

Logging and auditing system components are an everyday process that can bring daily struggles. Common issues arise from requirements that require a daily security review of audible events that must be offloaded to either a centralized logging server or to media which is secured and difficult to alter. Whether through technical (not having appropriate configurations) or business (not having enough team members) restrictions, maintaining compliant logging solutions can bring down an entities compliance percentage, and cause additional stress on teams who manage systems that must be logged.

Securing and hardening management interfaces

Web servers are integral to an organization’s online presence. If there are web based management interfaces, they now (for the time being) must only communicate over secure channels such as HTTPs with TLS1.2. With the recent SSLv3 vulnerability, browsers utilizing that protocol will be considered non-compliant, and fail a PCI DSS vulnerability scan performed by an ASV.

A Security Approach to Compliance

SecureWorks advocates a “security approach to compliance” instead of a “compliance approach to security” because it is critical to have a strategy that’s scalable, sustainable, and is backed by a culture that values information security throughout the organization. This can help reduce the risk of breaches and damage to your brand reputation, and help you manage your costs and resources.

Understanding and implementing Compensating Controls

Sometimes business or technical restraints may hinder the appropriate measures so a requirement is fully met. To address these, there are Compensating Controls that allow entities to go above and beyond the requirement with technology and processes to meet the intent of the requirement.

However, knowing which requirements allow a Compensating Control, and how to securely and compliantly implement them is a common struggle that the technology team will face.

Seeking answers from different sources yields different results

If an organization is not actively engaged with a Qualified Security Assessor (QSA) company, the first place they seek guidance is the Internet. While the Internet is a great resource for a lot of things, it is also an open forum and advice and guidance on something as specific as a PCI DSS requirement should be taken with caution.

With recent changes to the already new PCI DSS version 3.0, the best and most concise source of information outside of a QSA company is the PCI Council website: Typically, the information presented to a QSA is very quickly released to the public. The Council has done a great job recently of updating customers regarding changes to the framework, and major threats in the Information Technology landscape.

Mitigating the Risk of a Failed Compliance Audit

Though PCI DSS compliance can be a complicated and laborious process, the following tips will help guide your organization mitigate the risk of failing a compliance audit:

Maintaining compliance is an everyday battle

After your assessment is over, utilize the information you learn from your assessor to maintain a compliant environment.

PCI DSS compliance is an annual attestation, and requires the full cooperation of every team member for your business to remain compliant.

Provide periodic training and inspiration for team members; every person plays a part in securing your customer’s data and the future of the business.

If data must be stored, encrypt the data in transit and rest

Encrypt data in transit and rest through industry accepted standards, such as SSLv3 through HTTPS, and AES 256-bit encryption algorithms respectively. If your business does not need to store data, don’t store it!

Utilize segmentation (physical and virtual) to reduce scope

Network segmentation reduces the scope of the cardholder data environment (CDE), and is achieved through physical (switches, routers, physically separate networks) and virtual (VLAN, Hypervisor, VMWare) means.

If there is no segmentation in place, then everything connected to the network is inscope and must meet all 12 PCI DSS requirements.

Document an Information Security Policy, Software Development Life Cycle, Incident Response Plan, Risk Assessment, and Security Awareness Training

Each of these policies will be reviewed by your assessor, and each document must include policies and procedures for operations which support the storing, transmitting, and processing of cardholder data. Examined within the review process will be how the company securely develops applications which interact with cardholder data, how the business responds to security vulnerability alerts or malicious activity alerts, how the company assesses risks within its organization and network environment and how the company relays credit card security procedures to its employees.

Additionally, these policies must be reviewed, and in some cases tested, on an annual basis.

Use PA-DSS approved payment applications

If your business utilizes a third-party payment application (something that is currently not developed by you, specifically for you) require that the payment application is PA-DSS validated, and acceptable for new deployments.

PA-DSS applications must undergo a new validation every three years, and must maintain their compliance on an annual basis by submitting attestation of changes to the PCI DSS Council; review the listing on the PCI DSS Council’s website to verify the payment application and payment application vendor is in good standing and compliant.

Maintain Logs for One Year

All access to cardholder data must be logged (whether it be from a database or a payment application), especially the access of any administrator or administrative change to the cardholder data environment.

All anti-virus events must be logged, along with all logs from externally facing devices such as web servers and firewalls.

In most cases, logs must be able to be retrieved for an analysis of the last three months.

Perform Internal Security Assessments

PCI DSS compliance requires that businesses either perform or contract to a third-party internal vulnerability scanning and internal penetration testing.

If your business designates an internal resource to perform one, or both of these operations, this person must be knowledgeable in security testing procedures, and also must not be directly involved in the overall PCI DSS assessment (this is described as organizational independence).

Implement Change Tracking for System Components and Software Development

Any change that occurs on a system component, or developed software must be tracked and have the appropriate procedures (such as testing, and management approval) logged which can be used to correlate system and application changes as well as the responsible party.

Reevaluate Service Provider PCI DSS

Compliance Status Annually Maintain an active listing of any service provider which interacts with cardholder data from your network (payment processors, datacenters, and application vendors). Additional requirements are now in place that require your business have service providers agree in writing that they acknowledge their responsibility of any cardholder data they obtain through business channels or other interactions with you. Inquire with your legal counsel, as this verbiage or agreement may already be in place.

Protect Devices from Tampering

With broad scale attacks on credit card data unfortunately becoming the norm, take the time to train team members to detect fraudulent activity or devices.

Each team member must be familiar with the approved devices which interact with card data, and if a device appears to be different or tampered with an incident response procedure should immediately go into effect.

Maintain an up to date inventory for any device which interacts with cardholder data which includes the make and model and physical location of the device, and make the inventory known to all team members.

Source: SecureWorks

    Ads Blocker Image Powered by Code Help Pro

    Ads Blocker Detected!!!

    This site depends on revenue from ad impressions to survive. If you find this site valuable, please consider disabling your ad blocker.