Thus Quoth the Token Nevermore

Traditional tokens are a dying breed

There is an oft used term that a recent event is a 'sign of the times'. In 2011 though, technology has dictated the ringing of the bell announcing the dead - at least in terms of the traditional token. Gone are the days of the telltale SecurID key fob dangling from your house keys. The recent hacking of RSA exposed data that could ultimately compromise the security of the widely used SecurID token. In their defense, it's not the first time tokens have been attacked; and yes, compromised. Tokens are, in fact, still around. So, why, you may ask, is this year different from previous ones?

Let us review:

• During the 70's the 8 inch floppy was king




• The 80's gave way to the 5 inch floppy disk & later, the 3.5 inch




• The 90's took it a step further and gave us the CD, USB, and DVD for media alternatives




• All hail, the Blu-ray of the new millennium

What this shows is that all things change. Nothing, especially where technology is concerned, is constant. Two factor authentication is no exception. While two factor authentication has seen improvements since the days of yore with complex and cumbersome challenge tokens, we're still relying on this antiquated technology in the majority of physical tokens today.

If you think that a solution is great only because it's stood the test of time longer than most, think again. Columbus thought that, and he ended up only 9,000 miles away from his goal. This sure isn't India...

The simple fact is there are several issues with physical tokens and the way they are, and continue to be, implemented. Some of these problems have been around for almost the entire 30 years we've been using them.

Here are a few examples:

• Token deployment, even as simple as issuing a SecurID token to an employee, is tedious, and time consuming; sometimes even relying on snail mail which could take in excess of many months for distribution over an entire enterprise




• Over 10% to 15% will be damaged, lost, or stolen every year




• Barring all this, at best, a token's lifespan is 3 to 5 years




• Users forget their tokens - even ones attached to key rings; Contractors lose track of which token is for which client, adding more confusion




• Physical token systems require updates, maintenance, re-synchronization, and replacement

To every problem, a solution exists. How can we, as a global enterprise, still be secure, yet use technology that is already in place? The answer is simple - and you already own it.

Enter: The Mighty Cell Phone.

SMS has been in use for years, but with the global community reaching in excess of well over 5 billion devices currently in use, it seems most of us have overlooked one thing SMS is good for - that being to act as an authentication token. A passcode is sent to your Droid phone, for instance, thus eliminating the need for a physical token. SMS alone is not the answer, though. SMS does, in fact, have its pitfalls. The real answer lies in an ability to create similar (or even better, stronger) security that is already inherent in devices we already predominantly use. The unreliable nature of delays in messaging, cellular dead zones, or network issues with your provider are actual issues you may very well face. I am certain that those who wish to still cling to an antiquated technology, such as key fob based tokens, are sure to use as a rallying cry. At what point, though, do you stop bailing the sinking ship, and find a newer, better, stronger one?

Now Entering: MobilePASS.

MobilePASS by SafeNet, is a technology that still uses the same methodology of tokens, that being a two-factor authentication system. It simply does it in a better way. With MobilePASS, there's no additional hardware to lug around with you, the technology is easily deployed (and furthermore, managed), and the learning curve is non-existent. You do know how to download an app, don't you?

Strong encryption is still on the playing field. The tried and true two-factor authentication is still in the mix, yet the cumbersome, expensive, and dare I say, recently compromised hardware token, isn't.

"But what about my Windows Device?"

"There's an App for that".

In fact, not only is there an app for that old desktop of yours, but there's one for the iPhone, Blackberry, Windows Mobile, Android, Java 2ME, and even Out Of Band devices via SMS. Did I mention that it also covers Windows Server based platforms as well?

To log on to a secure network, from a laptop, PC or even an iPad (with the right software installed of course), users generate a One-Time Password (or OTP for short), via the MobilePASS app on their phone, and then enter this in the login screen thus creating a secure connection. Out of band delivery can also be granted via SMS or even email.

While MobilePASS by SafeNet is only one solution out there that utilizes cellular technology to end the need for the traditional token, this sort of solution is great for many reasons.

