News & Commentary

10:37 AM
David Jevans, IronKey
David Jevans, IronKey

RSA's Data Breach: Steps Banks Should Take to Protect Customers

There are several practical moves banks can make to prevent hackers from taking full advantage of the recent RSA breach.

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.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.