Payment Card Security: Risk & Control Assessments
By Gideon T. Rasmussen, CISSP, CISA, CISM, CIPP

The PCI Data Security Standard mandates foundational controls, most of which are information security best practices. It is a one-size-fits-all standard meant to address all business and technological environments that store, process or transmit payment card data. Minimum compliance with PCI standards may not adequately protect card data. Therefore, it is necessary to conduct a risk assessment in accordance with PCI requirements.

Organized crime is in the business of breaching card data and committing fraud to profit from their efforts. Business is booming and they are reinvesting. The level of sophistication is apparent. One recent breach was identified by common point of purchase fraud analysis. It took two forensics teams to find the source of the compromise. Sniffer malware was installed on an unassigned section of a server hard drive, outside of the operating system. Hackers are also using malware to collect unencrypted card data stored in system memory.

Professional hackers are innovative and patient. They slowly infiltrate an environment, learn how card data flows and subtly probe for vulnerabilities. They create custom malware unique to the IT environment and test against anti-virus software to avoid detection. Next, they install malware and exploit the payment application. Once card data has been breached, hackers encrypt stolen data and use anti-forensic tools to further avoid detection. Highly difficult attacks accounted for 95% of all compromised records.[i]

Be mindful of the threat posed by authorized personnel. In addition to malicious insider threat considerations, internal personnel may introduce vulnerabilities through human error. A malicious actor may assume the guise of an employee through a technological exploit or compromise them through social engineering.

I. Management Support

Resources are required to conduct a comprehensive risk assessment. Explain the current threat landscape to senior management. Determine their risk tolerance and request their active support.

Assign a dedicated function to conduct risk assessments to establish accountability. In a small organization, it may be an alternate duty for a security professional. In a medium sized organization, consider hiring a full-time security professional. In a large organization, a small team should be dedicated to technology risk assessment.

It will be necessary to involve members of multiple teams to conduct the risk assessment. Consider establishing a project to identify participants, conduct the assessment and finalize remediation.

II. Data Flows and Systems

Create a data flow diagram that documents where payment card numbers are stored, processed and transmitted. From the PCI Data Security Standard[ii], diagrams should detail physical and logical data flows, "including transmission and processing of card data, authorization, capture, settlement, chargeback and other flows as applicable". As a best practice, scan for payment card data outside the PCI environment at least annually.

Card Brand

Comments

Regular Expression

Visa

All Visa card numbers start with a 4.

^4[0-9]{12}(?:[0-9]{3})?$

MasterCard

All MasterCard card numbers start with numbers 51 through 55.

^5[1-5][0-9]{14}$

American Express

American Express card numbers start with a 34 or 37.

^3[47][0-9]{13}$

Discover

Discover card numbers start with 6011 or 65.

^6(?:011|5[0-9]{2})[0-9]{12}$

Source: PCI Security Standards Council

Next, establish an inventory to document the systems, applications and databases associated with each PCI environment. Include details such as information owner, data custodians, application managers, PCI network scans and when the last application assessment was conducted.

III. Risk and Control Assessments

PCI requirement 12.1.2 includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. To identify threats and vulnerabilities, subscribe to US CERT advisories, the DHS daily cyber report and vendor security alerts. Merchants can obtain the Visa list of vulnerable applications from their acquiring bank. Information security professionals should join the U.S. Secret Service Electronic Crimes Task Force and FBI InfraGard. ECTF and InfraGard are free and provide threat and vulnerability advisories.

The scope of a PCI risk assessment is the same as a PCI assessment. Follow the flow of payment card data in production and disaster recovery environments and evaluate compensating controls. Conduct a thorough risk assessment before implementing new technologies such as virtualization or cloud computing.

Conceptualize data flow as a pipe with holes in it. Areas of vulnerability include systems between encrypted network connections and the data flow channel itself such as application security attacks that easily pass infrastructure security controls.

IV. Failure Mode and Effects Analysis

Failure Mode and Effects Analysis (FMEA) is a method to evaluate potential failures within a process or system. Analysis includes consideration of failure severity, rate of occurrence and detection. FMEA was introduced in the 1940s by the US Armed Forces. Later, it was adopted by NASA, the Ford Motor Company and most recently, Six Sigma.[iii]

FMEA is also a practical way to conduct a technical risk assessment[iv]. Depending on the size and complexity of the environment, it will take between eight and sixteen hours to conduct an FMEA evaluation. In large organizations, maintenance of controls may be assigned to several teams. FMEA participants should include representatives from physical security, system and network administration, application development, information security and operations.

System Component

Potential Failure Mode

Potential Effect(s) of Failure

Severity

Potential Cause(s) of Failure

Occurrence

Current Process Controls

Detection

RPN


