Entries tagged with “QSA”.


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.

Yesterday while at the supermarket I played one of my favorite marketing games and looked on the back of a can of supplements to see if any interesting statements or disclaimsers were used.  The number of qualifiers and disclaimers were incredible yet the language was clearly crafted to convince prospective buyers of the benefits of using the product. The qualifiers are highlighted in bold while the disclaimers are underlined.

“Vitamin D is being investigated for breast health benefits. While no medical consensus yet exists, emerging science suggests there may be a correlation between adequate levels of Vitamin D and breast health. More research is needed.”

In reading a recently published report pertaining to PCI DSS compliance and data breaches I found some interesting language that gave pause.

From these results, it cannot be said that the PCI DSS fails to address the most prevalent threats to cardholder data.”

While it certainly appears that an attorney crafted the language it seems to contradict the purpose of the report. Additionally, inaccurate or incorrect statistics and methodologies are worse than no statistics or methodologies. The methodology section of the report states;

“…QSAs perform hundreds of PCI assessments each year. For several reasons, this report does not include them all. Rather, a simple selection process was used to create a sample of these reports for inclusion in the study…”

To conduct a statistically valid study a statistically valid representative sample should be used. Without a valid sample, the results are spurious, at best. To give credit to the report, the language does provide clarification and a disclaimer stating that: “from these results…”. In short, the report is little more than information presented in a format to look like a formal, statistically valid study. While it provides interesting reading “…it is suggested by the author “…that readers should evaluate whether they want to consider using the information to formulate a recommended strategy for considering security.” The last sentence was an effort to use levity and was intended to highlight the point I was making.

The purpose of this blog post is not to disparage or criticize rather it is intended to point out common tactics used to convince readers of a position when little or no real valid evidence exists. Data security thrives on using numbers, statistics, and implications, and innuendo to sell products and services.

When reading reports, labels, claims, summaries, and statistics read with a critical eye looking for validity, accuracy and relevance. While a report, label, or claim want a reader to infer one message, it may in truth have little basis for such inference. A great reference for learning about statistics and one what many readers may be familiar with is the ever popular “How to Lie with Statistics.” First published in 1954, it is still relevant today.

Chris Mark

Yesterday I was on a call with a service provider attempting to explain the PCI DSS requirements and card brand mandates when it became apparant that the person on the other end of the phone did not understand their company’s PCI DSS responsibilities and had an very limited understanding of security in general.  As frustrating as it was for me personally, I was more concerned about the merchants using this particular company’s services as the merchants are likely unaware of the risk to which they are exposed.  If you are a merchant using a third party or a third party with questions, hopefully this post will help shed some light on the responsibilities.

In an attempt to provide some clarification on the PCI requirements for service providers,  I will use excerpts from the card brand websites. (also to assuage any fears that I may be misrepresenting or misinterpreting the rules in my post ;)

As stated on Visa’ website: 

“PCI DSS compliance is required of all entities that store, process, or transmit Visa cardholder data, including financial institutions, merchants and service providers. The PCI DSS applies to all payment channels, including retail (brick-and-mortar), mail/telephone order, and e-commerce. Visa Inc.’s compliance programs manage compliance with the PCI DSS with the required program validation.”

Quite simply, if you store, transmit, or process cardholder data then you must comply.  Even if your company does not store data you may be processing or transmitting which means the PCI DSS requirements apply to your organization.  Hosting companies, gateways, processors, back end service providers, CRM, etc.etc.  There ar literally hundreds of companies that fall into the “service provider” category and they must all comply if they store, transmit, or process cardholder data.

At this point some are likely asking “who says I have to comply?”…as stated on Visa website:

“Members (Visa member banks) must comply with the PCI DSS and are responsible for ensuring the compliance of their merchants, service providers, and their merchants’ service providers. Acquirers must include a PCI DSS compliance provision in all contracts with merchants and agents. Specific compliance requirements and validation criteria are provided at this website.

