compliance:
PCI REQUIREMENT
12.1.2


IT IS IMPORTANT TO RECOGNIZE CHALLENGES
OF VALIDATING SMALL MERCHANTS HOUSED
IN SHARED HOSTING ENVIRONMENTS AND THE
POTENTIAL LIABILITY POSED TO ACQUIRERS.

by Chris Mark

    The publication of the newly minted Payment Card Industry (PCI) requirements marks a watershed moment in the payment services industry. Finally, the major card associations have agreed upon a single, comprehensive set of data security requirements with which merchants and service providers must comply. While the new standard should enable companies to pursue compliance and design their information security program more efficiently, it is not without some hidden pitfalls.
    A quick review of the PCI will likely leave many readers feeling as if the standard is simply an integration of Visa USA’s Cardholder Information Security Program (CISP) and MasterCard International’s Site Data Protection (SDP) program. While many of the original requirements were used as a basis, there exist some fundamental differences between the new PCI and the original standards. Arguably, one of the most significant changes can be found buried in one of the last pages and hidden among the more technical requirements. PCI requirement 12.1 requires that an information security policy be established, published, maintained, and disseminated. Requirement 12.1.2 expands on this:

12.1.2: (IS policy) Includes an annual process that identifies threats, vulnerabilities, and results in a formal risk assessment.

To the uninitiated, this new requirement may appear insignificant. In truth however, this single sentence may provide a significant obstacle to achieving compliance. To comply with the original CISP, a merchant or service provider needed only to read the requirements and implement controls listed in the document. As long as the organization had the appropriate firewall configuration, information security policy, and other controls outlined, they could feel confident in their compliance. Understandably, many companies developed their information security programs with an eye toward compliance and not risk management. With the addition of requirement 12.1.2 however, it is no longer enough to simply ‘paint by numbers’ using the card association standards as a basis to achieve compliance. Now companies must identify, understand and address the risk in their environment.
    To understand the potential implications of this requirement, it is important to understand the term ‘risk’ and ‘risk analysis/assessment’ as it applies to information security. Much of the following information was taken from the August, 2004 article titled: “Are You Vulnerable to Unnecessary Risk?” by Heather Randall Mark.
    The term risk is often used in information security and sadly, frequently used incorrectly. Many information security companies sell their security and vulnerability assessments as risk-assessments. An unfortunate result of such marketing is that many customers of these companies do not truly understand the concept or implications of a risk assessment. While there are many definitions of risk, a commonly used dictionary definition is as such: “someone or something that creates or suggests a hazard.” While a useful definition, this does not provide enough information for our purposes.
    Risk, as it is used in information security consists of three basis components; threats, probability, and impact. A threat is defined as any event that has the potential to cause harm to the assets of an organization. Vulnerabilities are weaknesses or susceptibilities to particular threats. The vulnerability and threat determine the probability of a threat being realized. Finally, impact is defined as the effect on the system, or network should the threat be realized. For our purposes, we will use another definition of risk: “the likelihood and impact of a particular threat affecting an organization.”
    The concept of risk can be displayed graphically as an equilateral triangle with each side representing a component of risk. If any of the components increase, this relates to an increasing length in the relative side and an overall increase in the area of the triangle and consequently, the risk.
    Building on the concept of risk, the term risk analysis or risk assessment can now be defined. A common definition of risk analysis is as follows:
    “The systematic examination (and prioritization) of the assets of a company or network, the threats to those assets, the vulnerability of the organization or system to those threats, and the impact should the threat be realized.”
    In general, there exist two types of risk analysis: quantitative and qualitative.
    Quantitative Risk Analysis attempts to quantify risk in terms of dollars. A common approach is to use the Annualized Loss Expectancy calculation for quantifying risk. In general, the ALE is determined by the following formula:
    Single Loss Expectancy x Annualized Rate of Occurrence = Annualized Loss Expectancy
    As an example suppose that the likelihood of a tornado hitting your house is 1 in 500,000 and that your house is valued at $350,000. Using the formula above, the ALE would be calculated as (350,000 x 1/500,000) = $.7 or 70 cents per year. Certainly some readers have identified a particular weakness in this type of equation. The equation used above assumes a total loss of the asset and does not allow for damage or partial losses. As one would imagine, using this type of equation in a complex IT environment with multiple variables would quickly become very challenging. While a number of types of quantitative risk assessments exist, most are very complex requiring significant time, resources and expertise to conduct with any degree of accuracy.
    Qualitative risk analyses are much more subjective in nature and do not rely on the complex mathematical models to achieve sufficient results. In most cases, qualitative risk analysis relies on expert opinions and experience from within the organization to make an ‘expert judgements’ regarding the criticality of assets, impact, perceived threats, etc. While the qualitative risk analysis approach may not appear as valuable as a quantitative approach consider the following example:
    A person drives a green, 1999 Land Rover Discovery II and lives in Mobile, Alabama on Oakwood Street. This person is considering whether to install a new $99 alarm to prevent their car from being stolen. Using a quantitative approach, they could review actuarial tables to determine the rate at which 1999 Green Land Rover’s are stolen on Oakwood street in Mobile, Alabama and then hire a an expert to calculate the ALE to determine if it is a worthwhile investment to install the alarm. Is all of this really necessary? It is likely that the research and effort alone will make this a very challenging and expensive undertaking. Using a qualitative approach, the same person can simply look up theft rates in Mobile, Alabama, talk to his or her neighbors to see if their cars had been broken into recently and make a subjective determination as to what he or she perceives as the risk to their vehicle. While this approach may not be able to provide an exact probability of a green 1999 Land Rover being stolen in Mobile, Alabama, it is probably enough to know that Land Rovers are being stolen more recently in Mobile and that his neighbor’s car was recently stolen.
    How does this help your organization? If your network is compromised and critical data is lost, a risk analysis can help your organization prove that it has conducted due diligence in the protection of its information assets. In general, companies have a responsibility to implement controls commensurate with the identified risk. In many cases, this may be sufficient to protect your organization from civil or legal liability. Risk analysis should be used as the basis of your company’s information security program. Risk assessments can help determine the controls that should be implemented to protect information assets. Without understanding the risks, companies tend to take a ‘fortress mentality’ and simply build their networks as strong as possible. This is neither an efficient nor cost effective means of implementing controls.
    When speaking to people about risk in their IT environment I frequently ask the following question:
    If I had $500 to spend on security for my house, would the money be better spent on a burglar alarm or on a fence with no lock designed to keep lions out? Invariably people will quickly answer that an alarm is a better investment. When I ask why, they reply that there is a greater risk of my house being broken into than having a lion attack me in my home. When I explain that I live in South Africa, which is currently having a rash of lion attacks, their answers change. The point being that when the risks are understood, educated decisions can be made about the types of controls to implement.
    There are currently a number of companies that can conduct risk analyses. For the courageous that wish to undertake a risk analysis on their own, a number of quality resources can be found on the Internet. A quick search on the following methodologies is a good start to understanding various risk analysis techniques: Octave, OSSTMM, BITSInfo, and COBIT. In addition, Thomas Peltier has written a very good book titled: Information Security Risk Analysis that discusses a process he calls the Facilitated Risk Analysis Process (FRAP).
    While risk assessments can be expensive and time consuming, your qualified PCI assessor can provide guidance on an efficient, appropriate assessment for your organization.