Archive

Posts Tagged ‘PCI’

ATMs: PTS, PCI DSS, or PA-DSS?

November 8th, 2009 admin No comments

A friend of mine and well known expert on the PCI standards, Branden Williams, blogged about “Does PTS apply to ATMs?“  For those of you still reading that question, PTS stands for PIN Transaction Security and was formerly known as the PIN/PED program.

The important question is which standard do you apply to automated teller machines (ATMs) which seem to exemplify the need for each standard to one degree or another.

Branden reminds us:

ATMs are payment devices just like the card swipe or chip & pin machines we see at mearchants all over the world.  The only difference is that they typically have larger displays, are heavier and more physically hardened, and they spit out money on request.  They’ve also become a great target for hackers to prey on the trusting human (with a fake ATM), or to add sophisticated skimming devices to steal and take advantage of consumer payment data.

It is important to not compartmentalize systems into Procrustean boxes and instead break them into their respective parts.  For example, a company may be both a merchant and a service provider (e.g. Amazon.com or Internet Service Providers).  In the same way an ATM can be broken down into its respective parts and the standards which apply.

  • PTS applies to the PIN pad component
  • PA-DSS applies to the software running on it (potentially)
  • PCI DSS applies to the company that drives the ATM network
Categories: PCI Tags: , , , , , ,

What does Regulatory Compliance have in common with Immunization?

November 8th, 2009 admin No comments

I don’t think many people have ever asked themselves what regulatory compliance has in common with immunization, but they should.  The fact of the matter is that these two have more in common than you think and understanding one will help you better understand the other and how to make better educated decisions.  In addition, there are trade-offs — both heath and economic — to the choices one makes in participating in vaccination and immunization programs.  The following addresses a few of these items and opens the doors for further conversation.

Why Comply? Why Vaccinate?

Immunization and vaccination are the process by which an individual or population is treated in order to fortify itself against attack from foreign bodies.  Vaccination against disease can help prevent contracting that pathogen in the future, and preventing multiple individuals in a population from becoming infected helps prevent the widespread outbreak and transmission of diseases such as smallpox, polio, measles, mumps, and anthrax.  By elevating the level of a population that is resistant to such attacks vaccines help protect the entire population from harm.

The problem is that although most all agree that vaccination is positive for the population not everyone agrees that it is positive for the individual.

Since vaccination began in the late 18th century, opponents have claimed that vaccines do not work, that they are or may be dangerous, that individuals should rely on personal hygiene instead, or that mandatory vaccinations violate individual rights or religious principles.

Have we not heard similar arguments against regulatory compliance?  Individuals stating that:

  • My environment is already secure
  • I know how to manage risk better than the regulatory bodies
  • My environment is special and unique and does not fit into your Procrustean boxes

I’ve listened to people sing the virtues of regulatory compliance as often as I’ve heard other individual tell me “that sounds good but it’s not for me.”  I feel as if I’m mediating between the Center for Disease Control (CDC) and a troubled parent about why their child should be vaccinated before entering grade school.

Perspective

Part I

One of the problems with understanding the complexity of the problem is that of perspective.  The CDC and the parent have very different perspectives on vaccines and immunization.  In the same way, the regulatory bodies and those who must comply with them have very different views on how to best apply data security practices.

For example, it is widely known by the payment card industry (PCI) that the majority of small and medium merchants use one of a few brands of payment application.  Many retail merchants use a Micros, VeriFone, or Radiant Aloha (restaurants) point of sale (POS) application.  This high level of homogeneity in a population lends itself to attract attackers (pathogens) who wish to take advantage of any vulnerabilities they can identify in these systems.

The PCI Council, who act as the CDC, along with the card brands mandate that software companies validate their applications against a given security standard (in this case the PA-DSS).  They then introduce these more secure applications into the population and the governing bodies mandate their use over less secure payment applications.

So why not just stop there?  If things were that easy, the CDC would only ever have to worry about one pathogen using one attack vector.  If we secure the retail payment applications, attackers will just move to other industries such as petrol (gas) stations, ski resorts, and florist shops.  To which the industry responds with Dresser Wayne or Gilbarco, SKIDATA, and Teleflora Dove validated payment applications respectively.  The validated payment application program targets to inoculate every industry against the dangers of retaining data most valuable to attackers.

Part II

But what about the individual restaurant owner who says they don’t need a validated payment application?  They claim all the reasons mentioned above from the specialized nature of their business or network to the secure risk management platform they have already implemented.  Why should they comply?

I do not have a good answer to the ‘why’ but I do have one for the ‘how’.  In fact, about 95% of the ‘PCI Wars’ debate going on today try to answer the question of “why” when this is as futile as debating intelligent design vs evolution (because both are based on separate and unequal premises.)  Debating why one should comply is futile as the rules state that everyone who “stores, process or transmits” such data must comply (as per the card brand operating regulations.)

