Last week, I attended the PCI SSC Community Meeting in Scottsdale, AZ.   The meeting is held every year so that stake holders in the payments industry can get together and discuss the PCI DSS and its impacts.  Each year brings with it new guidance documents, and sometimes new standards.  This year was no exception and the standard mix of new standards and new guidance was supplemented by discussion of new technologies (perhaps new is a bit of a stretch, as one of the “new” technologies under discussion was EMV – a technology that has been around for decades).  Mobile payments and Near Field Communications (NFC) were also hot topics of discussion and reminded of one my favorite topics – weighing the adoption of technology and its attendant convenience with the protection of payment data.

I am an advocate of a careful risk analysis – there are occasions in which a new technology does introduce risk, but that risk is outweighed by the potential benefit to customers and to the business overall.  In those instances, the organization may determine that the risk is acceptable and the technology is adopted.  In other instances, an organization may determine that the benefits are far outweighed by the risks and the technology is not implemented.  The point is that careful deliberation is sought.  Unfortunately, the current state of the market (economically difficult coupled with rapid technological change) may lead some companies to adopt a new technology as a “me too” strategy.  The appearance may be that by adopting new technologies companies are showing progress and leadership, which will lead to a competitive advantage.  Many times, though, the rapid adoption of new technology without proper vetting can introduce the “unknown unknown” into the environment.

The idea of the “unknown unknown” can be nicely summed up by saying that “you don’t know what you don’t know.”  In other words, one doesn’t have enough experience or knowledge about a particular subject to speak definitively about what its potential risks might be.  The concept was famously speared after Rumsfeld made his famous “unknown unknown” speech.  While pundits and comedians alike had a good time poking fun at Rumsfeld for his use of the terms “known unknowns” and “unknown unknowns,”  he is referencing something that risk analysts and philosophers alike have discussed for years. The premise of Nassim Taleb’s  The Black Swan is largely concerned with operating in a world in which we don’t know what we don’t know.  You can mitigate the number of unknown unknowns through analysis, evaluation, and research.

One of the ways that companies can mitigate the “unknown unknown” in terms of payment security is to evaluate new technologies against the standards established by the industry.  The standards are established to counter the known risks in the payment environment.  Any time a new technology is considered, a good practice is to consider how that technology would be integrated into the existing infrastructure and evaluate that result against the standards and against data security best practices )which sometimes evolve at a faster rate than the standards do.  Certainly this will not bring to light all possible permutations of risk that might arise from the adoption of a new technology, but it will help address an organization’s compliance status and may help mitigate the risk associated with adopting a new technology.

Dr. Heather Mark, PhD; SVP Market Strategy

In August, the PCI SSC released an updated version of its Wireless Guidelines.  The updates were not drastic, rather they were designed to bring the Guidelines into accordance with the PCI DSS v. 2.0 and to provide updates for Bluetooth technology, which was not contemplated in the original document.  This guidance document is important for companies seeking to achieve compliance for a number of reasons. Primarily because there is some disagreement as to whether an organization can be compliant if it uses a wireless network.  The short answer is “Yes, it can.”  However there are some caveats.  Those caveats will be briefly discussed here.

The first thing that one should know about wireless networks is that they are inherently more difficult to secure.  Therefore, while compliance with the PCI DSS is possible with a wireless network, it is not necessarily easy.  For instance, the network must support encrypted communications.  Further, that encryption method cannot be WEP, which was proved insecure several years ago.  In fact, the PCI SSC specifically states that WEP “must not be used” and was prohibited as of June 30, 2010.  Organizations using wireless networks must use WPA (Wifi Protected Access).  The guideline document further details specific protocols for the WPA encryption method, depending on the environment (SOHO, enterprise, etc).

Additionally, there is a tendency on the part of organizations to overlook the physical security of wireless access points.  This is particularly true if a company is using a fairly common access point, such as those that can be purchased at office supply stores.  However, these access points usually have common default passwords and are easily reset.  If an access point is left unattended, it would be a trivial matter for a criminal to hit the reset button on the access point and use those default credentials to access the corporate wireless LAN.

