Best Practices For Achieving PCI Compliance

1. Eliminate or Reduce cardholder data to Minimize PCI Exposure

Outsourcing payment card processing functions to a third-party service provider is an best practice to reducing the size of a payment environment, reducing the PCI compliance burden, and thereby the potential risk to the organization. One such outsourcing solution involves forwarding transactional data directly to a third-party from the initial “swipe” through settlement and chargeback. With the subsequent authorization and settlement process handled by a third-party, the organization may be able to remove most payment data and systems from their environment, eliminating many of the PCI DSS requirements from their scope. It is important to note that although an organization may outsource its payment processing functions; it will still have PCI compliance obligations. Organizations will be required to have a contractual agreement with the service provider that obligates the third party to comply with the PCI DSS and to ensure payment card data is protected within its environment. Other requirements may still apply if PCI-relevant data flows back into the organization’s environment and if the merchant accesses PCI-relevant data in the service provider’s environment.

2. Consolidate & Centralize Payment Processing Environment

Many organizations’ maintain a multitude of disparate applications, systems, and technologies that process, store, or transmit payment card data within their environment. Centralizing & Consolidating payment card processing systems and associated data can have significant benefits for organizations’, such as increased efficiency of transaction processing reduced operational and compliance costs, and reduced risk associated with the retention of payment card data. By consolidating payment card environment, organizations can eliminate many of the applications from the scope of PCI compliance as they would not store, process or transmit payment card data.

3. Tokenize Credit Card numbers instead of Encryption

Tokenization is a technology that enables a token to replace a credit card number in an electronic transaction. Tokenization replaces sensitive data with unique identification symbols that retain all the essential information without compromising its security. Tokenization may be a viable option for PCI scope reduction for companies with legacy systems that do not support encryption solutions, and for organizations that maintain distributed (often complex) payment environments that pass payment card data among multiple systems. The benefit of tokenization approach is that it centralizes all of the actual cardholder data into one giant lookup table and appropriate access controls can be applied to protect it from unauthorized access. It also eliminates the downstream applications from the purview of PCI compliance as these applications would not be storing or processing or transmitting credit card number. The hard part about tokenization is that applications needs to be modified to deal with this reference number like it would deal with a credit card number.

4. Use Network segmentation to reduce scope of PCI Audit

Network segmentation is the process of using both virtual and physical separations of systems to limit their use to authorized users. Segmentation of the cardholder data environment can significantly reduce the scope of PCI DSS. Network segmentation reduces scope from “anyone with access to the Corporate/store network” to “users approved for accessing cardholder data environment”. It also reduces the inclusion of all non-payment card applications in any future SAQ or on-site assessment.

Top 5 Challenges In PCI Compliance

Today’s Payment Card Industry Data Security Standard (PCI DSS), prevails as one of the most preeminent achievements in the information security industry. However, many organizations are struggling with the increased complexity associated with the PCI Data Security Standard. We will see the top 5 challenges that organizations face in their PCI journey.


1. Protecting Stored Payment Card Data

The most common challenge that many organizations face in achieving PCI compliance is requirement 3 of PCI DSS (encryption of stored payment card data) primarily because of the complex technical and often intrusive nature of available solutions. The data encryption requirement of the PCI DSS is designed to ensure that even if other data protection mechanisms are breached, the encrypted payment card data will remain inaccessible. Unfortunately, mainframes and other legacy systems were not designed to natively support encryption solutions. Data reduction and process reengineering are approaches used by many organizations to reduce the amount and type of payment card data that needs to be encrypted.

                                Image via pinewswire



2. Defining Cardholder Environment

                                                               Image via tevora

Organizations attempt to assess their current state of cardholder environment without a clear understanding of the in-scope environment. This includes understanding all payment processes including how cardholder card data enters the environment, where the data is processed and stored within the organization’s environment, how the data leaves the environment, and with whom the data is shared. It is very important to trace the route where the cardholder data goes through, and map all access points to the environment holding the card data. Even if cardholder data is not stored, the data can be compromised by accessing the channels through which it flows through. Lack of a clear understanding often results in an incomplete compliance assessment and residual risk.