In short, acquirers’ are responsible for their merchant’ compliance and this includes ensuring that their merchant’s use compliant service providers.  Specifically requirement 12.8 of the PCI DSS mandates that companies use service providers that are compliant with the PCI DSS.  The acquirer has liability for the merchant which includes liaibility should the merchant use a ‘non compliant’ 3rd party. 

As stated on Visa’ website:

“If a member, merchant or service provider does not comply with the security requirements or fails to rectify a security issue, Visa may fine the responsible member.”

It goes on to state:

“Both issuers and acquirers must use, and are responsible for ensuring that their merchants use, service providers that are compliant with the PCI Data Security Standard (DSS). Although there may not be a direct contractual relationship between merchant service providers and acquirers, Visa issuers and acquirers are responsible for any liability that may occur as a result of non-compliance.”

So what is a Service provider?  In the Visa world there are two basic types of service providers.  VisaNet Processors (VNP)  and Third Party Agents (TPA).  At last count there were only about 90 VNPs.  The vast majority of Service Providers will fall into the TPA category.  As stated in the Visa TPA FAQ document.

“A TPA is an entity, not connected to VisaNet, that provides payment-related services, directly  indirectly, to a Visa client and / or stores, processes or transmits Visa account numbers. TPA perform multiple functions on the issuing and acquiring side of a Visa client’s business.” 

In the MasterCard world,  service providers are either Third Party Processors (TPP) or Data Storage Entities (DSE).  As stated on the MasterCard website:

“In the SDP Program, Service Providers is a collective term for Third Party Processors (TPPs) and Data Storage Entities (DSEs). Web merchants contract with Service Providers to facilitate many business functions, including, but not limited to, offering and selling their content online, payment services, hosting applications and processing.”

By this point in the post it should be clear that if a company stores, transmits, or processes cardholder data then they are required to comply with the card brand rules including those mandating compliance with the PCI DSS.  All service providers are required to validate compliance with the PCI DSs through either (depending upon their classification) completion of a Self Assessment Questionnaire and network scan OR completion of an onsite assessment by a Qualified Security Assessor and completion of a network scan.  These are the only two options to validate compliance with the PCI DSS for Visa and MasterCard and all service providers are required to validate.  This can be confirmed by reading the MasterCard and Visa websites.

In addition to complying with the PCI DSS, service providers are also required to register with Visa and MasterCard.  Visa’ registration information can be found at this link.

In summary, if you are a company that stores, transmits or processes (even if you don’t store) cardholder data then you must comply with the PCI DSS.  If you store, transmit, or process cardholder data for merchants then you are a service provider and must comply and validate compliance and register with the card brands.  Requirement 12.8 of the PCI DSS standard requires that only compliant service providers are used to store, transmit, or process cardholder data.  In addition, the card brands mandate that service providers comply, validate and register and the card brands hold the merchant’s acuirers liable for any service provider that is not in compliance with the rules.

To gain more insight into the rules you can read some previous posts on this blog or visit the card brand websites.

 

I served a number of years in the US Marines and find the current PCI environment similar to that which I experienced in the Corps.  There are a number of people who remind me of what we used to derisively refer to as “baracks lawyers” or “squad bay lawyers”.

barracks lawyer –noun a member of the armed forces who speaks or acts like an authority on military law, regulations, and the rights of service personnel.

A quick read through the numerous blogs or other information sources will reveal literally hundreds of people speaking with absolute authority on the nuances of PCI compliance.  While some are certainly more familiar than others on the topic, it is worth investing in an actual expert if you have a need for PCI help.  In much the same way a person that needs a real attorney would be foolish to listen to the musings of the barracks lawyer. 

I have been writing quite a bit about knowing your rights and knowing the PCI DSS issues.  Here is a very real example of how knowing the real facts can be helpful and not knowing the real facts can cause some real pain. 

