Author Archive for PCI Guru


Celebrating Five Years

Wow! Time really does fly when you are having fun.

Believe it or not, the PCI Guru has been doing this for five years.

Thank you to my readers for continuing to support the blog and I look forward to serving you with even more blog entries in the future.


PCI DSS v3 Requirement 10.6

I was on a call the other day and we were walking through requirement 10 of the PCI DSS v3 to ensure we had everything covered regarding changes.  One of the other people on the call gasped and told all of us to look at requirement 10.6.

 “Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment.”

The person who gasped said, “You don’t think they mean ALL other systems as in everything do you?”

We all looked at the Guidance column for advice and saw that it said:

 “Logs for all other system components should also be periodically reviewed to identify indications of potential issues or attempts to gain access to sensitive systems via less-sensitive systems.  The frequency of the reviews should be determined by an entity’s annual risk-assessment.”

The tests 10.6.1 and 10.6.2 also refer to “all other systems” as well.  In the end, we came to agreement that the new version of the PCI DSS does call out that all systems, even those out of scope, need to have their log data reviewed based on their risk to the organization.

Talk about a “How in the Hell did we miss that?” kind of moment.

Worse is that we know a lot of organizations are going to push back very, very hard on this requirement.  They sized their security information and event monitoring (SIEM) solution based on their cardholder data environment (CDE) and Category 2 systems, not their entire networks.  But it gets even worse because this is not a requirement that you can put off until 2015, this requirement needs to be complied with immediately when going to the new version of the PCI DSS.  Oops!

But if this is not enough, the Council used that word “periodically” in the requirement.  In the guidance they state, “The frequency of the reviews should be determined by an entity’s annual risk-assessment.”  So there is another requirement for the risk assessment.  Your risk assessment must define why log data of all systems is only reviewed once a month/quarter/year/etc.  However, if you are routing all log data from all systems/devices into a SIEM, it should be reviewed in almost real-time.

Congratulations to all those SIEM vendor sales people out there as it will likely be a very good year for all of you.

Just wanted to provide you all with the heads up.


Why The Paradigm Must Change

The Target, Neiman Marcus and the potential other breaches of retailers to come should be a learning moment for all of us to demand that the card brands change their business paradigm to one that is more secure.

Bolt-Ons Do Not Cut It

For all intents and purposes, how a credit card works has not changed since the late 1950s when they were introduced.  Yes, there have been advancements such as EMV, 3D Secure and end-to end encryption (E2EE), but those are all things that just bolt onto the original concept.  The trouble is that, given today’s technologies and their capabilities, the card and the bolt-ons are just no longer providing the security they once did.

With the Target breach there has been a call to get the US to finally convert to EMV.  The trouble is that EMV would have leaked enough information for fraud to be committed as well, so it is not an answer.

Trade association spokespeople trotted out 3D Secure and other methods of securing online transactions.  The trouble is that most merchants eschew 3D Secure and its kind.  In addition, there are known vulnerabilities with these supposedly secure payment methods so they also have potential issues that could be exploited.

Then there is E2EE also known as point-to-point encryption (P2PE) from a PCI perspective.  These also can be exploited.  It may be more difficult, but when you are determined to gain access to sensitive information, that does not matter.

After the release of the PCI DSS in 2008, a lot of retailers implemented a variety of E2EE solutions.  Unfortunately, the endpoint at the retail location was the POS register and not the terminal.  This was not due to merchants’ negligence; this was due to how their POS applications operated.  This allowed for attacks such as that used in the Target breach to succeed.  All the attacker has to do is insert their malware into the POS process so that the malware can “see” the cardholder data before it gets encrypted.

Even in solutions that do E2EE/P2PE to the terminal can be defeated by taking the same approach and inserting the malware into the terminal process before the terminal can encrypt the data.  Worse yet, if the terminal is breached, the attacker can capture PINs if they also have malware that captures the keystrokes on the terminal before the PIN is encrypted.  There are a number of methods to minimize these risks at the terminal, but if the terminal supply chain is compromised as it was over a year ago in the Barnes & Noble breach, there is little a merchant can do to stop such attacks.

The bottom line is that all of these solutions are bolt-ons to the existing card paradigm and all still have risks that a breach could occur.

Using Complexity Against Us

Brian Krebs and others have wondered aloud how a sophisticated organization such as Target that has information security and forensic resources second possibly only to the government could have been compromised.  Particularly after the 2007 compromise by Albert Gonzales when Target totally revamped and increased their security posture to minimize the likelihood of another event.

