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.

About the Author(s)

Kelly Jackson Higgins, Editor-in-Chief, Dark Reading

Kelly Jackson Higgins is the Editor-in-Chief of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise Magazine, Virginia Business magazine, and other major media properties. Jackson Higgins was recently selected as one of the Top 10 Cybersecurity Journalists in the US, and named as one of Folio's 2019 Top Women in Media. She began her career as a sports writer in the Washington, DC metropolitan area, and earned her BA at William & Mary. Follow her on Twitter @kjhiggins.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like

More Insights