The more interesting question is that of how one should comply.  These examples reference the PCI standards but could apply to just about any regulatory compliance mandate.  The way in which one complies can be taken at a high level.  For the PCI standards it implies preventing the paper and electronic theft of payment card data.  In fact, any way that your company decides to do this implies compliance with the standard.

If parents didn’t mind sending their children to school in hermetically sealed bubbles, then there would be less of a public policy need for them to be vaccinate against disease.  In this way, the parent and child could make their own decision about data security without harming or posing a risk to the rest of the population of school children and their parents.  If your company can, via whatever means at your disposal, hermetically seal itself against attacks then the matter of compliance is simply an exercise for the user in creative documentation, reporting, and compensating controls.  The problem is, many companies over estimate their security controls and thus cause a break in the structure of data security.

Economics of Immunization and Compliance

When approaching the economics of immunization one cannot ignore the population at hand.  For example, a poorer population will benefit more strongly from an immunization program than one that maintains a high level of sanitation, health care, and treatment programs.  To the same degree a more vulnerable population (e.g. retail, restaurants, higher education, e-commerce, etc.) will benefit more from regulatory compliance than one that is more highly secure (e.g. government systems).

In fact, one of the primary catalysts for regulatory compliance is the build up of problems (e.g. data breaches) within an industry followed by the punctuated equilibrium that brings about a response founded in legislative and regulatory action.

The cost of making a population more secure is relatively simple: require them to use more secure applications and systems.  The cost to the individual can vary along with the benefits.  The same applies to vaccines.

One could go their entire professional life without contracting the flu but this is rather rare in my experience.  Instead many people will get the flu vaccine each year on the off chance they will come in contact with the virus because being bed ridden for 1-2 weeks can be both painful and detrimental to the company.

So what!

The cause of action to vaccinate a population is to immunize them from each other.  The process involves a uniform across the board preemptive treatment that is meant to mitigate risks, not prevent them entirely.  In the same way, regulatory bodies craft legislation as a one-size-fits all in order to protect the population from each other.  The individual implementation should see this as guidance and not a rule without exceptions.

The details of how one protects themselves against attack and infection may be unique to each individual, but they still must comply with the overarching industry agreement to protect themselves and thus the population against attacks.  The implementation will vary, of course it will.  One size does not fit all.  But the industry needs a standard, a baseline, against which it can measure risk.  As new infections and outbreaks occur, the industry will change the baseline to match the new attacks.

Those who can visualize the various perspectives will have a greater visibility into how they can better fortify their individual organizations to both validate against industry mandates and manage risk based on their specific organizational behavior.

When are data breaches just outliers?

August 19th, 2009 admin 6 comments

Recently the large story to hit the news, the thing people are all reading and writing about, is the story about how 1 guy (and 2-5 accomplices) were able to steal 130 million payment-cards in over three years, and finally got caught.  The question is, what if Albert “Segvec” Gonzalez (aka. Cumbajohnny) is an outlier?  A statistical anomaly.

Facts of the Case

Rich Mogull has a good overview of the indictmentWired magazine, the Washington Post (Brian Krebs), and the Wall Street Journal all have coverage.  Rich has an interesting comment that:

In the “drama” category, we learn that the main perpetrator is the same person who hacked TJX (and multiple other retailers), and was the Secret Service informant who helped bring down the Shadowcrew.

This indictment covers breaches of Heartland, Hannaford, 7-Eleven, and two “major retailers” breached in 2007 and early 2008.

This is the same Albert Gonzales who was indicted last year for breaches of TJ Maxx, Barnes & Noble, BJ’s Wholesale Club, Boston Market, DSW, Forever 21, Office Max, and Sports Authority.

The attacks both sniffed traffic and attempted to identify stored card numbers. They targeted data at rest and in motion.

The Wired article adds:

But these are just the latest in a string of high-profile breaches that have been connected to Gonzalez. He and 10 others were charged in May and August 2008 with network intrusions into TJX, OfficeMax, Dave & Busters restaurant chain and other companies.

Using a SQL-injection attack, the hackers allegedly broke into the 7-Eleven network in August 2007, resulting in the theft of an undetermined amount of card data. They allegedly used the same kind of attack to infiltrate Hannaford Brothers in November 2007, which resulted in 4.2 million stolen debit and credit card numbers; and into Heartland on Dec. 26, 2007. Of the two unnamed national retailers mentioned in the affidavit, one was breached on Oct. 23, 2007, and the other sometime around January 2008.

Gonzalez was a Secret Service informant who once went by the nickname “Cumbajohnny.” He was a top administrator on a carding site called Shadowcrew when he was arrested in 2003.