The first clue to me came when I read the iSIGHT PARTNERS report on the Target breach.  The theme that comes through loud and clear is that the attackers are using the complexity of Target’s technology infrastructure against Target.  I mean how could FTP activity and huge data transfers (internal and external) go so unnoticed?

Actually, that was likely fairly easy.  The attackers used existing network traffic to mask their own network traffic.  They sought out servers that already had large volumes of traffic and put their data collection server on one of those servers that already had a lot of traffic.  Better yet, a server that was already running as an FTP server.  As a result, even with diligent monitoring, the increase in traffic likely did not raise any alarms.

People assume that such breaches are like a “snatch and grab” in the real world.  The attackers break into an organization’s network, quickly take what they can off of the computers they encounter and leave.  That was the modus operandi (MO) in the past, but not today.  Sophisticated and organized attackers such as those that breached Target, do what they can to remain unseen while they learn more about their victim.  They take their time mapping out the network and determining what devices they want to compromise to further their efforts to gain access to the sensitive information they seek.  Because of this, it is highly likely that the Target attackers encountered the Target customer database during their investigation of the Target network and took it first so that they would have at least something for all of their efforts.

The most insidious thing I think the attackers did was that they likely used Target’s software distribution system to disseminate their malware.  Given the number of POS systems compromised (around 51,000); I find it hard to believe that the attackers manually installed their malware on those POS systems.  It would have placed their operation at extreme risk likely resulting in its discovery.  By using Target’s software distribution system, the attackers got an added benefit of legitimacy to their malware because they Target themselves did the installation.  As such, the malware would appear as valid because Target’s software management system initiated the change.

Now What?

All of this brings up an interesting conundrum.  If attackers are stepping up their game and using such techniques, how do we detect them?  It is a very good question with no good answers.  The iSIGHT report offers methods to stop and eradicate this particular attack.  However, the next attack and the attack after that will all likely use different malware and different techniques to get the data out of your network.

We are in is a war of escalation with no end in sight.  Merchants step up their efforts to stop such attacks and the attackers adapt and adopt new techniques to breach organizations and gain access to their sensitive information.  What we need is a solution that stops the escalation and gets us out of this vicious circle.

That is why I am pushing the 15 – 16 character single use transaction code as that solution.  My reasons are as follows.

  •  The algorithms already exist as a number of the card brands experimented with them a decade or more ago.
  • It will work with existing POS technology and applications.
  • It will work with existing eCommerce sites.
  • It can be implemented into eWallet applications.
  • It can be processed, stored and transmitted without encryption.
  • It can be generated by PCs, smartphones, tablets, credit card sized devices and any other devices that have computational capabilities.
  • It can be displayed on devices in a character format for manual entry or as one or 2D bar codes for scanning.
  • It can be transmitted via swipe, EMV, near field communication (NFC), Wi-Fi or even Bluetooth.
  • And best of all, it is secure by the very nature that it can only be used once.

There will be some changes that would be required at the transaction processors and acquiring banks to handle such a solution.  But given that some of the card brands already have experience with this solution, there is a body of knowledge that already exists as to how it needs to be implemented.

Let the discussion begin on how we move ahead with a better, more secure solution.


More Retailers Supposedly Breached

Reuters is reporting that Target and Neiman Marcus are not the only retailers that were breached during the holidays.  There are at least three more retailers have also been breached.  What makes this announcement interesting is some of the information disclosed in this article.

 “Law enforcement sources have said they suspect the ring leaders are from Eastern Europe, which is where most big cyber crime cases have been hatched over the past decade.”

This was reported by Brian Krebs on Christmas Eve.  However, based on Brian Krebs’ reporting, it is the Eastern Europeans that are marketing the cards obtained, but they are not necessarily the perpetrators of the actual crime nor are they necessarily be behind the crime.  So whether or not Eastern Europeans are the perpetrators is pure speculation at this point.  At one point there were reports that the attackers are from Southeast Asia, but those reports are also unconfirmed.

I really do not care who did these attacks.  I am more interested in understanding how they were done so that I can advise my clients as to what they need to do to minimize the likelihood that they end up in the news.

“One of the pieces of malware they used was something known as a RAM scraper, or memory-parsing software, which enables cyber criminals to grab encrypted data by capturing it when it travels through the live memory of a computer, where it appears in plain text, the sources said.”

“Yet a law enforcement source familiar with the breach said that even if the retailer had implemented those steps, the efforts may not have succeeded in stopping the attack.”

