So I’ve decided that I’m going to post a summary of the posts and articles that I’ve read over the last week or so that I’ve thought were interesting and relevant.  This isn’t what I’d really prefer to do - I’d much rather take the opportunity to rant about something or to try to explain something that we’ve seen out in the ‘real world’, but sometimes you just don’t have the time, so forgive me my laziness this time around.

Heartland and Discover Agree to Settlement

PCI Compliance - Why Spas, Hotels, and Resorts Can No Longer Ignore IT

NetSPI Blog - Security in the Cloud

Some Additional Commentary on VISA Payment Security Best Practices Guidelines…

The Fed Gets Involved with EMV (I find EMV an interesting topic although I might be alone in this…)

Skimming: Old Crime, New Tools (this one is also interesting to me)

I hope that you find these article interesting and I’ll get back to more comment-rich posting shortly.  Thanks!

Related articles by Zemanta

• European Payments Council Newsletter: New Business Opportunities with Chip and PIN (pindebit.blogspot.com)
• Is U.S. “Wising Up” to Smart Card Use in America? (pindebit.blogspot.com)

Actual is not normal (a tribute to Edward Tufte) - kevindooley via flickr

Short post here, but things always seem to happen in groups, so I thought I’d make everyone aware of a couple of current and upcoming opportunities to dig into a very important topic (particularly during budget season) - Security Metrics.

NetSPI is putting on a webinar tomorrow (Thursday, Aug 26th) with Symantec - here’s the info/sign-up page on their website (full disclosure, if you don’t know by now I work for NetSPI):

Application Security - without metrics it doesn’t exist

And I got the August issue of The ISSA Journal yesterday and the cover story is ‘Security Metrics, An Overview’ by Clare Nelson.  It’s a good starting point for Security Metrics and it provides a good list of sources for additional information.  You’re going to have to be an ISSA member to access the article, but if you are reading this blog you should probably join the ISSA regardless (it’s like $95 a year or something).

The Journal is available to ISSA members for download from the ISSA site - ISSA

I will highlight one of the sources that Clare uses for her article (seriously - join the ISSA and read her article) - the Center for Internet Security - not all of their information is free, but the information that you would need to get started implementing a security metrics program is free - it’ll at least get your conversations started…   CIS

Related articles by Zemanta

• Security Metrics - Is This Network Getting Better? (tenablesecurity.com)

VISA Provides Guidance on Secure Implementation and Management of Payment Applications [link]

After taking a look at the press release and looking through the actual document that VISA (and SANS apparently) produced [link] I think it’s a pretty interesting move on the part of VISA.  If you haven’t yet taken a look and you work for a retailer or a software vendor that sells to the retail space, I’d advise downloading the document and reviewing.

Basically, this guidance provides VISA’s best-practices regarding the implementation and support of payment applications that are already PA-DSS validated.  It appears that some of the recent breaches that have occurred (as per the post here) where the break-down in security may have happened during the implementation of the software or through after-deployment support processes has created some action

untitled_by_paalia_via_flickr

from VISA.

Now - what does this mean for you?

If you are a retailer - I’d say that it provides you a list of items that you are going to want to discuss with your software vendors and their resellers.  Most of the items in the document are something that your vendors should already be doing already, but some will, most likely, not be in place today (the reseller training program is something that I wouldn’t expect everyone to have in place today for example).  Number 6 in the press release is interesting as well - most of the software vendors that I’ve been working with are trying not to force an upgrade on all their retail clients (you’d expect otherwise, but, really, most of the vendors aren’t being pushy about it with their clients as far as I can tell), but in #6 VISA is basically telling the vendors to tell you that you have to upgrade if you have an older, pre-validation, version of their solution.

If you are a software vendor - get ready to spend more money and good luck not being held responsible for the actions of your resellers…  In all honesty - most of the items shouldn’t be a huge stretch (a lot of this is just good application security stuff), but the specific notes regarding the reseller training program makes this interesting.  I’m sure that you already have some sort of program in place for your resellers, but this might be a bit different from your general training - what happens when a reseller installs your solution incorrectly AFTER going through your newly implemented security training program and there is a breach?  Who’s going to take the blame (legally or otherwise) for the incorrect installation?

If you have any comments or insight that you’d like to add - please feel free to comment or send me a note via the contact page.

Also - I’ll be heading down to the PCI SSC meeting in September - look for a post after that trip highlighting some of the changes coming from the council on the PCI DSS.

Related articles by Zemanta

• Visa Releases Global Best Practices for Card Data Tokenization (newswire.ca)
• PCI SSC releases highlights for 2.0 changes (deurainfosec.com)
• Time to plug the PCI compliance gap (channelweb.co.uk)

The article also talks about why the major card brands work and attempts at breaking the system and introducing a new model for credit cards (none of which have yet worked)…  Not really a security article, but one that is highly relevant given the focus on payment security.

Why Your Phone Can’t Really Replace Your Credit Card | Epicenter | Wired.com.

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.