I’ve been a bit out-of-pocket recently (a combination of famility vacation & working on projects with some of our large retail and retail technology clients), but wanted to make sure that I made note of this information from VISA in case you hadn’t seen it.

Sorry - that’s it, but as we get through the next crazy week (it’s Black Hat after all…) I’ll try to be more active on the blog - I’ve got a few thoughts on the recent payment terminal announcements from VISA as you might imagine.  Thanks!

Visa Releases New Guidelines For Protecting Card Data - Network Computing.

Related articles by Zemanta

• Visa Inc. Completes Acquisition of CyberSource (pindebit.blogspot.com)
• Tokenization and Chargebacks (brandenwilliams.com)
• Visa yanks PCI approval from PIN entry kit (go.theregister.com)

The study in the article was sponsored by a vendor that provides firewall management solutions (go figure), but it doesn’t mean that the message isn’t an important one - firewalls are easy to forget about once you

Private Property - via Flickr - mollybob

have them in place and (particularly in retail and hospitality) there are so many things that your network and security people have on their to-do list that seem more pressing today then reviewing your firewall rules…

Now, I’m not supporting the vendor that sponsored this study and wouldn’t have the slightest feedback on its products effectiveness, but I am supporting the concept of reviewing and maintaining your firewall configuration.  The company that I work for does a lot of firewall rule assessment and while we are often engaged in this capacity as part of a client’s normal security operations, that isn’t always the case.  Sometimes it’s because management hasn’t appreciated the need to properly maintain firewall rules and now legitimate network traffic is being affected.

OK - back to the article - what’s also interesting is the implication that a company that is not taking the proper steps to review their firewall rules periodically will run into legal liability issues if they are breached.  They hit this point fairly hard, but don’t really provide much in the way of support for their argument.  However, it’s probably fairly valid - if an organization doesn’t manage their firewalls effectively (and isn’t able to demonstrate that they are doing so) it certainly could be something that a lawyer might latch onto …

The Perils of Firewall Security | CTO Edge.

Related articles by Zemanta

• One in 10 IT professionals cheat in audits (computing.co.uk)
• McAfee updates firewall hardware for enterprises (news.cnet.com)

… Why does Reddit use a Gmail account for this purpose, anyway? One of the site’s moderators answers: “When we were much, much smaller (no mail server, etc) it was the easiest way for several people to get to the feedback account at the same time, and it stuck.”

So there you have it: as the company grows, it should continually update its security practices, otherwise it might find that certain solutions, that were good enough a couple of years ago, simply don’t cut it anymore.

This is a common situation with many organizations (including many retailers) - not keeping security up-to-snuff as the organization and it’s systems, personnel, and needs grow and change.

While a social media site like Reddit may not be subject to security and compliance oversight like a retailer would be it reinforces something that I’m constantly discussing with clients - security (and compliance) is a process and, while point-in-time validations are necessary, they are just that - a point in time.

Make sure that you’re keeping security needs in mind as your organization and it’s environment changes….

Hackers Break Into Reddit’s Gmail and Twitter Accounts.

Related articles by Zemanta

• Hackers Break Into Reddit’s Gmail and Twitter Accounts (mashable.com)

So Dave & Busters’ FTC settlement is finalized and it illustrates another concern for merchants that aren’t taking a comprehensive approach to security - the burden of being monitored by the FTC.  Here’s the quote from the press release:

The settlement requires Dave & Buster’s to establish and maintain a program designed to protect the security, confidentiality, and integrity of personal information collected from customers. It also requires the company to obtain independent, professional audits, every other year for 10 years, to ensure that the security program meets the standards of the settlement. In addition, the proposed settlement contains standard record-keeping provisions to allow the FTC to monitor compliance.

This is a huge deal - having an ‘independent, professional audit’ of your security program every other year is not covered by your PCI Report on Compliance.  It is an additional audit requirement that goes well beyond PCI’s card-specific requirements and requires a far more in-depth review of your full security program.  It also requires putting in place the ’standard record-keeping provisions to allow the FTC to monitor compliance.’  In other words - it’s not getting ready every year for your QSA, it’s maintaining the appropriate information and providing access to that information 365 days a year.  Dave & Buster’s is going

to be requ

ired to document every aspect of their entire security program and be able to demonstrate it’s effectiveness to auditors and the FTC.

Add this to your list of stuff to worry about and make sure that, if your executive man

agement team isn’t putting the proper focus on security and compliance, that they understand that this additional concern is real - it’s not just about PCI.  And if they think maintaining PCI compliance is expensive…..

FTC Approves Final Settlement Order with Dave & Busters | Office of Inadequate Security.

Related articles by Zemanta

• Dave & Buster’s Settles FTC Charges it Failed to Protect Consumers’ Information (ftc.gov)
• Man sentenced for hacking restaurant card data (deurainfosec.com)
• Hacker’s record credit card theft fetches 20-year sentence (go.theregister.com)

I’m not a lawyer, so let’s put this caveat onto everything below -  This is all from one-side of the discussion and it’s all alleged and I don’t support one side or the other in this situation.

• Brew HaHa! purchased a ‘turn-key’ solution from what they understood to be a ‘exclusive’ reseller of the POSitouch POS solution - CC Productions
• It was explained to them that they could utilize a payments solution from Mercury Payments - any alternative to Mercury would cost Brew HaHa! additional money
• Charles claims that Brew HaHa! was not informed that the Mercury solution that was being implemented was not PCI / PA-DSS compliant and that, after the system was implemented, Brew HaHa! noticed that they were being charged a fee to allow Mercury to make the changes needed for their solution to be PCI compliant.  According to Charles, that’s the first time they realized that the solution wasn’t compliant.
• They have had a forensics team in and they determined that malware was present on the environment and that the malware was aggregating cardholder data (among other things)
• There is another, larger merchant that has yet to come forward that may have a similar situation and complaint…