System Component: Evaluate each system component listed on the card data flow diagram such as routers, firewalls, servers and point of sale systems.
Potential Failure Mode: For each system, determine how card data could be compromised at physical, network, host and application layers.
· Physical: Consider how card data could be stolen in-person such as taking a server from a computer room.
· Network: Consider how card data could be compromised in transmission over the network such as use of sniffer software.
· Host: Consider how card data could be compromised while in storage or while in system memory such as the use of malware or use of a zero day attack.
· Application: Consider how card data could be compromised at the application layer such as exploitation of a software coding error.
Potential Effect(s) of Failure: Describe the consequences of the failure mode such as payment card data would be compromised.
Severity: Enter a numeric rating associated with the severity of the failure mode.
Potential Causes of Failure: Describe potential causes of the failure mode.
Occurrence: Enter a numeric rating to represent the probability of the failure occurring.
Current Process Controls: Describe existing controls that detect or prevent failure.
Detection: Enter a numeric rating to represent the probability of the failure being detected.
RPN: Risk Priority Number = Severity X Occurrence X Detection

Use RPN scores to prioritize remediation. The highest RPN values correspond to issues with the greatest potential for business impact.

V. Risk Assessment Scenario

In this scenario, a large corporation used FMEA to conduct a thorough risk assessment of their PCI environment. Senior management, in partnership with information security and audit defined the following problem statement: The PCI Data Security Standard (DSS) is a publically available control baseline. Organized crime syndicates and their hackers are familiar with it. The complexity of an IT environment makes it difficult to maintain in practice. For these reasons, it is necessary to conduct a thorough analysis of the cardholder data environment to determine where opportunities to compromise data are present. This approach is also in keeping with the PCI requirement for an annual risk assessment.

As a result of FMEA evaluation, the following recommendations were made to mitigate risk above and beyond PCI DSS requirements:

Preventive Controls:

Preventive controls are necessary to protect card data from compromise. Each control environment is unique and compliance with PCI requirements alone may not be sufficient to mitigate the risk of compromise.

Restrict cardholder environment access to company-owned computers. Requirement 1.4 permits employee-owned computers to connect to the cardholder data environment. Employee-owned systems are outside of the control of employers and cannot be subjected to systematic removal of accesses from a payment card data perspective.

Encrypt data over private, internal networks. Requirement 4.1 addresses encryption over open, public networks, stopping short of requiring encryption over internal networks. There has been a trend of data compromises where card numbers have been compromised over unencrypted network connections. Relying on perimeter security alone is akin to "candy security", hard on the outside and soft and chewy on the inside.

Use firewalls to segment card data from internal networks. The entire company network has connectivity to systems that store, process or transmit cardholder data, which results in costs associated with maintaining controls and assessment activity in accordance with PCI requirements. Segmenting card data from unrelated systems takes them out of the scope of PCI compliance, reducing risk of compromise and the cost of compliance.

Further restrict payment card network connectivity and traffic flow to protect card data. Eliminate the practice of passing full 16 digit card numbers to the marketing server. Truncation is a viable alternative, deleting all but the first six and last four digits. Network connectivity exists between stores, without a supporting business requirement. Restrict store network connectivity to the corporate data center.

Require customers to enter their zip code at unattended payment terminals. Requiring a zip code to process a transaction is a method to prevent fraudulent transactions. For additional details, research the Address Verification System.

Detective Controls:

If a breach occurs, it is necessary to learn about it early to contain the incident and minimize business impact.

Implement configuration monitoring software to ensure system hardening remains in place, in accordance with industry best practices. PCI requires system configuration standards to be applied with file integrity monitoring to ensure configuration files are not altered without the system administrator's knowledge (requirements 2.2.c and 11.5 respectively). File integrity monitoring does not evaluate whether a system is appropriately hardened against attack.

Implement log monitoring software to detect security events. Log harvesting, parsing, and alerting tools are listed as optional for monitoring logs in requirement 10.6. It is not practical to conduct manual log reviews daily. In a recent report, 66 percent of victims had sufficient evidence available within their logs to discover the breach had they been more diligent in analyzing such resources[v]. Implement log monitoring software and a process to ensure alerts are monitored and responded to.

Include a testing component to evaluate comprehension of security topics and policy. Requirement 12.6.1.b addresses employee security awareness training upon hire and at least annually. As a best practice, test each employee's comprehension through the use of a questionnaire. A social engineering penetration test can be used as an alternate testing component.

Scenario Conclusion

The above section is not intended to be an exhaustive analysis of PCI requirements. Instead, it is an example of findings from a risk assessment. Conduct feasibility studies for each FMEA recommendation. Determine the cost of a solution and technology constraints such as performance impact from encryption. Management should be aware of inherent risk to make informed decisions before feasibility and cost decisions are made without their knowledge.