A few weeks ago I was in a very minor fender bender in Utah.  The police officer came and discussed the situation and gave me a ticket for ‘unsafe starting’.  I felt that I was in the right so instead of ‘pleading guilty’ I discussed my options with an attorney.  Unbeknownst to me the ‘ticket’ I had received was not a simple traffic citation but was really a Class ‘C’ misdemeanor…a crime!  If I had simply pled guilty to what I truly thought was a simple ticket (it was writte on a ticket, looked like a ticket, was for a ‘traffic violation’) I would have pled guilty to an actual crime (class C misdemeanor).

This same situation occurs on a daily basis in the payment card industry.  Some company will engage a well intentioned, albeit uninformed consultant or vendor to help them with PCI issues.  Based upon the advice confidently doled out by the consultant the company will modify their security practices or otherwise pursue what they believe are actions that will bring them into compliance with the card brand rules.  It is often not until it is much too late that the company realizes that the sage advice they had received was not as accurate as they had been led to believe and the company finds that they are ‘non compliant’ or facing some penalty from the card brands. 

The moral to the story is that ‘barracks lawyers’ and other self proclaimed experts are typically not malicious but not really understanding the rules can have far reaching consequences for those who take their advice.  It is imperative that any merchant or other company that needs to comply take action to engage consultants and vendors with demonstrated expertise and knowledge and stear clear of ‘barracks lawyers’.

Chris Mark, EVP; Data Security & Compliance
 

In reading the news this morning, I ran across an article about an engineer for a search engine company that was terminated for accessing user accounts without authorization.  In the comments following the article, there were a number of comments about data security and privacy, but the definitions often converged.  Very often, we hear the terms “security” and “privacy” used interchangeably.  Sometimes,  security is a sub-heading under a website’s privacy policy and vice versa.  There doesn’t seem to be a lot of thought devoted to just what the differences between the two might be.  It is true that they are very intricately entwined and one often follows the other, but – and make no mistake – it is possible to have poor privacy and good security practices.  However, it is difficult to have good privacy practices without a sound, comprehenisve data security program.  So, just what are the differences?

Data security, according to common definition is the “confidentiality, integrity and availability” of data.  This is commonly referred to as the CIA triad in Security 101 parlance.  It the practice of ensuring that the data being stored is safe from unauthorized access and use, ensuring that the data is reliable and accurate and that it is available for use when it is needed.

Privacy, on the other hand, is the appropriate use of information.  In other words, merchants and companies should use the data provided to them only for the intended purpose.  For example, if I make a purchase from XYZ Company and provide to them payment and address information in order for them to ship the product, they cannot then sell my information to a third party (unless they have disclosed the practice to me prior to my purchase and I approved it).  The Federal Trade Commission has instigated enforcement actions against companies that have done just that, accepted private information from individuals and then sold, rented or otherwise disclosed that information to third parties without prior approval.

In terms of their relationship to one another, I often look at data privacy and data security as symbiotic.  Privacy is the true objective of security.  I’ve been in the world of regulatory compliance, data security and privacy issues for sometime now, and it is rare that I’ve seen companies undertake security for the sake of security.  Most often, security programs are put in place to protect the privacy of consumers’ information.  Without appropriate security programs in place, it is very difficult to ensure that no unauthorized access or use (referred to above as “appropriate use”) of consumer information has taken place.  Conversely, one can have excellent data security practices, but fail to take the administrative measures necessary to ensure that data isn’t being inappropriately shared with third-party service providers.  The Company XYZ example above illustrates that point – data compromise doesn’t derive solely from technology or vulnerabilities in the network.  A data compromise can just as easily occur because a doctor’s office was sharing patient information with a drug company for marketing purposes without getting the consent of the patients in question.

While the relationship between data security and data privacy cannot be comprehensively addressed in short blog post, the important thing to take away is that the objective of data security programs is the protection of data privacy – whether that is the non-public personally identifiable information of clients or the company’s intellectual property.  Security is the ends to a means – privacy.  And we cannot rely solely on technology to ensure privacy.  Privacy, like security, requires constant monitoring and evaluation of practices and the threat environment, as well as education and awareness programs for employees.

Heather Mark; SVP, Market Strategy