It is estimated that such a solution as moving to an SMS based method such as this can reduce the ongoing running costs of authentication means by over a whopping 40 to 60 percent! Lower cost, higher convenience, and utilizing technology already in place.

SafeNet is a global solutions partner of NWN Corporation. As such, NWN can leverage this partnership to assist our clients in lowering their bottom line, ensuring the security of their infrastructure, and delivering the best technology-based solutions currently available.

Where Compliance Went Wrong

Earlier this week I had the opportunity to give a presentation on the new Massachusetts Privacy law or 201 CMR 17. The goal of the presentation was to give attendees a detailed understanding of what the law required, penalties for non-compliance and a roadmap for cost-effective compliance. The presentation itself however, is not the focus of this discussion. Rather, a question asked by an attendee is. During the course of the presentation, one participant asked "if I'm 100% compliment with 201 CRM 17, will I still be fined if there's a breach?" My short answer at the time was "Yes" (although it is still a little unclear how that fine will be determined. The question however, got me thinking.

With regulations like Sarbanes-Oxley, GLBA and the HIPAA Security Standards the focus is on input. What do I mean by that? Well, many of the various laws define that you must implement controls to make sure something bad doesn't happen. In some cases, organizations are left to determine the specifics of the controls while in other, the control requirements are relatively detailed. They key is that these regulations tell organizations what they must do to stop bad things from occurring. I'm referring to this as "input" focus because the regulations focus on what needs to go into a security program.

The converse to this is an "output" focused law. California Senate Bill 1386, the first well known state privacy law, is an example of this. The law is very light on requiring organizations to do anything as far as implementing controls. It is very short and to the point. If you suffer a security breach that results in the disclosure of personal information, bad things will happen to you. The only "control" really mentioned is encryption and even that is not required. This approach allows organizations to perform their own risk assessment and implement the controls they feel are necessary to reduce risk to an acceptable level.

While there is probably no perfect solution, the question asked during my recent presentation highlighted the major flaw in "input" focused regulations. With this type of regulation, compliance does not equal security. Recent security breaches where the organization was previously identified as "compliant" highlight this problem. Unfortunately, the response to these events was to blame the auditor. I watched numerous discussions where people made the case that auditors should be held responsible should a "compliant" organization suffer a breach. I'm sorry but that is just plain stupid. That removes the decision making responsibility from the organization and put it in the hands of a third party who will do what is in their best interests. That means, to a large degree, massive risk avoidance rather than reasonable risk management. Risk avoidance then results in significant increases in cost that are way out of line. Ask yourself this, if you were told that you had to audit another company for security and if they suffered a breach, you would be held responsible, what would you do?

Another problem with "input" focused regulation is that it forces organizations to focus on the specific regulation requirements rather than on good overall security. In response, many organizations create checklists for compliance. They will do the minimum to check off each item in the checklist and nothing more. Suffice to say that this is not the best approach to security either. In effect, it gives the attacker a list of exactly what you are doing and what you are not doing to secure sensitive data. It's no wonder "compliant" organizations often suffer security breaches.

Back to the questions I was asked. If I'm 100% compliment with 201 CRM 17, I will still be fined if there's a breach? To me, that sounds like a significant amount of input focus. I'll restate the question. If I complete everything on the 201 CMR 17 checklist, do I really need to worry about actually protecting personal information? The same question can be asked about other regulations.

Now, let's look at output focused laws like many of the state privacy rules. They simply say that organizations are requited to protect personal information and if they don't, bad things happen. Generally speaking, there are no requirements for periodic audit and there are no checklists for compliance. If you protect personal information, you win. If you fail to protect personal information, you suffer the consequences.

It seems obvious to me that the current method of checkbox security doesn't work well. All it has done is increase IT spend and increase costs of external audit without any real gains in security. Perhaps more focus on achieving security goals and objectives and less focus on a bunch of predefined controls might be a good idea.