February 10, 2008   Sign In |  About ebizQ |  Contact Us |  Join ebizQ Gold Club
Peter Schooff
Peter Twenty-Four Seven Security
Peter Schooff's blog is a daily look at what's going on in the world of computer security with an emphasis on how it affects businesses.

« Managing Superuser Accounts | Main | Absolute Necessity of Mobile Encryption »

November 21, 2007
Beware the Point-of-Sale Data Attack: A Podcast with Tripwire

Listen to or download the 9:15 minute podcast below:



Download file

What follows is my podcast with Barak Engel, the Tripwire PCI expert. Barak has over fifteen years of experience in IT and information security and is a member of the advisory board of the Center for Information Security, and in this podcast we discuss the problems and solutions of protecting data at the point-of-sale (POS).

I've heard that as many of eighty percent of data breeches occur at the point of sale. Can you give me an example of one of these point-of-sale data breeches?

Before I do that, the eighty percent number is an interesting one. Depends on who you ask and how you look at it. A lot of the breeches can start there but not necessarily occur at the point-of-sale itself, simply because, in many cases, the point of sale does not actually hold many transactions. Those that do, of course, become very, very attractive targets.

As far as an example of a point-of-sale breech -- I'll give you a recent one. I don't know how well publicized this was, so I won't tell you who the merchant is. But the idea is that the group that was attacking this particular merchant went into a couple of their stores and distracted the gentleman that was working at the cash register and, while he was distracted, they needed only about ten to twelve seconds to do this, took out the little swipe machine that is sitting right there, the one you put your credit card into in order to authorize a transaction with the screen that you sign on, with one of theirs that looked exactly the same. Left it there for a couple of weeks, used that to both recall transactions and to attack a further system inside of that merchant's back office, if you will, use that as an entry point to their back end systems as well.

In two weeks, they came back, they got what they needed, they replaced it back in the exact same tactic and proceeded from there.

How would Tripwire help prevent against one of these point-of-sale security breeches?

Well, the main point is that Tripwire gives you highly reliable auditing reports of any changes and, any time that a data breech occurs, unless it's a fully completely passive one where you're only sitting there, you know, a skimming attack you know is completely passive, nothing can really catch that. But the moment you create an attack that opens an attack vector, you have to make some changes to the system that you are attacking. And those changes have to be at the level that will be detected by a tool like Tripwire, in particular. That attempts to monitor these kinds of changes to systems.

The good thing about Tripwire is the fact that once you have configured it properly, all you will get are those highly reliable exception reports and you will get them on a regular basis. And you will be able to detect if a breech is occurring and stop it before it causes a lot of damage.

I guess this next question is more of a scaling question. I'd imagine a large department store would have a lot of these point-of-sale systems. How would Tripwire help oversee a system as large and complex as that?

Well, simply because it's so scalable, you can install Tripwire literally on tens of thousands of machines and go through the process of doing this regular audit report as well as an exception report. The one thing about even large department stores that do this, they tend to have relatively standardized types of point-of-sale systems and they all report to centralized machines that perform initial reconciliation that concentrates data from a region, from a segment of the stores or what-have-you. In many cases, then they send it over to a back office machine or back end machine or merchandising system of some sort that centralizes everything.

You have a lot of points along the way where changes would have to occur as part of an attack vector. Again, as we spoke before, and with a tool like Tripwire, you get visibility to all of these at all points of the chain. So when something like that happens, it's very easy to detect, usually if you can configure Tripwire properly, within 24 hours, you will know that something unusual has happened. You can start an investigation and you may stop a breech from going beyond a few thousand cards to several tens of millions as we've seen recently with TJX. You can end up stopping it when only, say, 5000 cards were breeched -- a much better result.

How would Tripwire have handled something like TJX, as you brought up, which was picked up via wifi?

Again, it's the same story. The attack vector -- so, yes, wifi was the entry point but then they had to make changes to, essentially to open a doorway for themselves or a pathway for themselves into those centralized systems. It could have detected it all the way up to the networking device that may have been changed, or it could have detected it at any point along the chain. And alerted if something was going on. If somebody was actually monitoring those reports for things that are weird, they would have figured out that something was going on and started an investigation.

