RSA's Data Breach: Steps Banks Should Take to Protect Customers
In the wake of RSA's startling data breach admission, banks faced with few facts are scurrying to analyze what likely happened and what comes next from the hackers. In describing the theft, RSA stated "this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack." The most likely scenario proposed by industry experts is that the secret codes, also known as seeds, used to generate one-time passcodes have been compromised or stolen, potentially allowing RSA SecurID authentication to be performed without a genuine token.
To monetize their successful breach, the hackers must match their stolen data with real user identities. Criminals will likely turn to crimeware such as ZeuS and SpyEye to infect the computers of online banking users. The Anti-Phishing Working Group estimates 25 percent of all computers are infected with this type of crimeware -- making all banks' customer base a viable target.
These toolkits and the botnets they belong to can capture massive amounts of data including user inputted token codes, authentication PINs, private challenge questions, and even token serial numbers. And functionality such as No-$H!+ in ZeuS command and control reporting automatically eliminates unneeded data and identifies the credentials criminals are looking for.
All of this means en mass attacks on banking customers using SecurID and their computers is child's play compared to the original theft of RSA data.
Aware of the potential for compromise to online banking accounts requiring RSA SecurID authentication, RSA has recommended customers strengthen the security of SecurID deployments. While best practice recommendations, they do not address the vulnerability of online banking users, their computing environment, and banking SecurID deployment scenarios.
Some immediate steps banks can take include:
- Add host-based security controls and protection: Mass attacks to monetize the stolen RSA data will likely be performed and be most effective on banks' customers. Without strong protection from man-in-browser, keylogging, browser monitor, DNS tampering attacks among others, customers can be easy prey. As described by the new 2011 draft FFIEC guidance, these new host-based security controls isolate the banking session and securely connect users with your banking site. Host security controls that isolate users from malware rather than try to detect known attacks are much more effective.
- Look for subtle anomalies: While the information provided by RSA and others recommend looking for failed authentication attempts, it's unlikely criminals will use brute force attacks to identify PINs because that would spoil their plans. Instead, look for subtle anomalies such as successful authentication attempts, then quickly logging out, or successful authentication from a different geographic location might be a tipoff. While false alarms are bound to occur, this is the challenging reality facing banks.
- Add new customer education: While banks don't need to alert customers specifically to the RSA breach, institutions should add specific new topics to their education programs. Topics relevant but likely not discussed before should include that banks will never ask for a token serial number after registration or that a bank will never ask for a token code over the phone or outside of authentication and payment authorization.
- Review token issuance and distribution processes: The entire issuance process of tokens should be reviewed. Serial numbers and customer information are likely stored in internal databases used for issuance and may even have been provided to third parties to perform device distribution. If a third party is involved, consider if it is necessary for them to be provided with and/or maintain this information.
- Segment authentication infrastructure: As recommend by RSA, the RSA Authentication Manager and any other systems that link customers to tokens should be segmented and hardened. Criminals have shown they can infiltrate deep into an organization, and systems that link users and tokens could come under attack. Making attackers work through segmented networks may alert you to their presence. If a service provider delivers authentication as a service, ask them about this risk and how they are protecting their systems.
- Educate call center and customer support: Like customers, call center and customer support staff should receive new education related to the RSA breach. Staff should proactively educate customers on what fraud looks like even during non-fraud or non-technical support calls. Proactively educating customers can reach those customers who would otherwise not take note of fraud education. And, it reiterates to the customer that you are looking to protect their security.
- Require PINs: SecurID authentication should always be performed with something the user has (their token code) and something they know (a PIN or password). Using a PIN in combination with a token code, will make it harder to attack online banking systems if an attacker has matched a user to their token. Of course, as discussed, it's not that big a leap to go from matching a user to their token and capturing their PIN as well. While an important best practice, this step alone won't stop criminals.
RSA SecurID is a technology that will remain in use by banks as part of a multiple layered security approach. Decommissioning or changing online banking applications are options that can't prevent a near-term attack. Instead, banks need to focus their attention on customers using SecurID and isolating them from likely attack methods.
David Jevans is the founder and chairman of IronKey, a provider of security solutions.
Tweet This