It may be easy, then, to subscribe to the notion that simply not using a wireless network is the easiest way to achieve compliance, and that may be true.  In fact the PCI DSS itself states, “Before wireless technology is implemented, an entity should carefully evaluate the need for the technology against the risk. Consider deploying wireless technology only for non-sensitive data transmission.”  It should be noted, however, that an organization should still be aware of the possibility of the “rogue access point.”  These are defined by the PCI SSC as those devices that do not have proper authorization.  According to the document, “A rogue AP could be added by inserting a WLAN into a back office server, attaching an unknown WLAN router to the network, adding a Bluetooth base, or by various other means.”  For that reason, PCI DSS Requirement 11.1 mandates that organizations scan for the presence of wireless access points on a quarterly basis.  This way, even companies that may not be running a wireless network can detect unauthorized devices that may impact the security of their network.

In short, companies should carefully evaluate the need for a wireless network in their environment.  In making this decision, it is highly suggested that the Wireless Guidelines be used to help determine the right forward for each individual company.

Dr. Heather Mark, PhD.  SVP, Market Strategy

It’s been a busy month for the Payment Card Industry Security Standards Council (PCI SSC).  In August the PCI SSC, the organization charged with managing and disseminating security standards related to cardholder data, released two new guidance documents.  One of the documents provided guidance on selecting or building tokenization solutions while the other was concerned with wireless networking security.  While the wireless guidelines document is an updated version of the existing document, the industry has been awaiting the tokenization guidelines for some time.  In this post, the PCI DSS Tokenization Guidelines will be discussed.  The Wireless Guidelines will be discussed in a subsequent post.

Since its introduction to the payments industry, tokenization has been heralded as one of the most effective ways to meet compliance with the PCI DSS.  This has led to a long debate among security professionals about the proper implementation of tokenization solutions for the purpose of achieving and maintaining compliance.  Without the voice of the PCI SSC, there was some trepidation about just how much reduction of the compliance effort could be achieved with tokenization solutions.

The new guidance document for tokenization offers “Key Considerations for Tokenization Operations.”  Among these considerations is the ability to retrieve cardholder account numbers from the Primary Account Number (PAN). If the organization still has the ability to recreate the PAN using the token then no benefit with respect to reduction of PCI scope will be achieved.

Another important clarification introduced in the guidance documents is that there must be a way to distinguish between the token and an actual card number.  This is particularly important as an increasing number of tokenization providers offer tokens that are virtually indistinguishable from card numbers.  They are 16 digits and will bass the Luhn test, which is a signifier of valid card number.  The PCI SSC offers several reasons for this guidance.  According to the document, “Without the ability to distinguish between a PAN and a token, the merchant or service provider may not realize that the tokenization system isn’t functioning as intended.  Additionally, PANs could be mistakenly identified as tokens, which can lead to mis-scoping of the CDE [cardholder data environment] and the possibility that the PANs are left unprotected and open to compromise.”

The document further outlines the differences between an “on-premises” solution and an outsourced solution.  An on-premises solution is one in which the merchant maintains control over the entire tokenization solution, including the system that creates the tokens.  The responsibility in this case rests solely on the merchant to maintain the security and compliance of the system, as the tokenization system, and the systems connected to it, are always in scope for PCI DSS.  An outsourced solution, on the other hand, significantly reduces the merchant’s scope.  The document then goes on to detail the responsibilities of the various parties relative to the tokenization system.

The tokenization document should prove extremely helpful for merchants that are in process of evaluating a tokenization solution.  It will allow merchants to develop their own metrics for determining the correct solution for their environment and for their abilities and resources.

Dr. Heather Mark, PhD; SVP of Market Strategy

These are common eCommerce related security questions we hear from merchants.  Hopefully, this will help some merchants in their pursuit of compliance and security.

If I don’t store credit or debit card data, do I have to comply with the PCI DSS?  Yes.  The PCI DSS applies to any organization that either stores, transmits, or processes payment card data.  Simply not storing data does not relieve your company of their obligation to comply with the standard.

I use anti-virus software.  Can I still get a virus on my computer? Yes.  Anti-virus and other malicious software protection typically uses signatures to detect malicious software such as viruses.  Unfortunately, until a signature is created and your anti-virus is updated, you may still have malicious software on your system that is undetectable. 