That point of alert, that thing that says, "Look, this is kind of funny, go see what it is," is usually the most critical one. And you want to be able to catch it anywhere you can.

What are some of the common mistakes people make when trying to secure point-of-sale systems?

Number one, data retention. Point of sale systems really shouldn't be keeping data. Some of them let data go away daily. That's, I would say, that's probably a good compromise between the needs of the merchant as a business and the end security. Some of them use flash devices or flash memory and they don't actually go through the process of removing transactions from that terminal on a regular basis, meaning that it continues to accumulate it. It could happen as well in that back office PC that centralizes those transactions if the terminals don't have their own memory.

In one case that we were working on, with merchants we were working with, they had exactly that kind of set-up, the POS terminals were no danger in the sense that they did not have transactions stored on them. But that back office machine never went and removed all their transaction. So they have been stored there for many, many years and it was a very attractive target for any potential hacker who discovered that particular flaw in design.

So that's definitely is number one. And there's no reason why those terminals should store just that data transaction. There simply is no business reason behind that. The next one is authentication into those terminals usually is done in a way that is easy to get around. There are many reasons for that but sometimes it becomes almost egregious as to how it's implemented. The main reason, of course, is that it has to be usable for the employees who are coming in and out. It's a seasonal industry in many cases, explaining complex security approaches is usually a little bit more difficult.

In addition to that, those transactions have to be stored in a format that is at least an encrypted format on those terminals and in many cases that I've seen, in all the terminals in particular, that is not the case. So once you bypass the very, very easy authentication method, the transactions are completely available to you. You don't have to make any effort in getting them out of the device at that point. There are a few others, but these are the most common, if you will.

What do you think will be the future for POS in terms of vulnerability and security?

Well, what I think is one thing, what I hope is that the data retention issue that I mentioned previously becomes much more critical in terms of design. Again, if you reduce the exposure at that point, it means that the risk of any breech, in terms of what damage it may do gets reduced significantly. It is certainly true that a lot of security vendors will try to capitalize as the POS as a major attack point and increase, as a result, at least in some cases, will increase security for folks who go ahead and utilize a more secure version of the POS system.

I'm not entirely certain as to whether this will become extremely widespread. Our experience is that retail is a very conservative industry. There needs to be a very clear understanding of the ROI on investment on something like, say, going out and spending a lot of money on each POS terminal. Again, if you reduce the risk from exposure, then the cost of exposure goes down. So I really do hope that the notion of really implementing strong data retention rules at the POS would become very popular.

Or the next thing I think will happen is that we'll see much more control on those points along the chain where POS terminals are reporting their transactions, or they get consolidated. Those areas usually hold transactions from multiple POS terminals and therefore become more attractive in and of themselves. They also become an entry point and an attack vector into the main systems, those merchandising systems sitting at the back end and thus they become very important when trying to discover a potential breech.

Beyond that, you know -- I'm not a prophet!

Posted by pschooff in |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/2893

Comments Post a comment




Remember Me?

(you may use HTML tags for style)

We ask that you type your code (displayed below) in the text box.This code is an image that cannot be read by a machine. It prevents automated programs from submitting comments.


Code:



Most Recent ebizQ Blog Entries
ADVERTISEMENT
Subscribe
News Feed
Blog Roll
Blogosphere
This Work
Accountability:The opinions expressed in this blog are solely representative of the blog's author, and not of ebizQ

Subscribe to our Newsletters
ebizQ Weekly Gold Club Update
Live Webinar Updates
Updates from ebizQ Partners
ebizQ SOA Update
ebizQ BPM Update
ebizQ Security Update
ebizQ BI Update
ebizQ Open Source Software Update
Virtual Show Newsletter
Your E-mail Address:
BAM: The Killer App for CEP
Date: Feb 12, 2008
Time: 12:00 PM ET
(17:00 GMT)

I WANT TO ATTEND
Event Processing Market Pulse
Date: Feb 14, 2008
Time: 12:00 PM ET
(17:00 GMT)

I WANT TO ATTEND
Archived Webinars | Upcoming Webinars

Marketing Solutions | Feedback | About ebizQ | Unsubscribe | Privacy Policy | Site Map