3. Logging & Monitoring Events

Logging and monitoring of security related events on systems that store, process, transmit, or provide access to cardholder data is required to aid in detection and prevention of suspicious activity and analysis of activities in the event of a breach. Many systems and applications in a legacy environment do not natively support logging controls mandated by the PCI DSS. Moreover, many of these systems and applications were not designed to handle the additional overhead on system resources in an environment where rapid transactional response time is essential. Organizations deploy a variety of monitoring and logging solutions ranging from stand-alone manual procedures to fully automated and centralized solutions. Once the solution is deployed, it generates massive amounts of log data which poses a new challenge in monitoring those logs effectively.
4. Controlling Access to Cardholder Environment

Restricting unauthorized access to cardholder data (and systems) is a fundamental principle of PCI compliance, and it continues to be a challenge for many companies. A variety of factors add to the challenge, such as data proliferation across disparate systems, using the production data in non-production environment, absence of a clear understanding of where data resides in the enterprise, the inability of legacy or home-grown systems to support certain PCI-mandated controls, and the absence of a role-based access control model. Remediation approaches range from tactical point solutions to managing access at the individual payment system level to complex enterprise identity management solutions.


5. Lacking A Holistic Approach to Compliance


                                                            Image via howlifereallyworks

Most organizations take a siloed approach to addressing applicable regulatory, risk management, and compliance requirements. In many organizations, compliance programs focusing on regulations such as PCI, Sarbanes-Oxley (SOX), and the Gramm-Leach-Bliley Act (GLBA) are not effectively integrated, even though many of their requirements overlap. Such a siloed approach impairs efficiency and effectiveness, contributing to duplication of effort, inconsistent processes, and ultimately compliance fatigue.

PCI Compliance - An Ongoing Journey Not A Destination

The Payment Card Industry (PCI) Data Security Standard is a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures created by major credit card companies to safeguard customer information. Credit card companies like Visa, MasterCard, American Express, and other credit card associations mandate that merchants and service providers meet certain minimum standards of security when they process, store and transmit cardholder data.

                                          Image via flarenetwork

The PCI Data Security Standard consists of 12 basic requirements spread among 6 major control objectives. One of the main objectives of PCI is to ensure that a consistent “due care” is used to protect payment account, transaction and authentication data of customers. The goal of PCI is to improve data protection strategies that will allow customers to swipe their credit cards with more confidence and assurance that the confidentiality and integrity of their information will not be compromised.

PCI Compliance

It is imperative that organizations must know their compliance posture before they approach PCI Compliance. The approach of fixing PCI using "one size fits all" approach would only lead to a disaster. To begin with organizations must scope the PCI infrastructure topology and then perform the following:

1. PCI Pre-Assessment and Gap Analysis must be conducted. The Pre-Assessment is crucial and enables an organization to understand what the PCI compliance effort will entail.
2. A remediation program must then be developed and implemented to address the gaps found in the Pre-Assessment.
3. Design a security framework and align the security controls to address the compliance requirements.

How do you think many matured organizations achieve success in their PCI efforts? Very simple…it’s by approaching PCI from a risk-driven model. This type of approach enables resources to be prioritized around business risks, which ensures that resources allocated, are directly in line with those that contribute to the achievement of corporate objectives. This is considered to be the keystone or foundation for an effective PCI compliance program management system. This is a formal system of risk management which can show that the PCI requirements and resulting work have been effectively planned and managed. These organizations view compliance as part of their risk management strategy and not as a standalone project.

Complying with PCI does not preclude an organization from attack. An organization's compliance to PCI represents only a “snapshot” of security in place at the time of the review, and does not guarantee that those security controls would remain in place after the review is complete. This means once the organization is PCI compliant, it has to proactively review the people, process and technology time and again.