Not a lot really (I’m not a great interviewer - not enough practice), but it did answer some of my questions and raise some more.

Also, Restaurant Data Concepts sent a press release as well - link (the link heads over to the Office Of Inadequate Security site - which is an excellent site btw).  Take a look at the release as it also makes some very interesting points.  Although, I will say that the statement, ‘It is not overly difficult or expensive for a merchant to protect themselves against theft of cardholder information’ is a little unfair - it can get very expensive and quite technically involved for many merchants.  The other line I thought was interesting - ‘A small expenditure to upgrade and secure their system can stave off significant costs and penalties…’

Ultimately it breaks down like this for me:

1. There’s an involved chain of companies/products/services involved here: Restaurant Data Concepts (software) —> CC Productions (hardware/installation/implementation/Mercury resellers maybe as well?) —> Mercury Payments (software?/processing) —>Brew HaHa!(which is responsible for their broader PCI requirements).    Lot’s of places for someone to not do their job with PCI/security.  Lots of places to miss something or to not even realize that something wasn’t getting done by someone else in the chain.
2. There is a responsibility that lies with a software vendor (as documented in PA-DSS), but does that responsibility extend to resellers?  ‘Exclusive’ resellers?
3. When a small merchant without a big IT staff purchases a ‘turn-key’ solution, what does that mean for PCI?
4. If a reseller or a technology vendor doesn’t volunteer the fact that they aren’t PCI compliant (or PA-DSS validated) does that mean anything?  Yes, the retailer should have asked (and really contractually obligated) the vendor regarding compliance, but is the provider responsible for disclosing?  (Either way, it’s a pretty crappy move if it really went down that way).

Regardless - it should continue to be interesting.

Some Additional Info:

Lawsuit Brewing…

Brew HaHa breach no laughing matter

Well - right now it’s just the threat of a suit…  The information is a bit thin and I’m not sure (based on the press release) whether or not this is a complaint about the software, the implementation of the software, the hardware system, or all of the above.

What it does look like is a bit of a fishing exercise by the law firms - let’s send out the press release, make it general enough that we include just about anyone that even thought about touching the system and see if the vendors jump for that settlement opening (’there is hope that RDC and CC Productions will decide to resolve the situation before it goes to court.’).

This could be very interesting if it is more than just a ’shake-down’ - we don’t know the software releases/revs, we don’t know when systems were installed, we don’t know how the alleged breaches actually occurred, we don’t know much of anything except that the lawyers are crying ‘PCI’ and waiting to see what happens…

It might be a completely legitimate complaint by merchants that implemented a solution that was over-sold to them as a fix to their ‘PCI problem’.  It might be that the merchants installed a solution that was secure in itself, but didn’t take any steps to secure their own environment beyond the POS.  It might be that the implementer took a secure solution and made it insecure through improper implementation (following that PA-DSS Program Guide?  huh?).  It might be software issues.  It might be who knows what…..

I want more information and I want to know if they are going through with this or if they are just using this as leverage.

Looking at the PA-DSS validated list, two of the POSitouch solutions are listed - both under PABP 1.4 - don’t know if these were the solutions/revs that the merchants had installed, but, if they were it would be an interesting exercise to see how much protection the PA-DSS validated list would provide a POS vendor…

Lawsuit Brewing Against Popular POS Software Provider and Reseller.

This implies two things (as far as I can see):

1. That the deadline everyone was wondering about is legit - why would ExxonMobil feel the need to negotiate an extension with VISA unless the deadline was going to mean something and VISA was going to enforce it at some meaningful level?
2. If you are big enough, VISA is going to play ball…

Not sure that #2 bodes all that well for smaller merchants (of all types) as I doubt that VISA’s all that interested in negotiating with everyone of extensions.

As is mentioned in the article, providing extensions to this sort of deadline creates problems unless you make them very, very rarely.  Which, again, strengthens the case for July 1st being a ‘real’ deadline for merchants.

We are currently doing a LOT of PA-DSS work for software clients, but, at this point those applications, even if they are validated prior to the first of July, will most likely not be fully deployed at merchant sites….

It’s getting interesting as July approaches.

StorefrontBacktalk » Blog Archive » ExxonMobil Discovers That A PCI Deadline Is A Deadline, Unless It Isn’t.

• Quick PCI overview, including the role of the PCI Security Standards Council and QSAs; the interrelationship of PCI-DSS, PA-DSS and PED; Merchant-Acquirer-QSA relationship; and the major PCI-DSS requirements
• Discussion of PCI compliance versus Information Security and the relationship between each
• Baseline view of the operational realities that make POS systems unique
• Review of the pros / cons of security solutions (e.g., blacklist-based antivirus, emergency security patches, application white-listing)
• Discussion of POS antivirus and file integrity monitoring requirements in POS systems; operational and deployment challenges; application whitelisting as compensating controls (Case Study)

Here’s the link to the registration and hope to see you there…

NetSPI Webinar — PCI 2.0: Moving Beyond Simple Compliance to Improved Security with Application Whitelisting.

FAQ on Washington State’s Impending PCI Law : Info Law Group .

I had know idea that there was a genre of online comedy videos that used scenes of Hitler from movies coupled with fake closed caption information….

Didn’t really think Hitler could be all that funny, but this one is pretty good.  Mind - I don’t speak a lick of German and have no idea what is really being said here, but the captions are hilarious…

Thanks to ReadWriteWeb for the spot.

YouTube - Hitler and Cloud Computing Security.