Doesn’t a firewall prevent hackers from getting into my systems? No.  Firewalls doe not prevent all traffic from entering and exiting your network they simply restrict access to specific ports and services.  If, for example, your company has a web server, then  your firewall would need to allow port 80 (HTTP) inbound to allow people to access your website.  It has been estimated that almost 99% of exploits are specific to HTTP.

Doesn’t encryption protect my data from being stolen? Maybe.  Encryption prevents unauthorized personnel from being able to read the data.  The weakness in any encrpytion solution is that it relies upon keys to encrypt and decrypt the data.  If the keys are not adequatly protected then they can be compromised and the data can be accessed.  Also, it is is important to remember that it only prevents unauthorized people from accessing the data.  If a data thief can obtain the logon credentials of an authorized user, they can simply use those credentials to access the data.

How do data theives get into my system? Unfortunately, people often invite them in.  “Drive by” infections of malicious software are often the main vectors in which malicious software such as trojans, viruses, back doors, etc. are planted on systems.  In drive by infections a user will access an infected website while surfing the Internet and the website will infect the system.  For this reason, it is important to filter and control Internet access.

Hopefully these simple answer provide some value to those trying to understand some of the threats facing their company.

This is part 2 of a recent post: “Smoke and Mirrors; What are they really saying?” In reading an article on the ETA website today I found a statistic that did not seem quite accurate.  It stated that: “PCI Compliant merchants fare better, but 36% still report breaches over 2-year span.” In reviewing the article the statistic was taken from the The 2011 PCI DSS Compliance Trends Study was released in April of this year.  After reading the ’study’ I had to admit I was somewhat taken aback.  Two major items stuck out immediately.

1) Respondents ’self reported’ and were “…deemed to be PCI compliant if they chose “all” or “most applications and databases are compliant.” According to the definition 66% of companies were ‘deemed’ compliant.   This definition is inconsistent with the PCI SSC’s, and the card brands’ definition of compliance which is meeting compliance with all application PCI DSS requirements.  Even using the more liberal interpretation, only 33% of the respondents should be considered ‘compliant’.  Additionally, it does not differentiate between when the companies were reported (self, I might add) “compliant” and when the “breach” occurred.  It simply asks if the company was ‘all’ or ‘mostly’ compliant and whether they had a breach.

2) While the study references data breaches numerous times and survey questions Q8a and Q8b ask about data breaches, there is no definition of “data breach” provided in the study.  Is an anti-virus infection considered a data breach?  Is a data breach defined as an intrusion which exposes confidential or protected personal data?  Is encrypted data that is exposed, considered a data breach?  Without a consistent definition, there is no way to understand the intent of the respondent.  It is possible that many respondents feel that a virus infection is a data breach.

Another interesting comment is found on page 1, paragraph 3 of the study.  It states: “In fact, virtually all (99 percent) compliant organizations in this study report that they have had only one or no data breaches involving credit card data compared to 85% of non-complaint organizations that had one or no such breach incidents.” What?!?  Having one breach involving credit card data is a bad thing and requires reporting to the card brands.  It then goes on to state that: “…the percentage of respondents reporting that their organization had a data breach in the past 24 months increased from 79% to 85% in 2011.” These numbers are difficult to understand and more difficult to believe.   So, reading these two statistics together, it appears that 85 of organizations (doesn’t say compliant or non compliant) had a breach in the previous 24 months.  Given that there are 6.5 million merchants in the US, if this represents a statistically valid representative sample, it would suggest that roughly 5.5 million companies experienced a breach in the previous 24 months.  This certainly seems unlikely.  It is more likely that the ’self reported’ breaches include virus infections, web server vulnerabilities and other issues that are not considered ‘data breaches’.

While it is important for companies to understand that protecting data is critical to their company’ success, it does not help to provide information that spins data in an attempt to support a pre-defined position.  When I first began working in data security I learned a new word.  FUD.  FUD Is an acronym for Fear, Uncertainty, and Doubt and is how many companies choose to sell security products.  In essence, you scare the heck out of your clients and they buy the products.  The lesson to be taken from this post is to continue to critically analysis statistics that are provided.  Sometimes a close look will reveal information that is not quite as it seems.