SecurID Breach Warning Signs In The Audit Logs

SANS Internet Storm Center on what to look out for in your ACE server logs in the aftermath of the RSA SecurID breach
Most security experts caution RSA SecurID customers not to panic about the breach the security company revealed last week. But that doesn't mean they shouldn't plan for the worst-case scenario: The SANS Internet Storm Center has come up with a list of things to watch out for in audit logs -- just in case the bad guys got the keys to the kingdom, stole your token "seed" values, and were able to then acquire logins and PIN numbers for a full-blown breach of your two-factor authentication system.

SANS ISC handler Daniel Wesemann spelled out the specific audit log entries that could show up in your RSA ACE server for SecurID if there's trouble. But even if an attacker had grabbed seeds from an organization's SecurID tokens, he would still have to figure out the userID and PIN to log in, Wesemann said, so this is one of the worst-case scenarios. His post comes on the heels of fellow ISC handler Rob VandenBrink's, who explained in a post yesterday on the ISC SANS site just how bad it could be.

"Long story short, no matter how bad RSA's breach might or might not have been, System Administrators have it in their power to implement truly effective mitigations," VandenBrink wrote.

Here are some entries you hopefully won't find in your audit logs in the ACE server. But if you do, take heed:

This log entry is probably nothing to worry about unless you see one or two of them per user and beyond, according to SANS ISC. This occurs when a user with the seed value mistypes his PIN or tries to guess it, for example. "You'll get quite a few of these in normal use, simply because authorized users sometimes forget or mistype their PIN. If you see a lot of these against one single userid, chances are it will lock after "n" failed attempts and no harm is done," Wesemann noted.

Once in a while, a user will mistype his userID. But if several of these show up in your audit logs, something fishy could be going on: "But if you get a lot of these, and especially if the username format is completely different than the userIDs in use, someone might be trying to guess your users from a phonebook or LinkedIn accounts," Wesemann said.

This entry comes when a user logs in with a static passcode because he lost his token or was given a static one. This should be rare, however: "There are legitimate emergencies for this kind of login, but it certainly is a dangerous option to have -- if someone can smooth-talk your help desk, they can get in, without needing a token," Wesemann said.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Editors' Choice
Jai Vijayan, Contributing Writer, Dark Reading
Andrada Fiscutean, Contributing Writer, Dark Reading