Gonzalez called his credit card theft ring “Operation Get Rich or Die Tryin.” As Wired.com previously reported, he spent $75,000 on a birthday party for himself and once complained to associates that he had to manually count $340,000 in stolen $20 bills after his counting machine broke.

Stephen Watt, a 25-year-old programmer who was working for Morgan Stanley, created a sniffing program dubbed “blabla” that Gonzalez’s gang used to allegedly siphon credit and debit card numbers from TJX and other companies and is facing sentencing this month.

The Wall Street Journal adds:

The Treasury Department recently reported that of the more than 55,000 incidents of wire fraud since 1998, more than half of them occurred in the past two years.

For the techie in each of you, I’d recommend Rich’s summary of the Visa/FBI/USSS data breach report in February 2009.

Allegations

From all accounts it appears that many of the major payment-card data breaches in the last three years can be attributed to a small handful of people, and perhaps one ringleader. Could this be a normal attack pattern, or were these individuals outliers?  If they were the crest of an even bigger wave of attacks, it does not bode well for corporate America, but if they are statistical anomalies then what would the world look like if we ignored them when measuring the success of the PCI program?

In 2003, Gonzalez, a carder in his own right, was arrested by the Secret Service and turned into a mole to allow them inside of CardersMarket, one of the largest carding rings in the world.  Though Gonzalez was outed at the time by Dave Thomas (aka. Ethics or El Mariachi), many people did not listen to his rants at TheGrifters.net.  Allegedly, Dave Thomas was at the time an informant for the FBI on the same operation.  Later that year, Gonzalez would replace Kim Taylor (aka. MacGyver) as the board manager.

In March 2004, Gonzalez expanded his domain by replacing Dmitry Golubov (aka Script) as board manager for CardersPlanet.

In 2008, Albert “Segvec” Gonzalez, Christopher Scott and Damon Patrick Toey were indited and accused of hacking into TJX Companies and thus exposing 40 million payment-cards.  This 2008 indictment named Aleksandr Suvorov (aka JonnyHell) of Estonia and Maksym Yastremskiy of Ukraine.  Could these be the two “Russian” conspirators that are mentioned in the current indictment of Gonzalez?

But Gonzalez would not have gotten very far had it not been for his friendship with Stephen Watt.  Mr. Watt, a 7 foot tall, 25-year-old programmer, wrote the packet sniffer “blabla” for Gonzalez to capture transactions as they traversed the corporate networks.  Interestingly enough, Watt “graduated from high school at 16 with a 4.37 grade point average and from college at 19″, but had a bug in the software that caused it to deactivate each time the POS was rebooted.

Outliers

Again, I begin to wonder what the world would be like if these personalities had not met or operated in unison.  What would the payment-card world be like without Gonzalez?  It may be a stretch to speculate that this one individual and his actions equate to outlier status. By this measure military dictators and oppressive regimes could also be named outliers even though their affect is quite impactful.

What we are really measuring here is the difference between potential energy and kinetic energy and the catalyst to convert matter from one to the other.  We can assume that there are vulnerabilities in every system and the grater the number the higher the potential energy.  The catalyst, in this case Gonzalez, plays the role in converting that potential energy (vulnerabilities) into kinetic energy (stolen cards and then cash.)  Without the catalyst the measured state would stay the same and as such represent a seemingly stable statistic.

We can ignore this alleged stability in the system by stating that all vulnerabilities have the potential of being converted into cash, but until they are such statements are meaningless (outside of theory modeling.)  To this point we measure vulnerabilities not by their size in population but by how frequently they are exploited.  Without a catalyst to convert the vulnerabilities they contain little value from a metrics perspective of data compromises.

Statistics

According to DataLossDB.org the number of payment-card numbers lost between 2007-2009 equates to the following:

2007: 111,957,179 records

2008: 13,439,242 records

2009: 130,965,494 records (to date)

The total number of records for (almost) three years time = 256,361,915 records.  So, let’s see what these numbers look like if we remove Gonzalez from the picture.  That’s right, let’s throw out the catalyst for the outliers and see what the world of data breaches looks like for the Payment Card Industry.

If we count up the number of records lost due to Gonzalez between 2007-2009 we have the following respectively: 94,000,000 (2007), 4,303,930 (2008), and 130,000,000 (2009).  The revised data for those three years would look as following:

2007: 17,957,179 records (down 84%)

2008: 9,135,312 records (down 32%)

2009:  965,494 records (down 99%)

Analysis

What can we learn from this data?  Well, one can speculate that in the absence of outliers like Gonzalez, the overall volume of credit card fraud is dropping.  In fact, without him we would be coasting through 2009 with very few payment-card related data breaches at all!  I won’t make the mistake you anticipate and confuse correlation with causation.