We now have an idea of how the crime was committed.  The attackers were taking card data out of memory.  It also appears that the attackers were using a memory scraper that was already available such as vSkimmer or BlackPOS.  However, based on the unnamed law enforcement source, the attackers either modified the malware or used it as a basis for their own malware such that anti-malware solutions would not recognize it as malware.

“One of the sources who told Reuters about the recent rash of attacks said the memory parsing malware cited in the Visa reports was among the tools that the hackers had used, but said they used other techniques as well.”

I found this information the most interesting as it seems to lend credence to my theory that the software was part of an update to the card handling application installed on the POS.

 “Avivah Litan, a security analyst for Stamford, Connecticut -based Gartner information technology research firm, said she learned about a separate set of breaches, dating back no more than a few months before the November 28 Thanksgiving Day start of the holiday shopping season, from a forensics investigator. She declined to provide his name.”

“Investigators believe that the early series of attacks on retailers staged before late November were mostly used as trial attacks to help the hackers perfect new techniques they then used against Target, stealing payment cards at unprecedented speed, Litan said.”

These quotes imply that these were attacks that were traditional hacks of the retailers’ networks from the outside.  The problem I have with that is that this speculation does not square with my knowledge of the changes that Target implemented after they were a victim of Albert Gonzalez back in 2007.  Target made significant changes that minimized the ability of an outsider being successful in breaching their card processing environment.  Not only that, but the PCI DSS push isolating cardholder data environments (CDE) from the Internet.  Assuming that all of the retailers involved followed the requirements of the PCI DSS, then they should have properly isolated their CDE and were monitoring it for such attacks.  Not that every retailer might have identified an attack on their CDE, but I know that a security aware organization such as Target should have identified such an attack.

Not only that, but we are no longer talking about a single retailer.  We now have at least five retailers that are potentially in play and possibly even more.  It seems to be awful long odds in my book that we have five retailers all hacked in one way or another and then had the same malware installed.  As a former penetration tester, I could see getting one retailer in this way, maybe two retailers.  But not five or possibly more with the same or similar methods in the same time frame.  Again, it can be done, but would require a lot of time, coordination, people and effort.

Hackers may be sophisticated, but they are like water and typically want to find the path of least resistance to accomplish their goals.  Attacking networks with firewalls and monitoring are to be avoided as they take lots of time and effort and the likelihood of getting caught in the process is too high, particularly when we are talking multiple organizations.  That is why I go back to compromising the software at the source.

If I were constructing such an attack, I would either infiltrate the POS application vendors for large retailers or coerce an existing employee of those companies to insert my malware in their code.  That way my exploit comes directly from the source.  The good news for attackers is that there are a limited number of companies that develop the code that most retailers use to handle card transactions, so an attacker would just have to look for the vendor with the customers that would provide the best results.

Since these vendors issue precious few updates, their customers are typically chomping at the bit to obtain those updates and get them rolled out before the holiday season.  They are going to be tested heavily, but a smart attacker would have set their malware up to know they are being tested and have the malware remain silent during testing.  Once placed into production, the malware would activate and begin collecting card data and sending it back to wherever the attacker decided they wanted to collect it.

Easy peasy.  And a lot simpler and easier than hacking networks.

Again, this is all speculation on my part.  But knowing how attackers work, I feel my scenario makes much more sense than what is being discussed.


The Economics Of EMV

There are a lot of people out there that have apparently taken big swigs of the EMV Kool Aid and think that merchants and banks in the United States are all idiots for not believing in EMV.  Well folks, here is EMV by the numbers.  Unfortunately, the best set of complete numbers I could get are from 2009, but I know that the fraud percentages have not radically changed since 2009.

As this example will illustrate, EMV in the US is a non-starter, not because we do not like EMV, but because it makes no financial sense. While I am using Target as the example, these numbers are pretty much what most retailers (large or small) are looking at as they evaluate going to EMV.

  • Target had around $65B USD in revenue for 2009 as reported in their Annual Report.
  • For 2009, card fraud amounted to 0.11% according to a report from the US Federal Reserve Bank of Kansas City report on EMV adoption. For comparison, card fraud in the UK (the best in Europe and the best for EMV countries) is 0.08%, a 0.03% improvement over the US.
  • We know that not all of Target’s revenue is in card transactions but I will estimate that 70% of revenue was card transactions (around $45.5B USD). Then Target has around $50M in losses related to card fraud for the year at 0.11%.  Therefore, assuming a 0.03% improvement in fraud due to implementing EMV, Target is saving around $13.5M USD a year.
  • Estimating between $50M to $100M USD to replace the POS (possibly), terminals and software to support true EMV (for comparison, Target is already spending an estimated $25M to $30M just on new terminals), Target gets a payback on that $13.5M USD savings due to EMV in around four to seven years.

