Following up on the earlier post by fellow ISC handler Rob on the RSA Breach, here'sa couple practical things you can look for in the audit log of your RSA ACE(SecurID) server.In line with Rob's scenarios, an attacker who is in possession of the seed values of your SecurID tokensstill has to guess the userid and PIN to get a successful login. With ampleforesight :), the authors of the ACE/RSA software seem to have expected such ascenario, and have implemented an audit log that fits to the case:
AUTH_FAILED_BAD_PIN_GOOD_TOKENCODE will show up in the audit log whenever someonehas a good token (or the seed values) and either fumbles or tries to guess theassociated PIN. You'll get quite a few of these in normal use, simply becauseauthorized 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. But if you see 1-2 of these per user and enumerating several ofyour users .. then you should take a closer look for sure.
AUTH_PRINCIPAL_RESOLUTION / AUTH_ALIASES_NOT_FOUND will appear in the log if theuserid that tries to log in does not exist. Again, you can expect a couple of theseper day in normal operation, it is just a fact of life that users can't type their own names ... 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. Take a closer look!
Irrespective of the recent RSA breach though, there is one audit log entry that youshould keep a close eye on:
NEW_STATIC_PCODE_AUTH_SUCCESS shows up in the log whenever someone logs in with astatic passcode. This means that the user has lost his token, or never had one, andthat someone with ACE Admin privileges has assigned a static password instead. Yes,this is possible, and it basically turns two factor authentication into two-passwordauthentication, while still everyone can claim to the auditors that login goes viathe SecurID server. There are legitimate emergencies for this kind of login, but itcertainly is a dangerous option to have - if someone can smooth-talk your Helpdesk,they can get in, without needing a token.
Considering the latter, you probably shouldn't worry all that much about what was orwasn't stolen in the recent RSA heist. But if you're not doing so yet, you certainly should check your ACE server audit log.
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.