I’m sure that everyone would agree that new vulnerabilities are discovered everyday. In such a situation, it becomes mandatory for the organization to be dedicated and disciplined if it wishes to stay on top in spite of all these challenges. However, the ultimate success around PCI depends on how committed management is to it.

To conclude, Payment Card Industry Data Security Standard (PCI DSS) compliance is an ongoing journey once you embark on it and not a destination.

Risk-based Authentication – A Strategy for Real-Time Fraud Detection

Identity fraud is the major security concern for most of the organizations doing Internet businesses today. It has an influence on the cost of doing business, increasing customer anxiety and thereby inviting government regulation. The best way to prevent identity fraud would be to adopt a layered approach to security. Fraud detection would be a critical security layer, which would include Risk-based Authentication as a mechanism for fraud detection.

                                                            Image via zunia

Risk-based authentication is a technique that uses both contextual and historical user information, along with data supplied during Internet transaction, to assess the probability of whether a user interaction is authentic or not. Let us see what contextual and historical user information mean. The contextual information typically includes the traditional username and password in addition to the following information like who the user is, from where they are logging in (IP addresses, location information - city the user is actually in at the time of communication), what kind of device they are using. Historical user data includes specific attributes provided from the session as well as user behavior and transaction patterns. This information represents an additional authentication factor that supplements the username and password, making this an enticing multifactor authentication technique.

The risk-based authentication model is built on a rule engine that takes into account multiple combination of parameters such as IP address, location etc. as described above. This data can be used to create a pattern to compare with those in future authorization attempts. The rule engine checks each transaction to see if it matches any pre-determined pattern for fraudulent transactions. Since online fraud patterns evolve rapidly, the rule engine must deploy automatic pattern recognition and self-learning capabilities, in order to quickly find new patterns to prevent fraud. A machine learning, anomaly-detection system can also be used to address the shortcomings of rule-based systems.

In risk-based authentication, much of the contextual data is susceptible to fraud. Although it is difficult to replicate the contextual data, a fraudster could try and spoof with the intention of fooling the authentication system in which case the fraudster would have to know all the specific attributes that the authentication algorithms and then painstakingly replicate the attributes. Fortunately, the difficulties in exploiting this, along with the availability of historical data that cannot be spoofed, make risk-based authentication more effective.

Risk-based authentication enables Internet businesses to assess security risks and use out-of-band challenge and response mechanism as a second factor authentication only when necessary. Risk-based authentication works behind-the-scenes and has a minimal impact on users. Risk-based authentication can occur at initial log in and may also be performed at subsequent interactions during secure sessions as well as during high-risk transactions.

Risk-based authentication allows selecting the right level of security for each activity, instead of using comprehensive security for the entire user base. This type of authentication gives businesses the flexibility to be able to provide additional authentication as and when necessary. The main benefit of this type of authentication is that additional hardware or software is not required, making this non-intrusive and seamless to the end user. In addition, risk-based authentication is far less expensive to deploy and administer. It is also one of the few solutions that successfully identify man-in-the-middle attacks.

Risk-based authentication like any other authentication solution is not fully foolproof. There are few challenges like false positives & accuracy of risk prediction that risk-based authentication must address in order to be more effective. False positives are a major challenge that risk-based authentication needs to overcome. There are false positives with any given technology, but there are also ways to minimize these issues by applying best practices and fine-tuning the authentication process.

The bottom line is that risk-based authentication works behind-the-scenes to spot the high-risk transactions, and apply the right level of security for the specific level of risk. It allows the organizations to manage online risk in a better fashion. It helps to decide what risk the business is willing to take, and what risk it isn't willing to take, for every online activity. Since most users are not challenged, it provides a good balance between security and usability and hence maximum usability for the majority of users, and a little more effort for a small amount of users.