I can tell you from experience that, if a merchant cannot get a three year or less payback, they will not even consider the investment. A two year or less payback is actually preferred and the only sure way for any project to get management’s consideration and approval.

But while the financials for EMV do not add up, there are also other factors that are causing retailers to question a conversion to EMV.

One of the largest is the fact that EMV does nothing to stem the fraud losses from card not present (CNP) transactions. Since most retailers are viewing eCommerce as their next new retail opportunity, the exponentially increasing losses due to CNP fraud does not improve the likelihood of converting to EMV. And with that larger focus on eCommerce and maintaining brick and mortar margins, there is also the concern regarding investing significantly in any changes to those brick and mortar operations that also hold back retailers from transitioning to EMV.

Another consideration is that a lot of retailers just upgraded their terminals a few years back to comply with the PCI PTS requirement. Most retailers like to get at least seven to ten years out of their technology investments. Had Visa and MasterCard played their cards right and coordinated their EMV push with the PTS changes, the US likely would have converted to EMV.

Finally, there are concerns about EMV even surviving given the advent of new payment technologies such as eWallets as well as Bitcoin and other new forms of payments. As a result, a lot of retailers are sitting on the sidelines while technology and payment methods sort themselves out before considering making any investments in new payment process capabilities.

That my friends are the cold, hard facts of why EMV is currently dead on arrival in the US.


What You Should Take Away From The PCI DSS 3.0 – Part 2

It was published sooner than I thought.  But here is the remainder of the post on PCI DSS 3.0.

What You Should Take Away From The PCI DSS 3.0 – Part 2


What You Should Take Away From The PCI DSS 3.0 – Part 1

See my latest blog entry at the FishNet Security 6Labs blog.

What You Should Take Away From The PCI DSS 3.0 – Part 1

Part 2 will be published shortly and I will post the link here.


How About We Fix The Problem?

As I pointed out in my last post, EMV would have not stemmed the loss of data in the Target breach.  All EMV would have done is restricted where the thieves could use the card data obtained.  Even though the thieves can supposedly clone cards from the data gathered, as far as anyone has reported at this point, cloned cards do not appear to be the method of fraud.  So the assumption I have is that all, or the vast majority, of the fraud committed to this point has been through card not present transactions.

In response to people clamoring for a solution to the breach problem, Visa and MasterCard have curiously remained silent.  I would have assumed that the card brands would have trotted out their press releases touting EMV as the savior.  Yet they have said nothing.  Could it be that the card brands are actually acknowledging that EMV would have not been the answer?  One can only hope.

So what is the answer?

To me the answer is single use transaction codes of 15 to 16 characters in length.  With the advent of smartphones and miniaturization of electronics, the ability to create a card or an application that generates such a code is not only possible, but has been demonstrated in recent years.  Not only that, but the card brands and banks themselves dabbled with such solutions over 10 years ago but for some reason backed off on pushing such a solution.  My best guess is that without a portable method of using the single use code system, there was no point to pushing such a system.  But times and technology change.

With the capabilities of today’s technology, the single use codes could be displayed as bar codes so that existing merchant POS systems could scan them and avoid data entry errors.  Since they are no more than 16 characters in length, the codes can be stored in applications’ existing fields used to store card numbers without modification.  Since the card brands and banks have already developed the algorithms for this approach, they only have to agree on which algorithms to use.  But best of all, since the code can only be used once, it can be processed, stored and transmitted wherever and however without fear of a compromise because it can only be used once.

This is just my thought for a solution but there are other people and organizations that have their own solutions to fix this problem.  The bottom line is that it is time to fix the problem, not keep kicking the can down the road with a known format that is at the end of its life.


EMV And The Target Breach

There are a lot of people now pointing to the Europay MasterCard Visa (EMV) card (aka “Chip and PIN”) as the savior from breaches such as those at Target and I am sure Visa and MasterCard are very pleased with that fact. Well, I hate to burst your bubble, but if the US was only using EMV like Europe and Canada, it probably would have had only a minor impact.

Are you stunned by that statement? After all, that is not how Visa and MasterCard are portraying EMV. If you read their media statements, they imply that EMV is the answer to these breaches.