In this example, senior management had a low risk tolerance due to compromises in the industry and related business impact to the affected companies. In the risk community, the term Black Swan[vi] refers to events with the potential for severe impact to business and a low rate of occurrence. Business continuity planning is an example of preparation for a Black Swan. Risk assessments are necessary under the same rationale.

VI. Provide Guidelines for Risk Mitigation

When a risk assessment identifies a vulnerability that exceeds the risk tolerance of your organization, it is necessary to address the gap. Here is a listing of controls that mitigate risk above and beyond PCI requirements:

Implement two-factor authentication to restrict access to PCI systems from the internal network. Requirement 8.3 addresses two-factor authentication for remote access originating from outside the network. Use of the same technology internally helps prevent compromise from unauthorized personnel by minimizing the risk of password disclosure.

Implement Network Behavior Analysis (NBA) to detect unusual activity. NBA monitors for changes in established network traffic patterns. It is particularly useful for detecting malware or other malicious activity. NBA can detect if a system passes traffic to another system for the first time or when an unusually large file is transmitted. It can also send alerts when a new protocol is used.

Use Application Whitelisting to protect against malware and viruses. Whitelist software allows authorized programs to run and blocks all others. It takes the opposite approach to signature based anti-virus software, which blocks known exploits. Whitelisting can effectively block polymorphic viruses, which change each time they run.

Use Data Loss Prevention (DLP) to prevent leakage of card numbers over unauthorized networks. Implement DLP at network choke points such as an Internet network connection. Use host-based DLP to detect card numbers stored outside of the PCI environment and to prevent data loss through USB flash drives.

Use Database Activity Monitoring (DAM) to monitor database queries for malicious activity. After establishing a baseline, configure DAM to deny requests for more than a certain number of card numbers. DAM also includes audit trail functionality and can record a history of queries.

Use Tokenization to replace Primary Account Numbers (PANs) as unique identifiers. Tokens reduce the risk and cost associated with processing card transactions. PCI compliance requirements are tied to PANs. Tokenization can be used as an effective scope reduction technique.

Conduct an adversarial security assessment. Compliance is a first level of maturity. Risk management is the second. As a final level of maturity, conduct a thorough, unscripted, adversarial assessment that exceeds the PCI requirement for a penetration test. For example, use an elite information security firm to align techniques with organized crime resources. When a physical or technological barrier challenges core capabilities, engage additional resources to penetrate further. Conduct the assessment over a month or more. Include social engineering within the scope of the test.

The above techniques may be cited as compensating controls, depending on the situation. Document optional controls as company guidelines for securing payment card data.

VII. Report and Present

Consider each PCI environment with a focus on operational risk. Do not skew results of an assessment for financial or political reasons. A decision made at the business unit or Line of Business level can impact the organization as a whole in the event of a compromise. Transparency is warranted. Executives should determine risk tolerance and have ultimate control of the budget and funding.

Finalize the risk assessment report with empirical data to support development of a business case for funding. Refer to the ISACA Risk IT Framework for industry standard methods to communicate risk. Present findings to executive management, including ongoing remediation and plans for the next risk assessment. Funding for security enhancements should be deducted from the cost center associated with revenue for the related product or service.

VIII. Conclusion

In the years that follow, consider using an external firm with PCI experience to lead the risk assessment. Use of an independent third party helps ensure risk assessment is comprehensive, versus a "check the box" exercise. Rotate methodologies each year. For example, use a PCI Qualified Security Assessor one year and an information security firm the next.

Organized crime represents an Advanced Persistent Threat to PCI environments. It is impossible to secure payment card data with absolute certainty. Maintain compliance with PCI requirements and remediate risk assessment findings. There is severe reputational damage and financial impact associated with a payment card data compromise. Each organization must protect card data in accordance with business objectives. Failure is not an option.


About the author: Gideon T. Rasmussen, CISSP, CISA, CISM, CIPP is a Charlotte-based Information Security Manager with over 10 years experience in Fortune 50 and military organizations. His website is www.gideonrasmussen.com. The opinions expressed here are those of Gideon Rasmussen and do not necessarily represent those of his current or past employers.



[i] "2009 Data Breach Investigations Report" by the Verizon Business RISK team, April 15, 2009.
[ii] "Payment Card Industry (PCI) Data Security Standard, Version 1.2.1", by the PCI Security Standards Council, July 2009.
[iii] "Failure Mode and Effects Analysis" from Wikipedia, the free encyclopedia, March 7, 2010
[iv] "Procedures for Performing A Failure Mode, Effects and Criticality Analysis, MIL-STD-1629A" by U.S. Department of Defense, November 24, 1980.
[v] "2009 Data Breach Investigations Report" by the Verizon Business RISK team, April 15, 2009.
[vi] “The Black Swan: The Impact of the Highly Improbable”, by Nassim Nicholas Taleb, April 17, 2007.





Originally published in (IN)SECURE Magazine (September 1, 2010)



image
image