One could also conclude that payment-card related fraud does not follow a normal Gaussian distribution.  In fact, it appears that payment-card related theft and fraud is statistically closer related to the probability distribution of terrorism than traditional crime statistics.

Taking a business perspective one still needs to be on the lookout for attackers and carders who wish to target your business in an effort to “get rich or dye tryin”.  Wherever there is financial or payment-card data there will be those who wish to plunder and capitalize on it.  One thing we must remember is that underground carding is a business model, albeit an illegal one.

Personal Responsibility in Information Security

August 9th, 2009 admin 5 comments

Recently Nick Selby posted on FudSec his article on Showing the Oblomovs the Door.  For those who care, an Oblomov or Oblomovism is considered a lazy or apathetic person or belief.  The blog post claims that information security professionals are “well-trained, well-intentioned” but “reduced [to] a series of relentless box-ticking” due to being “saddled with compliance management.”

The blog post further claims:

The CEO who lets the Security organization become the compliance department has abdicated to the government and Payment Card Industry his responsibility to understand and manage organizational risk. That is a fiduciary breach of CEO responsibility to shareholders. In addition to firing your ass, this should also be a floggable offense.

I agree one should use compliance as a guideline but manage it with respect to the business process.  I disagree with the fiduciary statement on grounds that one cannot claim a breach based on sparse case study and singularity statements.  The writer says this to bring grandeur to their claim.

The important part of this statement is that we are focused on the individual company here and their personal responsibility.  Remember, if you ever want to get something done don’t pass the buck.

The author, frustrated with the current implementation of compliance, states, “I stomped away from trying to influence security as an analyst because compliance … has managed to suck every ounce of oxygen from the room that is the security industry.”

Let’s just remember that history has shown that in the absence of legislation there exists a downward spiral of corporate responsibility towards protection of customer/consumer information and the well being of others. To support this I point to the moments of punctuated equilibrium that lead to things such as the Food and Drug Administration (FDA), the Securities and Exchange Commission (SEC), marginally improved ecological laws in China, and the current global financial crisis — to name a few.

Let’s also take a moment to remember that regulatory compliance has been raising the bar of information security since 1999, starting with GLBA, then with HIPAA and SOX, and finally with PCI DSS.  Is it because PCI DSS impacts most all business verticals on a global basis that it receives the most abuse from those who feel burned out?

Might I remind you that without such efforts the number of data breaches would be higher, much higher, than we see now because people find it easier to blame someone or something else rather than take personal responsibility for their own work.  The Information Security Management Handbook, by Tipton and Krause, has a section on diffusion of responsibility.

People behave differently based on the perception of being part of a group as opposed to being an individual.  It has been commonly observed that people tend to work less in a group than as individuals when only group output is measured.  People, in addition, tend to feel less responsibility in a group than as a single individual.  The bigger the group, the lower the felt sense of responsibility. Social scientists call this diffusion of responsibility and the phenomenon is commonly observed across all cultures.

I believe that instead of blaming others, we as information security professionals need to become an agent of change starting with ourselves and our current environment and expanding outwards.

The blog then claims:

At this writing it’s unclear whether Black Hat and DefCon demonstrations will include the PCI-compliant account skimmers we’re heard of, but the fact that they’re out there stands testament to the Pyrrhic victory that is the PCI Data Security Standard.

Please remember, the PCI DSS is meant to protect against the electronic and paper theft of payment card data.  It is not meant in any way to prevent credit card skimming. If you wish to raise the issue of skimming, please use the correct approach which is to clarify the need for a more secure payment card.  That of course gives way to the larger question of what is proper capital allocation and the conundrum of offline transactions and backwards compatibility.

I agree, sadly, with the blog post when it says, “PCI is not the minimum standard, it’s the maximum effort that many organizations make.” The question I have is, based on historical precedent (see above): are we better off with or without a carrot-and-stick approach? What impact has HIPAA had on the security of health care records vs PCI on the payment card industry?  In which area do we see more movement?

Certainly, movement does not always imply movement in the correct direction, but I would claim that basic items such as PCI DSS Requirement 3.2 which tells merchants and service providers to not store sensitive authentication date post-authorization has done wonders to the security of our payment card data.  How better to secure the data than to remove it in the first place?  We are seeing trends in this direction more and more in this industry and others.

But isn’t it better to have a minimum standard than none?  What if the minimum was for companies to do nothing?

Jeremiah Grossman stated, nothing did more to build webappsec awareness than pci-dss. Now we need something to improve webappsec security.” I could not agree more, but let’s please remember that without awareness of a problem you cannot bring clarity or correction. People love to lambaste and transfer responsibility to others, all the while stomping away from personal responsibility.