To make sure I was describing the security features of EMV correctly, I reached out to my friend and EMV expert Andrew Jamieson, Security Laboratories Manager, at Underwriters Laboratories – Transaction Security in Kew, Australia. Underwriters Laboratories tests and certifies a lot of things, one of which is card terminals (magnetic stripe and EMV) to the PCI standards. As such Andrew has a lot of knowledge in the area of EMV and how it works.

I asked whether or not EMV cards are encrypted.

“EMV cards are not encrypted, per se, but instead store a couple of secret keys which are used as part of the authentication of the entire transaction. All card data can be output from the card in the clear – PAN, CVV, etc – except for the customer PIN and the secret keys. The CVV will also be different from that on a magnetic stripe, either static (called an iCVV) or can also be a dynamic value that changes with each transaction (dCVV).”

Well there is a piece of interesting news. While the transaction gets encrypted with the secret keys, an EMV card would still provide some information in a Target-like breach.

Then I asked if there is a risk even with EMV.

“So, any chip based transactions from an exposure such as the Target one would only have exposed the PAN (technically, the PAN on the card can be different from the PAN on the face/track, but in reality this never happens), not the full track. As the CVV would not have been exposed, the PAN would have limited value.”

If the magnetic stripe was not present, the CVV would not be required or recorded in the chip, so only the iCVV or dCVV would be available and those would not be usable as the code printed on the card would not match either of those values. Therefore the information gathered would not allow for the cloning of cards because the information recorded in the chip is not the same as the information that is printed on the physical card. But this should not be a surprise because that was what the EMV standard was designed to do, prevent the cloning of cards.

However in a Target-like breach where the terminal and/or POS system were compromised, the chip would have still given up enough information to be used in card not present transactions such as those conducted via eCommerce. As a result, the attackers would be limited to only defrauding online merchants but that is where most card fraud is being committed.

EMV is not a “silver bullet” such as the card brands like to imply. Yes, it is better than the magnetic stripe, but it does nothing to stem the tide of the growing fraud in online transactions. There are a number of new technologies on the horizon that will minimize the fraud risk of using credit/debit cards in both card present and card not present situations. But until the card brands get behind those solutions, they will continue to push their old solutions and not address the current problems.


Target As A Target

It is not a good thing when a local institution becomes the target of attackers, but that is what happened this week when Target Corporation announced that they have suffered a cardholder data breach of around 40 million card numbers from around Thanksgiving through December 15.

The key quote in Brian Krebs’ blog post is:

“The type of data stolen — also known as “track data” — allows crooks to create counterfeit cards by encoding the information onto any card with a magnetic stripe. If the thieves also were able to intercept PIN data for debit transactions, they would theoretically be able to reproduce stolen debit cards and use them to withdraw cash from ATMs.”

Of all of the bad things to happen, the attackers obtained track data.  The only way track data could have been obtained would have been to compromise the software that executes in their card terminals.  A huge misunderstanding we can thank the PCI SSC for when they stated that card terminals were just “dumb” devices.  Unfortunately, even when that statement was made it was not accurate.  Card terminals are similar to smartphones and typically run embedded versions of Linux or Windows and have their own software development kits (SDK) for developers to use for the rapid development of applications.

What Brian Krebs’ statement implies is that the attackers developed a version of the software that collected card swipes and the entry of the PIN from the keyboard before the real application then properly processed that same information.  It also implies that the attackers are somehow part of the terminal supply chain and were able to have Target implement the compromised version of terminal software on their terminals.

This is not as farfetched as it might seem.  A little over a year ago, Barnes & Noble was compromised by card terminals that had compromised software.  In that incident, the attacker pretended to be the third party that managed, repaired and replaced Barnes & Nobles’ terminals and shipped packages to a random number of stores asking employees to replace their busiest terminal(s) with the replacement terminal(s) that were compromised.

And compromising software is not as farfetched either.  Card terminal manufacturers are no different than other high technology manufacturers and rely on contractors in low-cost locations such as India, Mauritius China, Brazil, Argentina, Egypt and other overseas locations to develop their software.  That is not to say that someone within Target could have manipulated the software, but it is much more likely that a contractor for the terminals’ manufacturer is the culprit.

However, one thing that bothers me about this whole situation is how did the terminal software make it through Target’s quality assurance (QA) process?  The answer to that question might lend itself to the fact that an insider was involved either directly or indirectly.  The reason the QA process might not have picked up the compromised software is that the compromised software knows when it has been deployed in the field and did not activate in QA testing.  That would imply that the persons that developed the software had some insider information to ensure that the compromise would not activate during QA testing.

