Those that are familiar with this blog may have heard it said more than once that the United States lags far behind Europe with respect to the protection of consumer information.  The European Union, in fact, has been operating under the penumbra of the European Directive on Data Protection for 15 years.  The EU actually recognizes the protection of personal data as a fundamental human right.   That is a far cry from the legislative activities surrounding data privacy in the United States.  The US has traditionally take piecemeal approach to data protection, often leaving the regulation of data privacy and security to the states, and in some cases to individual industries.  Given the political culture of the United States, such an approach is not terribly surprising.  However, the rapid advancement of technologies has perhaps been enough to spur the federal legislature into evaluating the lessons of the EU directive to see if, or how, similar regulation might work in the US.

On Friday, Sept 16th, the House Energy & Commerce Committee’s Commerce Subcommittee will be holding hearings on the issue of privacy, and specifically the impact of the EU regulations.  In Rep. Bono-Mack’s published opening comments, she states “The purpose of the Directive is to harmonize differing national legislation on data privacy  protections within the European Union, while preventing the flow of personal information to  countries that – in the opinion of EU regulators – lack sufficient privacy protections.”  She goes on to discuss the large number of unintended consequences of the regulatory regime.  To be fair, unintended consequences are almost always found the in wake of new legislation, particularly such sweeping legislation as the EU Directive on Data Protection.  It should be noted, though, that with 15 years of implementation history and lessons, the US should be able to draw sufficient parallels without also reaping the same number of “unintended consequences.”

In looking at the purpose of the directive one can immediately see the attraction of such a regime in the US.  As stated by Rep. Bono-Mack, the purpose is to “harmonize differing … legislation on data privacy…”  In looking at the domestic regulatory landscape surrounding data privacy and protection, it is difficult to conclude that some “harmonizing” would not benefit both businesses and consumers.  As of this writing, more than 45 states have data breach notification laws.  While there are some major commonalitites to these laws, there are also significant variations.  There are differing definitions of “personally identifiable information,” “breach,”  “trigger,” and other critical terms.  Some states include data security protections in those laws, while others have separate laws for data security, and still others have no laws regarding data protection and security.  The situation becomes even more confusing when one considers the federal legislation impacting privacy and security (FERPA, HIPAA/HITEC, GLBA, SOX, etc) and industry self-regulating programs.

While there are some concerns that tomorrow’s hearing is too slanted towards industry, ignoring or downplaying the concerns of consumers, I believe that it is a positive step. Bill McGevern, professor of law at University of Minnesota does bring up an interesting point, though.  That is the different conceptions of data privacy between the US and Europe.  According to McGevern, Europeans think of privacy as a fundamental human right, while Americans (and particularly American businesses) conceive of privacy as a market force with which they have to deal.  That being said,  this author does believe that it is possible to create a European-style privacy directive that accounts for American sensibilities.

Dr. Heather Mark, PhD; SVP of 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

It is an interesting experience to search the term “data breach” on Google News, then scroll through the first five pages or so.  The number of well-known, well-funded entities reporting data breaches, even at a daily rate, is an impressive sight.  Cyber attacks are quickly earning the status of “all but inevitable” and business owners and other holders of personal data should ensure they are prepared to handle the consequences of such an attack.

One such consequence is the breached party’s responsibility for data breach notification. Forty-six states have adopted breach notification laws that govern an entity’s actions subsequent to a compromise of sensitive personal information.  Achieving compliance with the multitude of states’ data breach notification laws is a bit like arriving on the scene of an accident where dozens of victims require first aid but each has his or her own unique language, accepts help subject to an individual timetable, and requires an exceptional set of measures.  It is a complex process. 

In light of the difficulty in deciphering and complying with the multitude of laws, entity’s concerned with compliance should consider the following steps:

(1)  Develop a Data Breach Notification Plan.  Effective data breach notification plans will dictate internal team members’ responsibilities, contain model notices, and outline when, and under what circumstances, to notify law enforcement, regulators, and customers, since the timing of when customers in a given state should be notified is critical.

(2)  Know State Law Requirements.  Breached entities must be aware of the customer notice requirements on a state-by-state basis, including when and under what circumstances notice to those customers might be required, and whether less costly substitute notice is available.  Consider outsourcing this expertise as the sheer volume of statutes and annual changes in this arena requires almost full-time vigilance.

(3)  Create a Remediation Plan.  An entity’s response to a data breach is extremely important, both from an internal repair perspective, and external, public and customer relations perspectives.  It is advisable to create relationships with forensics, security, public relations, and legal experts in advance of a cyber attack and include those experts in the planning process.

(4)  Stay Current on Pending Federal Legislation.  Bills have been introduced in both the House and Senate over the past several years in an attempt to nationalize and bring some unification to the patchwork of states’ breach notification laws.  At least three have been introduced this session, along with a proposal from the White House.  A federal data breach law would likely preempt state laws and address some of the headaches associated with data breach notification, although consensus on the level of preemption and other issues, like the timing of notification have so far made passage into law a difficult proposition.  Nevertheless, if such legislation passes, and some experts believe this will be the year, entities subject to breach notification laws should be prepared to adjust their plan and notification requirements accordingly.

Over the weekend, details continued to emerge about a data compromise affecting  a number of companies, both large and small. According to reports, and a release on the company’s own website, the nexus of the breach appears to be an email marketing company called Epsilon.  Although the breach appears to have been contained to names and email addresses, the consequences of the breach have been widespread.  According to an article in eWeek, “No industry segment appears to have been spared. Epsilon has been updating its list of affected companies as it continues its investigation into the breach. As of April 3, the list included financial services institutions such as Capital One, US Bank, JPMorgan Chase, Citi and Barclays Bank of Delaware. However, the only Barclays Bank of Delaware customers affected were the ones who have an LL Bean Visa card.” The question that many people may be asking is “what’s the big deal about email?”  Many people wonder whether a breach of email addresses really poses any significant risk.

The answer to that question is, maybe.  The problem is that this will likely lead to an increase in phishing scams.  Phishers can now send very targeted emails that ask recipients for their personal information.  Due to the fact that the data thieves stole actual marketing lists from the company, their attacks may become increasingly sophisticated and difficult to detect.  For example, I know that the IRS is not going to send me an email requesting any personal information.  However, if a merchant with whom I regularly do business sends me an email asking about account information, I may be more inclined to respond.  (A quick note, most legitimate merchants and organizations will never send an email asking that you respond with any kind of personal information.  If you are in doubt, don’t call the number in the email or click on a link.  Find the contact information for the company independent of that communication and contact them directly.  Most likely they will tell you that the email is not legitimate and thank you for making them aware of the scam.)

The point of this story for consumers is a familiar one – be careful about sharing your personal information and don’t open emails or attachments from people that you don’t know.  The more interesting and impactful point of this story is for businesses.  Normally, such a maelstrom in the press would accompany the compromise of financial data.  Here, we see a significant amount of attention being paid to a compromise that does not include financial data or social security numbers, but email addresses.  Which begs the question, “Should email addresses now be considered as sensitive personal information?”  In some states, for the purposes of breach notification laws, email addresses are considered to be protected information.  Many companies, though, haven’t been overly concerned with the protection of email addresses, focusing instead on overtly sensitive data like account numbers.

The breadth of the recent email breach should make companies aware that every element of customer data has some value to thieves.  It will be interesting to watch how this incident evolves and what consequences might be in store for the compromised entity.  The outcome may have a dramatic effect on the way in which risk analysis and data classification are conducted.

Dr. Heather Mark, PhD; SVP Market Strategy