If your company or those around you fail to see the forest through the trees of ‘industry best practices’ when I wonder if they are fit to run the information security department.  Those who complain that ‘compliance’ is the problem are transferring responsibility to industry standards instead of working to secure their own infrastructure.

Do such standards need correction and evolution to mirror the evolving threat of attackers and the continued evolution of information security practices and technology?  Certainly!  I support Mr. Selby in his goal to drive higher standards and move towards risk management, but let’s do so by taking individual responsibility for our own management of risk.

Mr. Selby claims,all this compliance stuff is preventing us from addressing risk and performing, you know, security.” Why?  Did someone tell you that you cannot secure your data? Did someone tell you that by using proper the proper risk management practices you claim work so well that you cannot pass the “minimum standard”?  I support you in questioning and ferreting out anyone who makes such statements.  For the rest of the unwashed masses, we need standards.

Mr. Selby ends his rant with a statement everyone should agree with, “Compliance – the state of being – is achieved as a by-product of well-managed risk, not through a relentless ticking of boxes”, which is then followed by high-level statements of positive thinking.  The problem is that we need some tactical examples and guidelines to match the ever increasingly vague strategic statements.  GLBA says to safeguard customer information, but how?  And left to their own devices most companies will chose the cheapest possible way to implement optics of compliance.

I argue, that the PCI DSS has given concrete statements to how one secure their infrastructure, while giving the flexibility one needs to adjust for business and risk management (e.g., compensating controls, wireless and end-t0-end encryption guidelines.)

The problem lies not with our industry “best practices” but with the diffusion of responsibility that happens throughout every company.  Let’s reference back to that Information Security Management Handbook article:

The effects of de-individualization and individualization are real and play a role in how users perceive their role in an information security awareness program.  In the credit card processing call center example, de-individualization can encourage theft, carelessness, and loss of productivity.

I’d like to stop the blame game and see everyone start at home, transforming their company and being neighborly enough to share the information and results with others.  Revolution has often come from emerging evolution of ideas and conversations. I commend Mr. Selby for the conversation, but wish it involved a greater focus on personal responsibility.

Take responsibility for your own security, risk management, and data protection. Start today.

Dave Hogan doesn’t know PAN

August 7th, 2009 admin 2 comments

In a recent blog posting Dave Hogan, CIO of the National Retail Federation (NRF), reiterated his dogmatic stance that “PCI is little more than an elaborate patch”.  This is something he stated in a recent Congressional subcommittee meeting.

The best accounts of this testimony are by Branden Williams and Anton Chuvakin.  I highly recommend reading both of their blog posts, which deconstruct the testimony and point out flaws and fallacies in many of the statements.

Now, I want to agree with Dave, but much like conspiracy theorists he goes a little too far.  Is PCI enough to secure companies against every data compromise ever imaginable? Certainly not.  Does it raise the bar for the entire industry and make it harder for hackers to compromise payment-card data? Most certainly, and this can be shown by the increase in sophistication of attacks each year.

So, I want to agree with Dave until he makes statements like the following one during the Congressional subcommittee meeting:

What is ironic in this scenario is that the credit card companies’ rules require merchants to store, for extended periods, credit card data [PAN] that many retailers do not want to keep.

I am shocked he was not reprimanded for this one, but then again he said the same thing a few years back on 60 Minutes and few people blinked an eye.  This statement is 100% false.  The card brand operating rules and regulations have long since enabled chargebacks without the full credit card number (or PAN.)  This is further verified by Anton and Branden in their blogs mentioned above.  Walt had to restrain himself from throwing objects at his TV when he saw the 60 Minutes episode.

Dave continues in the next sentence by saying:

To many NRF members, it appears that the credit card companies are less interested in substantially improving their product and procedures than they are with reallocating their fraud costs.

Come again? The credit card companies that dominate the industry, Visa and MasterCard, are not liable for fraudulent transactions.  Do you know who is? The merchants who accept the stolen or fraudulent cards, by means of lost merchandise or goods.  In this sentence Dave is blaming the card brands for trying to reduce payment-card data loss, which in turn reduces other merchants fraud losses, many of which are members of the NRF … his employer.

Again, I want to agree with Dave when he says that we should remove the data and never store it in the first place.  <APPLAUSE>  In fact, many companies have been saying this for a long time, including: TrustCommerce, ProPay, Shift4, MerchantLink, EPX, PPI, BrainTree, Network Merchants, MagTek, Semtek, HomeATM, VeriFone, and CyberSource to name a few!

But are we to blindly accept that one-size-fits-all business models?  The benefits of many of these end-to-end encryption systems come with limitations on how the data can be used.  Internal business process must be re-engineered and some many no longer be possible since only scrambled or encrypted data will be present.