Finally, is it possible that other merchants have been compromised and just do not know it?  That is a definite possibility and merchants should be taking steps to ensure that they too have not been compromised.  For this sort of breach, merchants should be monitoring their network(s).  Merchants should make sure that those devices’ and systems’ network traffic is only going to their acquiring banks or transaction processors.  Network traffic going anywhere else should be investigated and halted if deemed a risk.

UPDATE – 12/21/2013

The media reports regarding what data is available seems to indicate that PINs were not compromised.  This is based on what Brian Krebs is now reporting as well as other media sources are finding at some of the online carder sites.  If true, that would indicate that the data could have come from Target’s point of sale (POS) systems as well as terminals.

That would be good news for Target customers.  While fraudulent transactions can still occur and people need to monitor their accounts, without PINs, debit cards are just credit cards and people can more readily get their money back if hit by credit transactions.  However, that can depend on your financial institution and state laws.

Inclusion of the POS solution could be bad news for a number of retailers that also use Target’s POS solution.  If the source of the breach was the POS, then obviously that POS solution has potential issues and those merchants with that POS solution could also be at risk just as the merchants using the same manufacturer’s card terminals could also be at risk if it is the terminals.

For concerned merchants, the key though is still monitoring and alerting from your POS environment.  The attackers have to get the data out by using your network for such a large breach.  So if you are properly monitoring your network and identify traffic to anywhere other than your transaction processor(s) or other approved outside sources, you have probably been breached and need to investigate.

UPDATE – 12/26/2013

News reports over the holidays are quoting unnamed sources stating that PINs for debit cards were obtained in the Target breach.  Target is denying that fact and that denial would appear to be supported by the data being sold on the carder sites that have been identified thus far as selling the Target data.  As of this writing, no one reviewing the data on the carder sites has reported seeing PIN data for sale along with cardholder data.  That is not to say that PIN data was not obtained in the Target breach.  If it was obtained, it is not being offered openly for sale on the carder sites and may be available only through back channels.  Knowing how carders work though, one would assume they would have offered the PIN data for sale if they had it.

The misinformation regarding PINs in the media reports are amazing.  I would love to know who the experts are that are advising these people as they really do not appear to know how cards work.  The PIN block on the magnetic stripe is the only field on the stripe that is encrypted.  So any PINs obtained were not obtained from the magnetic stripe.  That would mean that if PINs were collected, they would have had to have been obtained at the terminal as the user was entering the PIN and before the terminal transmitted it to the processor.

Media pundits continued the drum beat for EMV adoption.  Again, where do these pundits get their information?  EMV cards are not encrypted (as with traditional cards, only the PIN block is encrypted) and EMV would not have stopped this breach given the level of sophistication quoted by the US Secret Service.  What EMV would have done would be to have limited where people buying the card information could have used the information they gathered because they would not have had the CVV2/CVC2/CID codes.

Brian Krebs believes he has identified the person behind the marketing of the data and possibly someone who likely knows who perpetrated the Target breach.

UPDATED 12/27/2013

The plot thickened today when Target admitted that PIN data was breached as well but that data was encrypted.  This clearly points to a breach at the POS register and not the terminal.  If a terminal had been breached, one would assume that they would have had access to PIN data entered when customers entered their PINs with debit cards.

But this is not some Windows- or Linux-based POS that just anyone could know about.  This is IBM 4690 POS and it runs a specialized version of a UNIX-like operating system that is not widely known outside of the retail software industry.  As a result, the perpetrators likely work or have worked for Target’s retail software vendor or even IBM’s retail division at some point.  That will shrink the number of people that could have engineered this breach down to a very small number.

Something I would like to clarify.  While the breach involves 40 million total card numbers, the number of actual credit/debit cards involved is likely less than 40 million.  The reason is that those 40 million are likely not all unique numbers, just 40 million unique transactions.  I know that during the breach period my spouse and I visited Target a number of times as I am sure a lot of other people.  As a result, when viewed as unique card numbers, that 40 million could actually be 50% or more below that number.  Not that this makes this breach any less important or devastating, but it helps put things in perspective.

UPDATED 01/01/2014

 “But this is not some Windows- or Linux-based POS that just anyone could know about.  This is IBM 4690 POS and it runs a specialized version of a UNIX-like operating system that is not widely known outside of the retail software industry.  As a result, the perpetrators likely work or have worked for Target’s retail software vendor or even IBM’s retail division at some point.  That will shrink the number of people that could have engineered this breach down to a very small number.”

Boy, I blew that and here is why.

