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.

Advertisement

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.

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.

Why The Continued EMV Push?

Visa and MasterCard continue their push to get merchants in the United States to install Europay, MasterCard and Visa (EMV) capable terminals so that they can push issuers to transition to what most of the world refers to as “Chip and PIN”.  Because Visa and MasterCard have a vested interest in EMV technology, they feel obligated to push this “dead horse” onto the rest of us.  The problem is that merchants and everyone else outside of Visa and MasterCard have with EMV is that there is not a business driver to convert as EMV does little or nothing to address today’s card fraud issues.  

As background, EMV was developed to address the rampant card present transaction fraud that occurred with the fall of the Iron Curtain back in the late 1980s.  Overnight, credit/debit card cloning of the magnetic stripe on the cards became big business in Eastern Europe.  With the rollout of EMV in Europe in the mid-1990s, card present transaction fraud plummeted to at or below the levels in the United States because the chip in the EMV card was impossible to clone (although to be compatible, EMV cards have a magnetic stripe which still can be cloned).  Spin ahead a decade to the mid-2000s to today.  Card present transaction fraud continues to be at about the levels in the United States and Europe.

Times change and so does fraud.  With the advent of eCommerce over the Internet starting at the turn of the century, fraud has moved to card not present transactions.  As long as someone has the PAN, expiration date and cardholder name, you can shop almost anywhere.  And if you are someone who is committing fraud, you can buy that information via the Internet for around $2 to $10 an account.  Pay more and you can get the three to four digit code (CVV2, CVC2, CID, etc.) that confirms you have the card in your possession.  Card not present frauds run around 10 times or higher than card present fraud and is costing merchants and some consumers billions every year.

So what does EMV do to minimize card not present fraud?  Absolutely nothing.  Not that there have not been attempts to introduce EMV-based solutions for eCommerce.  A number of European banks and American Express in the early to mid-2000s tried to introduce standards that used inexpensive serial and USB EMV card readers connected to a shopper’s PC.  But none of these solutions could gain traction with eCommerce application developers and merchants, so eventually they dropped their efforts.  Had Visa and MasterCard had some foresight, they would have partnered with a few of the influential eCommerce merchants and eCommerce application developers and created an eCommerce EMV standard and related APIs, but that did not happen.

To add insult to injury, EMV probably only minimally improves the risk of data breaches.  The reason is that EMV moves attacks to compromising terminals and POS systems at the merchant and gaining access to systems and information at the transaction processors and financial institutions.  That is because once the information in the chip is being processed, it is handled the same way as information off of a magnetic stripe.  If it is not processed, stored or transmitted securely, an EMV card is just as susceptible to being breached as its older, less secure magnetic stripe counterpart.  And given the current state of affairs with BlackPOS, POS botnets, vSkimmer and the like, the risk with EMV is probably only slightly better than magnetic cards.

Unfortunately for Visa and MasterCard, technology has moved on.  With the advent of smartphones and tablets, application developers created eWallet applications.  eWallet applications store a cardholder’s credit/debit card information in a secure file or database.  Some eWallet applications use these devices’ near field communication (NFC), Bluetooth or Wi-Fi capabilities to securely transmit the card information to a merchant’s POS solution.  There are also eWallet applications that display the PAN as a bar code so that merchants can use their existing POS technologies to scan it from the screen.  Coming in the near future are eWallet applications that will generate a single use 16 digit number with bar code, NFC, Bluetooth and Wi-Fi capabilities.  All of these solutions offer as much, if not more, security than EMV.

The times have changed and so has card fraud.  Yet here we are with Visa and MasterCard continuing to push EMV technology.  EMV does little to nothing to address today’s issues or issues that are down the road.  It is time for Visa and MasterCard to move on from EMV and look for the next new solution and stop pushing a dead end technology on merchants that have no good business reason to adopt it.

POS Botnets

Just in time for the holidays.

An article came out this past week regarding botnets that are specifically targeting point of sale (POS) systems.  The reason I bring this up is because of this quote.

“StarDust developers have intimate knowledge of the inner workings of PoS applications such as Clearview PoS.  As a result, the malware can ferret out where in computer memory sensitive data, in some cases in cleartext form, is stored.  StarDust can also sniff network traffic and is able to extract Track1 and Track2 card data.  To remain covert, the software transfers card details only when the terminal is inactive and the screensaver is on. It also uses the RC4 cipher to encrypt data before sending it to the control server.”

Obviously, if your organization uses Clearview POS software you should probably be examining your systems and networks to ensure that they have not been compromised by StarDust.

However, the larger issue is that most merchants do not see themselves as targets of such attacks, let alone have they constructed a secure environment for their POS systems.  Some of this is not entirely the merchant’s fault.  A lot of merchants outsource the maintenance and management of their POS systems to a value added reseller (VAR) and that VAR is the one responsible for the POS network configuration.  Regardless of responsibility, a merchant needs to be aware of these threats and take appropriate action either internally or with their VAR to address these threats and minimize risk.

Regardless of whether it is StarDust or a similar threat, here are some steps you can take to minimize and detect such threats.

• Segment your POS network from the rest of your internal network and limit POS network segment traffic to only communication to your processor and internal network and system support and operations systems.  This will require the development of network access rules so that traffic can only reach your processor or internal system support and operations systems.  This will limit the number of systems that could compromise your POS environment.
• Monitor your POS network segment for any traffic that is directed to an external network other than your processor or system support and operations systems.  Your firewall rules should only allow secure connections between your POS network and your processor or your system support and operations systems.  Network traffic going anywhere else should be stopped and reported for further investigation.
• Monitor your POS systems for any file or configuration changes.  Most anti-virus solutions can provide this capability, but there are also solutions that are specifically engineered for this task.  Regardless of which you choose, configure the tool to alert you as soon as it identifies a potential change to files or configuration of the POS system.  If approved changes were not made to the POS systems and you received an alert, you likely have been compromised.
• Develop an incident response plan should you receive an alert indicating that your POS systems have been compromised.  An incident response plan provides the organization with a “battle plan” should a compromise occur.  This type of plan is key to minimize the potential reputational impact to the organization should such an attack be confirmed.  A good incident response plan can keep you from making mistakes as you navigate the mine field that is the media circus that comes with a breach.

Three straight forward and simple steps that can minimize the threat of StarDust and a documented incident response process should you unfortunately be breached.

Security does not have to be rocket science.

PCI DSS v3 and PA-DSS v3 – Wait For It

There are all sorts of QSAs and other experts who are weighing in on the new versions of the PCI DSS and PA-DSS that were released around the first part of November.  In my very humble opinion, all of this discussion is speculation, at best, because the PCI SSC has not released the final pieces of the standards puzzles.  Those final pieces are the respective Reporting Templates for those standards.  Without those templates, QSAs and PA-QSAs have no idea of what the true testing and reporting requirements they will be held.  As a result, the impact of the changes to the standards will not truly be known until QSAs and PA-QSAs have the templates and can review the new testing and evidence requirements.  While I am not expecting the sort of major changes that resulted when the version 2 Report Instructions were released, there still could be some surprises that could impact the amount of work and evidence collected.  The PCI SSC has not committed officially to a release date for the Reporting Templates, but the rumor is that they will be available around the first part of March 2014.

There are some comments that can be made and I will be covering some of those points on a Webinar sponsored by Tripwire on Monday, December 16, at 7PM UTC / 1PM CST.  If you care to attend, you can register for the session here.  “See” you there.