Companies must weigh the pros and cons of any security technologies before running head first into any “solution”.  I am an advocate of end-to-end encryption along with many other information security protection measures (many are listed in the PCI DSS), but we must implement each to the degree that they facilitate and support the business.

We also, need to read deeper into the mantra being told to us by experts.  We need to question the authority of others and examine the problem from all sides for ourselves.  It’s never an easy process but the more educated each of us are of both external security measures and internal business processes, the better we will be able to offer real guidance to our companies.

And that is job security you can bank on!

Got Spam? PCI does!

August 6th, 2009 admin No comments

Spam is one of those things we have grown to live with; right up there with junk mail and infomercials.  When we think of spam we usually imagine a Nigerian 419 email or something more sexual in nature.  But today I received a spam message that topped the list of niche markets — PCI spam!

The following is an email I received that purported to help you achieve PCI compliance.pci_spam

This initially looks like a legitimate company that is trying to sell some snake-oil and make a buck on the uninformed small merchant, but it’s actually much worse.

It seems PCI has become so popular that even phishers and spammers have begun to capitalize on it, ironically stealing your credit card number under the guise of helping you become PCI compliant.

By the time I clicked on the link the URL (www.merchant-sol.info) did not resolve, but a quick WHOIS lookup revealed the domain for what it was.  Under the list of DNS servers it says:

Name Server:DUMMYSECONDARY.PLEASECONTACTSUPPORT.COM
Name Server:BLOCKEDDUETOPHISHING.PLEASECONTACTSUPPORT.COM

Sigh.  It seems there is no place sacred from phishing and spam.  Worst of all, it’s meant to exchange your credit card number for PCI compliance.  Perhaps we need PCI DSS Requirement #13: Do not use your credit card to pay for PCI compliance.

Categories: PCI Tags: , , ,

How Banks and Merchants manage their risk with PCI DSS

June 22nd, 2009 admin 3 comments

When a situation is not risky, there is little need to manage or measure the risk involved.  This applies equally to lending money to friends, reading utility meters, and until a few years ago, handling credit card transactions.  With the growing risk to financial transactions there is a need to improve the ways acquiring banks, processors, gateways, and even merchants manage and measure their risk.

In fact, prior to the PCI DSS the metrics involved in measuring the risk in an acquiring bank’s merchant portfolio were rather basic.  You look at the number of transactions per month and categorize the merchants into business categories.  One would say that online gambling would be riskier than grocery stores.  The logic seemed flawless, at least for the environment at the time.

Unfortunately the environment changed and hackers turned from fame and glory seekers to those wanting large financial payoffs from their prowess.  They began attacking merchants and even banks by finding the low-hanging-fruit never imagined by the industry.  The hackers began targeting:

  • POS systems directly connected to the Internet with weak remote access methods
  • Weak or insecure wireless located at physical stores
  • Insecurities in partner and vendor connections to companies
  • Insecure web application software

The hackers identified, by brute force, holes in the security of an industry that were never imagined by those creating the metric for managing their risk.  When the compromises reached a tipping point, the industry began to shift the focus to security.  The banks and card brands formed the PCI Security Standards Council (PCI SSC or Council) in 2006 and invited merchants, POS vendors, and other industry experts to participate (as Participating Organizations.)

In order to realize the importance of this change you have to first understand that people do things based on incentives, and for most companies security is not something they are very willing spend money on.  This can be seen in the ever increasing number of data breaches that occur every day.  Anyone who has had teenagers can tell you that in order to “encourage” a person to do the right thing you need to properly incent them.  Regulatory compliance has been the thing that has incented companies to place an importance on information security for the last 10 years, and PCI DSS compliance has been the leading force for the last three years.

This might pass over as just another regulatory issue like GLBA or SOX if not for the fact that it’s not specific to a business vertical.  The payments industry is sometimes called a “horizontal” because it cuts across so many areas such as banking an finance, travel and entertainment, health care, power and energy, etc.  In fact PCI DSS is the first globally enforced, industry regulated, cross-industry compliance program.  It’s goal is simple: prevent the electronic and paper theft of payment card data.

But why?  Don’t you like it when we ask why?  The reason was not to do this because it’s the right thing.  We all like to say we are acting “green” by composting when really it’s just a way of reducing the cost of our garbage bill.  We want to prevent the loss of this data because someone is paying for the fraud: other merchants, acquiring banks, and many more.

So, we begin to understand that acquiring banks use the binary aspect of PCI DSS compliance as a measuring stick to determine the risk within their merchant portfolio.  Sure there are still the number of transactions, type of business, and size of the organization, but now there is the check box of security.  What does this really mean in practical terms?

Well, of all the PCI DSS requirements, the most important by all accounts is 3.2 which mandates that sensitive authentication data should not be retained post-authorization.  The other requirements for security act to protect this data from being intercepted in the first place.  The end result is that hackers should never have any access to this sensitive authentication data.