I was a Target store today and I examined the cash register as closely as I could without getting escorted out of the store by security.  To my shock, I realized that Target had swapped out their IBM 4690 POS registers with NCR RealPOS registers.  From a color and configuration standpoint, Target’s NCR units look almost like their former IBM units, so that is why I mistook the NCR POS for IBM POS.

The reason this POS identification is important is that NCR RealPOS is essentially an Intel-based PC with a cash drawer.  These POS systems typically run Windows but can also run Linux.  Unfortunately, I have no idea whether Target runs Windows or Linux on their POS registers.  One would assume they run Windows but the POS application they run does not give any indication of the underlying OS.

What drove all of this was an email from a reader that pointed me to a Microsoft case study.  In that case study was the following statements that caught my eye.

 “Microsoft was pretty creative about developing a virtual machine edition for SUSE Linux for us.”

“By the second quarter of 2012, we’ll be complete, with more than 15,000 virtual guests running on more than 3,600 Hyper-V hosts across our entire store network.”

“At each store, System Center Configuration Manager 2007 acts as a distribution point for security updates and application upgrades for approximately 172 devices.”

“Each of our server endpoints and each of our 5,400 POS registers has a System Center Operations Manager agent installed. That way, we can ensure the checkout experience for our guests remains fast and efficient.”

If you read the full case study, there are a lot of references to Microsoft products running on servers, but there is a lone reference to SUSE Lunix on a virtual server.  However, the real clincher that the RealPOS is likely running Windows is the statement that there are 172 store-level devices that are managed by System Center Configuration Manager 2007 (SCCM).  Since SCCM 2007 did not deploy anything other than Windows, it is almost certain that the RealPOS in Target stores are running some version of Windows.

Now one has to wonder if the POS registers are running Windows 7 or XP?  Given that the POS is isolated away from external networks, it is not likely that the attack came from the outside.  It could have, but I seriously doubt it.  Given the reference by the US Secret Service that it was a sophisticated attack, I would still bet that this breach has some form of insider knowledge be it from the POS vendor, NCR or Target.  However, now the population of people that could have pulled off the breach is rather large as we are talking a Windows environment, not a proprietary environment.

UPDATE 01/07/2014

I got an email from a friend out in California this morning.  They were shopping at their local Target and they noticed that the store has new Verifone MX925 PIN pads that have replaced the red Hypercom (now Equinox) units.

Verifone MX 915 front_light

My guess is that Target is implementing Verifone’s end-to-end encryption (E2EE) solution in response to their breach.  The E2EE solution will encrypt the data stream from the terminal and take the POS system totally out of the loop as a breach point.  Anyone that would want to compromise this solution would have to figure out a way to load software onto the terminal to intercept the data before it is encrypted.  While that is a risk, it would be almost impossible to do it to every terminal Target has installed like they did with the POS systems.

UPDATE 01/12/2014

The news on Friday, January 10, could not have been worse for Target, but not for the reasons you might think.  Yes, the attackers had accessed up to 70 million customer records containing names, addresses, telephone numbers and email addresses.  It was worse because, in a lot of instances, the media seems to have totally misrepresented and misreported what the Target press release stated.  As a result, Target’s customers were, in a lot of cases, totally misinformed about what had actually been stated and that resulted in people like yours truly dealing with a lot of silly and ridiculous questions and concerns.

My first problem was with the blaring headlines that up to 110 million individuals’ data could have been released.  While technically accurate, it is not really factually accurate.  The reason is that, according to Target’s press release, it is likely the majority of the original 40 million that were breached were highly likely to already be included in the 70 million of records breached.  As a result, it’s much more likely that only an additional 30 million or so people had their information breached.

My second problem with the reports is that none of the reports seemed to ask the obvious question that the new revelation demanded be asked.  Which breach happened first, the breach of the POS or the breach of the customer information?  The reason this question is important is that once it is answered, it will help us all understand how the breaches went down and how much liability to assign to Target.  It is one thing if Target was a victim of bad actors that doctored their POS software and then used that to access the customer information.  It is another thing if the customer information was hacked by outsiders due to security lapses and that that access to the customer information was leveraged to cause the POS breach.

My third issue with the media reports on Friday is that they also missed the easy question which is, “Are there any more data that might have been compromised?”  I am not an expert on Target’s technology infrastructure, but if they are like any other organization, they have customer information in more than one database.  As a result, one has to wonder if there will be more revelations of other customer information having been compromised.

