Internet Security Systems - AlertCon(TM)

Monitoring SecurID Authentication Failures

Posted by Tom Cross on March 25, 2011 at 6:10 PM EDT.

Following RSA's announcement there has been speculation regarding what the impact is for networks using SecurID two factor authentication. Because IBM possesses little technical detail about the issue, it is difficult to make specific, actionable recommendations.

One recommendation that has been proposed by other parties is the idea of increased vigilance regarding authentication failures on systems that use SecurID. The belief is that attackers might try to gather information required to access SecurID protected accounts, such as pin codes, through brute force "guessing" attempts. This type of activity would generate a large number of authentication failures.

While IBM doesn't have enough information to determine for certain whether brute force is a part of the attack methodology being employed in this case, keeping an eye on unexpected authentication failures is not a bad idea regardless of the circumstances. However, brute force attacks experienced by any specific company may be completely unrelated to an attempt to exploit the SecurID issue.

SecurID can interoperate with a wide array of different access control systems and protocols that may be monitored in a number of different ways. The most obvious place to monitor for authentication failures is at the RSA ACE Server itself.

However, our Proventia IPS also includes a large collection of signatures that detect different types of logins and authentication failures, and we thought it might be helpful if we provided a list of them (which is available below). Increases in the volume of one of these signatures might indicate that something unusual is going on, particularly if you have a good baseline for what constitutes normal activity. 

RSA published a list of specific recommendations for customers which are included in this Wired story. These recommendations are similar to the kinds of basic security recommendations we provide regarding protecting one's networks from Advanced Persistent Threat. For a more detailed discussion of APT please see my presentation from Pulse. X-Force has learned numerous lessons combating APT cases over time and this presentation provides a framework for approaching the problem as well as specific technical recommendations.

The <protocol>_Auth_Failed signatures look for 'an excessive number of failures to authenticate to a <protocol> server'. Many are tunable. Signature will trigger if pam.login.<protocol>.count failures occur within pam.login.<protocol>.interval seconds. Full details at each of the signature links:

HTTP_Login_Known_User
FTP_Auth_Failed
HTTP_Auth_Failed
IMAP_Auth_Failed
POP3_Auth_Failed
Rlogin_Auth_Failed
SMB_Auth_Failed
SQL_Auth_Failed
Telnet_Auth_Failed
Email_Auth_Failed
pcAnywhere_Login_Failed
Socks_Auth_Failed
VNC_Login_Failed_User
VOIP_Brute_Force
LDAP_Auth_Failed
SSH_Brute_Force
SMB_Mass_Login
SIP_Auth_Failed
ISAKMP_Brute_Force
IMAP_Login
Telnet_Login
Rlogin_Login
pcAnywhere_Login
SQL_Login
VNC_Login_Failed
LDAP_Request_Failed
Oracle_Invalid_Login
RDP_Login
SMB_Empty_Password_Failed
SQL_Empty_Password_Failed
SQL_Empty_Admin_Password_Failed
SAMETIME_Login

Comments or opinions expressed on this Weblog are the opinions of the authors alone. They are not necessarily reviewed in advance by anyone but the individual authors, and neither IBM Internet Security Systems nor any other party necessarily agrees with them. The views expressed by outside contributors and links to outside websites do not represent the views of IBM Internet Security Systems, its management or employees. All content on this Weblog has been made available on an “as-is” basis, and IBM Internet Security Systems shall not be liable for any direct or indirect damages arising out of use of this Weblog.