OK, so the standard exists to protect the super secret data so banks can measure how risky their merchants are to them.  This acts much like the credit rating agencies such as Moody’s and Standard & Poors.  The question is, “Are the current  metrics sufficient for measuring risk in a merchant portfolio?”

I would argue that, much like the credit rating that says “AAA”, the PCI DSS is only one part of the holistic approach merchant banks should take to measuring risk within their portfolio.  Think back to the collateralized debt obligation (CDO) market that just exploded.  People were packaging mortgages together into one security that people could then trade against.  The problem is understanding the impact that all those thousands of mortgages and the people behind them will have on the value of that one security.

In a similar way, banks need to look at PCI DSS as just one factor in analyzing the risk to their portfolio.  I’d argue that to keep the model working one should look to the Verizon Data Breach report and analyze attack vectors to determine what areas should be measured.

If we look at the data breach landscape we see the following numbers:

  • 74% resulted from external sources
  • 20% were caused by insiders
  • 32% implicated business partners
  • 39% involved multiple parties

The metrics companies and banks should use for measuring risk should include:

  • Third Parties and the data they share (all three types)
  • Deployment of a wireless network (proximity to acceptance channels such as POS)
  • Number and size of business processes (POS network, databases, applications)
  • Connected business units (call center, data warehouse, or physically insecure locations)

Individual merchants need to prioritize attack vectors.  If we know that more hacking events occur due to weak passwords or default passwords we should focus on eliminating things like “<blank>” or “password” or “<vendor name>” rather than focusing on achieving 7 character, alpha-numeric ones (which for the record are no better than 5 character ones in theory.)

I argue that we need more focus on attack vector trending threat models for regulatory compliance before we focus on the broad spectrum of security best practices.

10 Fallacies in PCI Conversations

June 9th, 2009 admin 8 comments

Since my goal is to make your arguments better, here are a few of my personal problems I have with the current PCI-Wars debate.  For those not familiar with logical reasoning, please read up on some of these fallacies.

The following is a list of unbalanced flaws in conversational logic that should be avoided when having a conversation with me about PCI.

1. Companies got hacked so PCI must not work

People like to point at recent data security breaches and claim that because companies have been compromised then of course the standard must not work.  Under the same logic if any company gets compromised then the entire information security industry must have somehow failed us.  People forget to remember that it’s all about: people, process, and technology, not just the industry standard.

2. The PCI DSS is all about “risk transference”

I have to restrain myself physically when people say those naughty two words.  Let’s take a walk down the life cycle of a fraudulent transaction for a moment, completely independent of PCI or compliance.

Merchant “A” accepts a fraudulent payment card and delivers the product to the client.  If a cardholder denies the charge, it’s a charge back and Merchant A must absorb the fraud.  (This is why merchants should maintain strong fraud reduction measures.) In the event of a CPP designation on Merchant “B”, the Issuer may apply for reimbursement from the compromised Merchant B.  To do so they need to apply, through the card brands and Acquiring bank, for reimbursement.  If Merchant B can cover the cost then they will pay for the fraud due to their losing data.  If Merchant B cannot cover the cost, then responsibility resides on their Acquiring bank to pay for the fraud.  In many instances it’s not the compromised merchant that pays for all the externalities resultant from lost or exposed payment card data.

So you can see, a compromised merchant is usually the last one to pay for fraud resulting from data that they lost.  They have always been responsible and PCI DSS does not change that in any way.  Instead, the PCI DSS serves as a metric by which the Acquiring banks can begin to measure their potential exposure to financial loss.

3. PCI compliance is all about making money for someone else

Whoa there cowboy!  Remember that the card brands, issuers, and acquirers all spend money on trying to keep merchants and service providers secure.  They put time, money, and resources into developing the program and educating others about it.

The participants: the QSAs, ASVs, infosec vendors, etc. all already existed before PCI ever came alone, they were just called “security consultants”, “Internet vulnerability scanners”, and “product vendors”.  Changing the name of a company doesn’t change the game.  Most merchants forget a small fact that every level of merchant is allowed to self assess if they wish.  Level 1 merchants can use their internal audit group or a QSA, and Levels 2-4 all use the Self-Assessment Questionnaire (SAQ).  The reason companies pay consultants to help them out is the same reason I hire an electrician to rewire my house.  They have experience with it.

I’ve got a deal for you.  You promise to never lose or expose payment card data then I’ll wave my hand and say “this isn’t the non-compliant company you are looking for.”

4. Credit card theft is part of identity theft