All of this said, I think Target is giving us all as much information as the US Secret Service will allow.  What the media and public do not appreciate is that Target’s public relations department is not in control of reports regarding the breach.  If they were, we might know more details about the breach.  The reason the US Secret Service is not letting more information out is so that they can conduct their investigation to find the culprits and that cannot be done if everything is revealed in media reports.  The US Secret Service also controls the timing of when information is released

Shortly after the revelations by Target on Friday, we got another revelation that created concerns for its lack of information.  That was the acknowledgement that Neiman Marcus has also suffered a card breach of unknown length and size.  What was most disconcerting about the Neiman Marcus announcement was that they were told of their breach by the card brands in mid-December which implies that Neiman Marcus had no idea they had been breached.  While the Neiman Marcus breach was not tied to the Target breach, those of us in the industry are wondering about a potential link since both potentially may use some of the same POS applications.

It will be interesting to see how these events progress.

And this just in. The Chicago Tribune is reporting that three more retailers have been breached over the past holiday season and that announcements of those breaches are imminent.

UPDATE 01/16/2014

Brian Krebs comes through again with his take on how the Target breach occurred.  Based on my review, I have a few comments.

 “That source and one other involved in the investigation who also asked not to be named said the POS malware appears to be nearly identical to a piece of code sold on cybercrime forums called BlackPOS, a relatively crude but effective crimeware product. BlackPOS is a specialized piece of malware designed to be installed on POS devices and record all data from credit and debit cards swiped through the infected system.”

We had been led to believe that the malware was something already seen but this seems to confirm that it was BlackPOS and not some other memory scraper.

 “Somehow, the attackers were able to upload the malicious POS software to store point-of-sale machines, and then set up a control server within Target’s internal network that served as a central repository for data hoovered by all of the infected point-of-sale devices.”

That somehow is likely Microsoft System Center.  Given the number of POS systems that we believe are involved, I would assume that the attackers somehow were able to get their malware into Microsoft System Center and have it then “officially” distributed to the POS systems.

The other thing of note is that there was a control server that was commandeered to collect all of the information being gathered.  I would assume that server would have already been involved in a heavy transaction traffic situation so to mask the additional traffic created by the malware.  So the server used was probably already been used for FTP as that is the protocol BlackPOS uses.

But this also gives us a clue as to the timeline of the compromise.  The earliest that the attackers could have gotten in is the end of June 2013.  That is based on the fact that that is when BlackPOS first showed up as available for use.

 ““The bad guys were logging in remotely to that [control server], and apparently had persistent access to it,” a source close to the investigation told KrebsOnSecurity. “They basically had to keep going in and manually collecting the dumps.””

This quote just made my jaw drop but makes sense if you want to surreptitiously get information out of a heavily monitored environment.  Again, I would assume that the attackers chose their remote access point and the central server based on existing traffic volume so that their activities would be masked by the high volume of legitimate traffic.

In regards to why anti-virus and anti-malware utilities did not detect the malware.

 ““They were customized to avoid detection and for use in specific environments,” the source said.”

So those of you heavily relying on your anti-virus and anti-malware to detect these sorts of attacks, you should rethink that strategy.

So exactly how did the attackers get in?

 “But according to sources, the attackers broke in to Target after compromising a company Web server.”

This is probably why the personal information of customers was obtained.  In all likelihood, the PII was the first useful information the attackers encountered as they got into Target’s network.  And since they had no idea how far they could get, they likely downloaded that PII so they at least had something to sell for their efforts.

I am going to leave things here as I ruminate on what all of this means.  There is a lot of other pieces that come to mind and I need time to put all of it together before I comment further.

UPDATE 02/01/2014

I am behind in my updates here for a variety of reasons.  However, it appears that Target has a high likelihood that Target was PCI compliant when the breach started and even, possibly, as it gained access to sensitive authentication data (SAD).

As we have come to expect, Brian Krebs continues to give excellent updates on the Target breach.  But my hometown paper, the StarTribune, has also been doing a decent job on covering the breach as well.  On Thursday, January 30, the StarTribune following up with BMC Software on Brian Krebs’ claims, got BMC to admit that they are working with McAfee.  Later in the day, BMC Software issued an update clarifying Brian Krebs’ report.

The bottom line in the flurry of activity late last week was that a vendor’s software was used to obfuscate the attackers.  The troubling part of all of this is that the software in question is used by a multitude of retailers which could lead to further announcements of breaches as those retailers examine their implementations of BMC Software.


FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (, search for 'PCI' and apply.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response to too "sales-ee", I reserve the right to edit or not even authorize the response.


July 2014
« Jun    

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 909 other followers


Get every new post delivered to your Inbox.

Join 909 other followers