federalcto.com The Blog of a Federal CTO

30Mar/110

This why we have standards

Blah, blah, blah

RSA breached

Blah, blah, blah

The last week or so has been really interesting.  Yes, one of the hot topics is the RSA breach.  I'm not going to link to it - if you haven't heard by now, I'll wait until you google it, and then come back.

For me, the interesting part was that it was an APT (Advanced Persistent Threat).  It's a hot topic in the Fed space, but most on the commercial side have never heard of it (want to know more about APT?  Check out this 30 minute session I did a few weeks ago).  However, our internal discussions started going down the "are we vulnerable to this same attack with our Defender product?"  I replied with some glib comment saying, "No.  Duh!" and went on.  Not really, and it was much more pleasant, but it was definitely short on details as to why.  But the conversations continued.  Now, for someone on the outside, I probably would have given a more detailed answer, however I thought it was obvious that being standards-based, as we are, we avoid this sort of attack simply by following the rules instead of creating our own.

Well, last night, the questions continued, so I put together much of what is below in an email to explain.  The gist of this is that Defender support OATH which means that we can use any token to provide 2-factor authentication and the algorithm used to calculate the next "random" value is a standard.  By using a standard, a breach of the code simply isn't possible.  Why?  Because the code is already public.  There's nothing to hide, so there's nothing to steal.  And what that means is if there's a problem, it is with the token seed records.

For those that don't know, one-time password tokens all operate on a pre-defined seed.  That seed is used to calculate the next password by the device.  And when I say device, I include software tokens, and any other "thing" that provides a 1-time password.  RSA does it, we do it, everyone does it.  That seed is unique to the device, and kept secret by the owner of the token. Here's where things become interesting.

If you steal the seed records, you only have 1/3 the puzzle in getting to someone's login.  Not only do you need the seed (to calculate the next, unique password), but you also need to know the account it's tied as well as the 'something you know' part of 2 factor authentication, which is usually a PIN or a predefined password.  In the case of Defender, most customers use the AD password, which is usually better than a 4 digit PIN but that's irrelevant for this conversation.  However, knowing someone has your seed record, as a user, ought to make you nervous.  If one of the two factors you rely on is compromised, then it's no longer 2-factor, now is it?

The next bit is a direct copy/paste from the email I wrote.  Vasco is one of our token suppliers, and the ones make the Go tokens we most often use for demos.  So it's the one most people inside of Quest are familiar with, which is why I used them in the example below.

--

To add to this, let's say Vasco have a breach, and they get both source code from Vasco, as well as all their token seed records, including those of our clients.  And the breach is so bad, they get our purchase orders (from Vasco) and maybe even see which tokens may have been drop shipped to our clients on our behalf.  That's pretty bad.

But none of that mean you need to rip out and replace Defender.  Our client can simply say, "We no longer trust Vasco tokens, and will switch to [insert name of OATH token vendor]."  The Defender server stays intact, nothing needs to be changed, upgraded or patched.  The customer simply gets a new set of tokens, loads them up, and gives the token to their users for self-service registration.

In the case of RSA, they are a tightly coupled system, where tokens, algorithms and authentication servers are all tied together.  If you don't trust RSA, and feel they've been compromised, then you need to throw out the whole lot.  In our case, Defender simply cannot be compromised in that way as we don't do anything secretly or have proprietary algorithms.  OATH is published.  RADIUS is published.  If you trust those standards, then Defender is fine.  The same for AD - we store our data there, but its a "pseudo-standard" where it's ubiquitous, and there's no deep dark secrets about it.

This is why I keep saying that our approach is more sound, and ultimately, more trustworthy.  Not because our code is better (it may be but RSA have some clever folks, too) but because our entire approach/methodology does more to protect the client from a breach such as this.

There's still a cost, and you have to throw out the tokens, but you don't need to learn a new toolset, and plan a migration from one auth system to another.  Especially in a stressful time when your CISO is breathing down your neck, asking how much of a threat is this.

--

That was really it.  I don't have much more to add at this point.  Other than maybe that we have a really cool, new token from Yubico called a Yubikey.  You should ask for a demo, but it's something you have to see in person.  USB-Based, but works on Windows, Macs, Unix, etc.  Very clever, that token.

14Mar/111

The Advanced Persistent Threat and Cybersecurity Webcast

For those of you that tuned into today's webcast with myself and Paul Harper, thank you.  If you haven't seen it, it will be available shortly, and I will post the link back in this blog post.  In the mean time, if you'd like a copy of the slide deck I used today, here it is: 20110314_-_Insider_Threat_Webcast

   
Copyright (C) 2010-2011 Dmitry Kagansky – All opinions expressed are those of the respective author and do not reflect the views of any affiliate, partner, employer or associate.