Solutions for Portable Security

Have you ever forgotten a password for some service that you’ve signed up for and then needed to click on the “forgot my password” link? After providing some identifying information and perhaps answering some challenges, you’ll have your password reset.

I’ve seen the password reset operation (that last step) happen a few different ways:

· You’ll be asked to type in a new password and confirmation
· You’ll be sent a new password from the service
· The service will send you your forgotten password – *OUCH*

Why does the last method hurt? Well, first of all it means that the service actually has a database of user passwords stored somewhere. A breach of that database will reveal your password to adversaries. But that’s OK because it’s only the password to the service so the damage will be limited… right?

You know as well as I do that this isn’t the case and the government is now painfully aware of it. The recent Gawker hack has compiled a collection of federal, state and local government email addresses and passwords for future attacks. The hackers know that many people use the same password for many different services as they were quoted (grammar intact) saying to their community – “These people more than likely use the same pass everywhere. Try to gain access to the @email STMP using the email/pass combination also google their email address to find other accounts on the inernet [sic] they may have and try their password with said accounts.” (see http://fcw.com/articles/2010/12/13/gawker-hack-may-put-government-workers-at-risk.aspx?s=fcwdaily_141210)

Even without being hacked, it is very disturbing to know that some service providers actually have access to your password and therefore also have your password to many other services. You might want to check the fine print on your online banking agreement and ask yourself whether they’d consider that you’ve “safeguarded” your banking password by giving it to someone else. Essentially that is what you are doing when such a service stores it in a database regardless of how carefully you protect it.

The practice of maintaining databases of user passwords is not limited to the security-ignorant web service provider. Shamefully, there are security device vendors out there that are doing the very same thing for their device recovery service. There is nothing special about a password to a USB device that makes it any less likely to be used for other things.

There is an easy test to figure out if your deployment of security devices has a password database on the back end. Just request a password reset and see what happens. If in the end you get your “forgotten” password sent to you, then the answer is clear. Your best course of action in this case is to change the password wherever it is used for other services and don’t use your device password for anything else that you really need protected.

For more related thoughts see my other post on web logins (http://www.mxisecurity.com/blog/cto/2009/10/21/how-about-opt-in-certificate-web-logins/)

In the world of managed secure USB storage devices we are seeing more requests for a “Remote Kill” or “Remote Wipe” feature. The idea is quite simple. From a central point of management an administrator can mark a particular device (say by serial number) to be disabled or wiped whenever it is detected plugged into some machine on the Internet. Sounds great, right? It would be, except that achieving this capability in reality is not so simple.

I can think of two common remote kill scenarios that organizations are interested in:
· Lost or stolen device
· Rogue employee

If a device goes missing, there is great peace of mind in knowing that the data on the device is completely inaccessible should it end up in the hands of anyone but the owner.  Remote kill would certainly ensure that this is the case.  However, strong authentication mechanisms and policies (password rules, retry limits, device blocking on too many bad attempts, etc.), and hardware based encryption, can achieve the same level of assurance that your data is safe and inaccessible without deploying remote kill.  That being said, if you hadn’t set up your authentication polices properly or your device security is not fully implemented in hardware then a remote kill feature would definitely be a good remedy in this situation.

The rogue employee scenario is where it starts getting a bit complicated.  To understand why, we need to look at how remote kill works for a USB device.  Making remote kill 100% effective over the Internet requires some kind of policy enforcement server to be involved in every attempt to access the device (by 100% effective I mean that when an administrator wants to kill a device, the policy takes effect immediately and kills the device the next time it is accessed).  The policy server would ideally take part in the authentication process and a user would not be able to access the device without the server also permitting it.  At this level of involvement the remote kill function can be a message from the policy server to execute a data destruct or block command on the device, instead of the usual authentication.

Unlike cell phones USB storage devices do not have an “always on” connection to some central location.  They are only Internet accessible if the machine that it is plugged into has a connection.  You could enforce a strict connection policy but it would mean that employees cannot access their removable storage in off-line environments like on a plane.  To address the need to have off-line access some remote kill implementations allow grace periods where you are allowed to access your device for a certain period of time or a certain number of times before you need to make a connection to the policy server.

The rogue employee scenario makes the policy decision rather difficult.  Say you want to terminate the employee.  You’d like to be able to disable all access to sensitive information immediately.  The employee, knowing that he is about to be terminated and knowing that there are grace periods, simply needs to disconnect from the network and copy all the data from his USB device in one session.  Unfortunately, in this situation, the grace period allows remote kill to be easily defeated just when you need it the most.

There are options that help mitigate the risks while providing more off-line flexibility.  For example you may allow grace periods for frequent travelers but not for other employees.  Alternatively, grace periods could be disabled for office employees or teleworkers because network connectivity is required for productivity anyway.  You might only allow removable storage devices to be used on managed machines even when they are off-line (McAfee ePO has this capability with MXI Security USB devices).  This approach works if you have also implemented good data leakage prevention on the corporate machines. 
 
You can’t get away from the fact that there are always risk/cost/productivity tradeoffs when it comes to security policies and remote kill is no exception.  If you are looking at remote kill for USB devices, be aware of the limitations and think about whether the available policies are going to suit your security needs.