The Honey Stick Project

This week I heard about two interesting devices.

The first is a story of a digital camera that was stolen (click HERE). The owner was surprised to receive an email with pictures of the thieves. Apparently, the owner had forgotten that they had a $100 special SD card with Wi-Fi built in, called Eye-Fi (click HERE), and the ability to upload files to the owner’s site. It actually sends its data via email or upload to a file repository. It’s not clear to me exactly how this works yet, but if it can do it without spending cycles on the finder’s computer it would solve a lot of the privacy and liability issues I’ve written about in my paper.

Another thing I heard about this week was the Trackstick II Personal Tracker (click HERE). It looks like a USB Drive that has GPS tracking on board, and track and store its own location and movement information. However, I’m not sure if this one can store user files or data, and it doesn’t look like it can “phone home”. But it’s only a matter of time…

If a “phone home” program was added to it in case of loss, I’d see this as having some liability issues, if the finder’s computer were damaged during the program’s unauthorized execution.

It looks like we’ll be seeing a lot more devices integrating different technologies. All the more reason to be very careful what you stick into your computer. If you thought Double-click’ and web bugs had privacy issues, just wait until your new camera registers itself and sends your picture and PC configuration to their server.for more “personalized” support services.

Or what about something like Napster for cameras? Camster anyone? Will you be able (or knowlegeable enough) to prevent your camera from “sharing” your photos and files with other devices nearby. After all, sharing sounds good, right? A lot of manufacturers have not figured out that allowing open access and sharing by default in new devices usually creates serious and fast-spreading privacy and security issues.

Listening to a recent episode (#134) of the Security Now! podcast by Leo Laporte and Steve Gibson (at http://www.grc.com/securitynow.htm), Steve noted that he had left his USB Drive with his key chain when he took his car in for service. He felt safe because the drive was encrypted using TrueCrypt (a public domain encryption product).

Subsequently, (in episode #139) a listener wrote to Steve to tell him some horror stories from auto shops of how the mechanics at some places (even some big name dealerships) will routinely snoop through cars in for service to see if there are any MP3s, CDs, etc. Mostly, they just want to “harmlessly” expand their music collections, but who knows what they might find.

On top of that, one listener pointed out that TrueCrypt uses an executable on the key to do encryption and decryption of the data. If that executable were replaced maliciously, any program could be made to run when you think you are decrypting the data on the drive.

My concern is that such a program might even give what looks like a valid error message saying something like, “TrueCrypt system error - data file corrupted. Please enter your password to attempt a recovery”. If you entered a password, it could be snagged and sent back to the mothership.

This logically begs another question. Are mechanics being paid to plant malicious code on media devices left in your car? Best not to let them have access to any of your media or devices while its in the shop.

Of course, one might leave a honey stick in one’s car to test their integrity. On the other hand, perhaps car dealers wanting to keep their teams honest might be interested in planting test devices that can be tracked.

Here’s a simple tip that can save you a lot of trouble.

DON”T ENTER PASSWORDS WHERE YOU AREN’T EXPECTING THEM!!!

I recently came across a suspicious email in my spam folder. It appeared to be from a payroll service I’ve actually dealt with.  There was almost no way to tell for sure if it was from them.

The subject line included a recent date and the word “Paystub”. There was a PDF attachment and even with image loading turned off, there was a label that said “This PDF is password protected”. It had a single field with the word “Password” beside it.

I have yet to determine if this email was authentic or a real phishing attack, aimed at gathering passwords. But if this is a phishing attack, here’s what could happen if I entered a password:

1. The password gets collected, and an error message is produced saying “Invalid password, please try again”.  Knowing that we should all be using different passwords for each site or program “to be secure”, I may simply think I should have used one of my other dozen passwords (don’t we all use that many password variations?!)
2. Hitting “Enter” or clicking on a button causes the password to be sent back to a mothership, including enough information for them to identify my email address as being valid.
3. No only do they now know that this email address is valid, but they have at least one version of my password. If I tried several different ones, they could have them all.

This is dangerous because people think they “NEED TO SEE WHAT’S INSIDE” then encrypted email. It’s like arriving at your office with a wrapped package that has lots of heavy tape sealing it up. The more tape there is protecting it, the more you want to open it to see what it is that could be so sensitive.

To make things worse, there aren’t a lot of easy ways to automatically check for the authenticity of such a package. It can have a digital signature on it, which you could verify. But there are a lot of usability issues yet to be solved in verifying digital signatures in the wild. Enterprises that use Public Key Infrastructure regularly would have an easier time letting people ensure the authenticity of emails and attachments. But most people won’t have that luxury.

So, if you aren’t expecting to be asked for a password (even on a website - which can effectively trick you the same way) you should call up somebody in the originating organization to verify that it is valid, and that it is important. I would also notify them that they should not present password protected information without an easy way to securely verify that it is real.
I am actually surprised that I haven’t seen more evidence of this type of phishing, but I’m sure we will in the future.

Nobody really knows what the long term effects of data loss are. The main differences between losing data and losing solid assets are:

1. Data can be copied, or even broadcasted, instantaneously to many locations around the world. Once the bytes are out of the bag, you’ll never be able to round up all the copies. Just ask any celebrity who has had lies and slander written about them in the tabloids. You might get a retraction printed by the original source, but it’s too late.
2. Public data often gets indexed for free. If it’s on a server connected to the Internet, there’s a good chance it will get indexed by Google or any one of the dozens of search engine crawlers. This means that it can be found by anyone, with the right search query.

You can start to get the feel for how common data breaches are becoming by scanning through the history at the Data Breach Blog of SC Magazine (click HERE), the Breach Blog (click HERE), or simply doing a search on things like “data breach”, “breach disclosure”, or similar terms in places like Google News. (more…)

In a nutshell, if you are collecting information about somebody who visits your website, then that information may be Personally Identifiable Information (PII). Things like credit card numbers, group affiliations, etc. may be considered PII.

One thing I was concerned with in designing the HSP was the fact that my original plan included capturing the IP addresses of people accessing the files on the Honey Sticks. This would potentially allow me to do a lookup in order to find out what company the network was registered to. It might be an ISP, but it might also be a private company.

One could argue that collecting the company name might be considered PII. In the beginning, I did not want to be collecting and handling PII.  So, based on wordings found on the OECD website (www.oecd.org) the collection of IP addresses may or may not be considered PII, depending on how you were using it. In the case of using IP addresses for website maintenance and performance tuning, they would not be PII. However, if used for “profiling or targeting” it might be. So, I decided to steer clear of this issue in Stream 0.

As a result, I do not collect IP addresses for the study, even though they do show up in my logs. Logs get rolled over after a period of time.

For all practical purposes, I can not identify individuals who use the Honey Sticks. There may be situations where other logs record a user’s actions and might be able to correlate them. But I do not receive or handle these logs.

For a more detailed discussion of privacy and Honey Sticks, please click HERE to review the paper I wrote on this subject.
In future streams, I may collect PII from Honey Stick users or other individuals, but will have a formal process for handling it.