Pardon? Ok, in the metaphysical world where everyone sings coombyya then, yes, credit card theft is part of identity theft.  In that same world so is automobile theft, library card theft, and friends using your Costco membership.  I read recently that, “The Federal Trade Commission (FTC) estimates that 50 billion is lost annually due to identity theft and credit card fraud.”  Without context we have no way of understanding this number.  We need to define “identity theft” or else we should include the automobile theft statistics, because if someone steals your car and gets ticketed, isn’t that your identity as well?

Credit card theft has so little impact on the cardholders that almost every issuing bank waves the $50 service fee, and reissues a card within 7-10 days.  If someone steals my SSN, and uses it, the cost to me could take years of work to reverse.

5. PCI just enables checklist security

Yes, just like every other security checklist that ever came before it.  That’s like saying a wheel is only a tool.  Correct, but if that wheel is a racing tire and put on a Formula-1 car it can do good things.  If you hang that wheel on your front door hoping it will ward off evil, I suggest altering your philosophical beliefs.  Companies need to learn how to use the PCI DSS to enable security within their payment card environment and not follow it alone.

The problem occurs on the implementation side when companies with no prior security adopt the PCI DSS as their information security management system, which it was never designed to be (IMHO).  Companies must integrate the PCI DSS into their overall security framework and not use it to replace one.

6. A “compliant” company was compromised so the standard must not work

This is not true.  Please see also: compliance vs validation.  The Visa website provides a “Global List of PCI DSS Validated Service Providers“.  I don’t see the word compliant in there once.  In fact, if we open the PDF and read the first sentence it says, “The companies listed below were validated as being PCI DSS compliant by a QSA as of the ‘VALIDATION DATE’.”  What this means is that a company validated they were compliant one day of the year.  What that company does the other 364 days of the year is an unknown, until the forensic investigation team shows up.

7. Merchants are required to maintain the PAN

Ugh… In late 2007 60 Minutes did a broadcast that contained some misinformation.  One of the people being interviewed claimed that the credit card brands require companies to store the Primary Account Number (PAN), one of the basic elements in authorizing credit card transactions.  I know one person who had to restrain himself from throwing things at his TV after hearing this.  The payment card brands (i.e. Visa) had long since changed their rules and do not require merchants to retain the PAN after authorization and settlement of transactions.  This informaiton has not been widely disseminated to the pupulation.

Regarless, this is still a weak argument, since we know that the vast majority of payment card fraud has nothing to do with just the PAN, but instead the resale and illegal use of sensitive authentication data (track data, CVV2, PIN block).  And this, everyone universally agrees, should not be retained or available to hackers.

8. PCI is reactionary and not preventative

The PCI SSC has stated they will update the PCI standards on a 2-year basis.  When updating these standard, I assume, they will use data breach information and feedback from the industry itself to keep the document as up-to-date and usefull as possible.  When we saw web-application data breaches on the rise, the PCI DSS was updated to include Requirement 6.6 which helped address the problem.

Only by understanding the patterns of attack can be better help companies repel these forces.

Please also remember that the PCI SSC is contributed to by the Participating Organizations who provide feedback on a regular basis.  If you want to get involved then join as a member.

9. PCI is too much! or PCI sucks!

Let’s all chant together, “Tastes great! Less filling!”  Most people get less 5th grade about it and say, “PCI is too specific” and others say, “PCI is too vague”, while still other cynics claim, “… no, it’s specifically vague!”  Wrong, wrong, wrong.  If PCI is too much then why don’t you just secure your data and call it a day.  If your security foo is so good then validate as such.  Also, remember #5.

Jack Daniel said it this way, “PCI sucks. But it sucks less than doing nothing, which is the normal alternative. Real security would be better. So would unicorns.”  If PCI is painful then I begin to wonder why.  Perhaps you don’t fully understand the scope, intent of requirements, or how to best secure your infrastructure?  Perhaps you understand all these but still cannot achieve compliance due to a flat network topology or other scope issues.  This is when I remind you that the overall intent of the PCI DSS is to prevent the paper and electronic theft of payment card data.  If you can understand and achieve this, then it’s all you need.

10. PCI is not enough!

To this I agree, but not that we need more regulation or more security products.  I think people need to expand their insight into the intent behind the requirements and the standard itself.  In the last paragraph I stated that meeting the intent facilitates compliance.  Let’s take this to the next logical conclusion.

While many security people are happy to help you “carpet bomb security” by securing every system to the 9’s, why don’t we start talking about scope reduction and eliminating systems from scope.  The PCI Answers blog lists for us several product vendors that support end-to-end encryption.  Other people have begun creative ways to remove data from scope instead of securing it.

By removing data from scope, and finding more creative ways of securing the data we do store, we are going well beyond simple compliance into the realm of sound security practices.  The PCI DSS exists as a minimum bar to which those who have little security in place can aspire.

sidebar west END -->