Re: RSA Compromise

["Ivan ." <ivanhec () gmail com>]

Navin

see below

cheers
Ivan

Making sense of RSA ACE server audit logs

Following up on the earlier post by fellow ISC handler Rob on the RSA
Breach, here's a 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
tokens still has to guess the userid and PIN to get a successful
login. With ample foresight :), the authors of the ACE/RSA software
seem to have expected such a scenario, 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 someone has a good token (or the seed values) and either
fumbles or tries to guess the associated PIN. 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. But if you see 1-2 of these per user and enumerating
several of your users .. then you should take a closer look for sure.

AUTH_PRINCIPAL_RESOLUTION / AUTH_ALIASES_NOT_FOUND will appear in the
log if the userid that tries to log in does not exist. Again, you can
expect a couple of these per 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 you should keep a close eye on:

NEW_STATIC_PCODE_AUTH_SUCCESS shows up in the log whenever someone
logs in with a static passcode. This means that the user has lost his
token, or never had one, and that someone with ACE Admin privileges
has assigned a static password instead. Yes, this is possible, and it
basically turns two factor authentication into two-password
authentication, while still everyone can claim to the auditors that
"login goes via the SecurID server". There are legitimate emergencies
for this kind of login, but it certainly 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 or wasn't stolen in the recent RSA heist. But if you're
not doing so yet, you certainly should check your ACE server audit
log.

http://isc.sans.edu/diary.html?date=2011-03-29
and
http://isc.sans.edu/diary.html?storyid=10609


On Sat, Apr 2, 2011 at 6:49 AM,  <navin1406 () yahoo com> wrote:
> Hi Guys,
>
> How serious does the RSA breach looks like and what proactive measures should we take to mitigate exposure if any?
>
> Thanks,
>
> Navin
> Sent on my BlackBerry® from Vodafone

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------