Phishing - it's the classic scheme that never goes away. In fact, it evolves. Amy Blackshaw of RSA offers insights on how to respond to this and other trends identified in the 2012 Faces of Fraud survey.
"Phishing is one of the oldest fraud vectors in the book," says Blackshaw, Senior Product Marketing Manager within RSA's Identity and Data Protection Group. "And even though we've seen the same trends year over year, organizations still don't feel prepared to prevent and detect them."
In 2011, RSA found that roughly one in every 300 e-mails in circulation contained some element of phishing. This was an increase of 37 percent over 2010. "And 50 percent of those attacks were focused on financial institutions," Blackshaw says.
The problem is that technological evolution has enabled more efficient and effective phishing. And not just phishing, but other forms of fraud enabled by malware. "These evolutionary traits of what we are seeing occur in the fraud landscape are really of the most concern," she says.
In an exclusive interview about the 2012 Faces of Fraud Survey, Blackshaw discusses:
- Today's top fraud trends;
- Strategies for FFIEC compliance;
- Best practices for challenge questions and transaction signing.
Blackshaw is a Senior Product Marketing Manager within RSA's Identity and Data Protection Group. In her role, she is responsible for the go-to-market strategy for RSA's transaction protection solutions which provide protection against advanced threats in the enterprise and online. Prior to joining RSA, she worked in the energy industry, bringing secure technology solutions for sustainable energy businesses. Blackshaw holds her undergraduate degree from the University of Massachusetts, Amherst, her MBA from Simmons College, and is a CISSP.
TOM FIELD: Just to get started, why don't you tell us a little bit about yourself and discuss some of your own experience fighting fraud please?
AMY BLACKSHAW: My role here at RSA is focused on bringing different transaction protection solutions to the market. So by focusing on protecting the transaction or post-log and activity, we provide defense against an advanced attack, which we're seeing aimed at financial institutions. My team is part of RSA's larger anti-fraud product group which focuses on different layered security solutions for both commercial and enterprise views. Prior to joining RSA, I worked in the energy industry bringing secure technology solutions for sustainable energy businesses that definitely face different types of fraud themselves.
FIELD: In fact, I was just reading about a new energy business fraud today so you are spot-on there.
BLACKSHAW: That's right.
Faces of Fraud Survey
FIELD: We've just completed this Faces of Fraud survey and there are a number of areas that jump out from the resources that institutions have to whether they do or do not conform with FFIEC guidance and to where they're going to be spending their money in 2012. Of all that you have reviewed, what are the responses that stand out most to you?
BLACKSHAW: First, there are such great data and insight in those results, and not only are they echoing what we hear from our customers, but it's echoing what we hear in the fraud underground as well. We all - and both of us know - that fraudsters are continually innovating to stay ahead in the arms race, but what's interesting is that the overall fraud trends really haven't changed greatly. A lot of the top threats mentioned in your survey have been effecting financial institutions for years.
Let's take phishing as an example. It looks like a top-three response for the type of fraud organizations experienced in the past year. I think about 50 percent of respondents mentioned phishing. It's one of the oldest fraud vectors in the book. Even though we've seen the same trends year over year, organizations still don't feel prepared to prevent them and actually detect them.
Another standout fact is that about 82 percent of fraud incidents are detected by the customer, with almost half of respondents stating that inadequate fraud detection tools and technologies present the biggest challenge to fraud prevention. So even though financial institutions are expecting an increase in fraud resources, I think it was over 50 percent of respondents said that they're seeing an increase of resources. We need to make sure that those resources are being expended in the most efficient and effective way. And then the fact that only 11 percent of respondents are in full compliance with the FFIEC authentication guidelines today means that we still have a lot of work to do.
I'm really glad to see that a common theme of what respondents felt was missing from the FFIEC supplement was specific mobile guidance. The fact that organizations are thinking about mobile security, even now while we know that they're still building out some of the actual functionality of mobile applications, is really key. Security can't be an afterthought here, right? So even though the supplement didn't specifically call out the mobile channel, we think banks should assume that they should apply this guidance across all of their channel platforms.
Top Fraud Trends
FIELD: You make some great points and you drill out some of the same observations that I made looking at the results, and one of them is the fraud trends really haven't changed year to year in all the years that we've been looking at fraud. The top three or four have pretty much stayed the same. Then again, the other thing that we've seen pretty consistently in fact has gotten worse is the notion that the customers really are the best fraud detection system out there. They're the ones that are most often letting the financial institutions know that fraud has occurred. Based on the trends that we have reviewed, which are the ones that concern you the most for financial institutions this year?
BLACKSHAW: Well, all fraud is concerning. But when we look back at 2011, we saw that approximately about one in every 300 e-mails circulating the web contained links pointing to phishing. So if you compare that with the total number of phishing attacks back in 2010, phishing numbers have increased about 37 percent. Fifty percent of those attacks were focused directly at financial institutions. This even goes back to our first conversation around year over year trends not changing that much. Why are we still seeing phishing being such a prevalent vector in the financial institution? And what we really think is it goes around technical innovation, things like automated mass-hijacking of accounts and genuine source code being pulled from real sites that fraudsters are using in their phishing sites. These things make phishing attacks more efficient and harder to stop from a genuine user standpoint. So never mind the fact that phishers are surrounding users at every communication touch-point today. It's not just about e-mail, right? It's IM, Facebook, texting, and then remember the URLs in a mobile phone are often short, making it next to impossible to spot the incorrect URL.
So even though phishing has been around for some time, it's still evolving. We can understand why about 70 percent of the survey respondents believed their exposure to fraud has increased due to evolving online threats. It's really the fact that evolution of threats, of vectors of different tools and methodologies that the bad guys are using against financial institutions, that's the most alarming, because we're not only seeing this continued evolution and sophisticating in phishing. We also see it in banking trojans. If you think about the man-in-the-browser trojan like Zeus, it's really a perfect example of a Trojan which is constantly innovating. It can fully automate the fraud process really from initial injections all the way to cash-out of an account. This means not only can Zeus hijack these accounts to take over the users' credentials, but it can also take over the users' device to create fraudulent transactions.
Now a legitimate user would not be aware that these details of their transaction have actually been changed. Maybe there's an extra zero added or a couple of extra zeros added to the amount of transfer, and it's now not being transferred to your department store bill, but to a mule account. Well, all of these will be actually invisible to the genuine user, so these evolutionary traits of what we're seeing occur in the fraud landscape is really of most concern.
FFIEC Authentication Guidance
FIELD: You mentioned earlier the FFIEC authentication guidance, and of course this was a huge theme in the questions that we asked, and the responses we got back were pretty clear - that organizations in many cases didn't understand the guidance and they certainly were not ready to be in conformance now when federal regulators are out there examining institutions. What I would like to ask - from your perspective - where do you see organizations having success addressing some of the requirements and where do you see them having some success in conforming, because I'm sure you're seeing some institutions that aren't struggling.
BLACKSHAW: That's absolutely right. I mean, we have been having conversations with our customers for a year now specifically just on the supplement, and we definitely have a large range of conversations there from "what do I need to do, I don't even understand my gaps," to "I actually think because of our security posture, we are actually in conformance now." We have been having this large range of conversations and I think organizations are having success when they take a risk-based approach to their layered security posture. That's right in the supplement.
But when they put emphasis on device identification along with anomaly detection and behavioral analysis, this will really help them to determine their users' normal patterns of behavior. From there, they can understand the level of risk associated and help determine what type of control needs to be put in place dependent on that risk. It's really important for institutions to be able to identify the activity on a customer's account that may not be normal for that specific user. In order to do this again, it's this risk-based layered security approach to looking at not only log-in, but post log-in transaction.
A basic example of this would be looking at one customer who has a frequent traveler maybe and they're a user of online banking who transfers large sums of money on a regular basis. Now if the organization sees this user transacting multiple different times from multiple different time zones, this wouldn't be a high-risk activity necessarily. But if you now see a user who logs in once a week and just checks their balance, now transferring large sums of money maybe at an incorrect time from their normal use of the application, well then something needs to be raised there.
It's really understanding the risk, which is the number-one takeaway for us and the best practice we would recommend is understanding that transaction risk, but also understanding the difference between humans and trojans. So again, this goes back to the evolving threats and understanding of trojans because there are certain types of behaviors that may appear to be coming from a real user but they're actually indicators that the session has been hijacked by a trojan or a fraudster.
So for example, a man-in-the-browser trojan can use HTML injections to introduce different fields into a user session, things that normally wouldn't be there. But with advanced analysis, this type of activity can be detected and to immediately raise a red flag that something's wrong. And now, once you sort of have this baseline understanding of what is risk and what is anomalous for your genuine user, you need to decide what to do. We tend to see two primary schools of thought here. The first is to challenge the user visibility, some sort of step-up authentication that's mentioned within the guidance that works for that user and that channel. And the second school of thought is really to delay and investigate. So some financial institutions that I have worked with really have chosen to not take a visible challenge but to go back, and then pass forth those transactions once confirmed viable. So it's all about risk thresholds.
FIELD: I'm glad you used the term "challenge" because I wanted to ask you about a couple of topics that I know are very important to RSA and one of them is challenge questions. We had some questions in the survey about challenge questions and I would like to hear from your perspective, how challenge questions are evolving and what some of the more progressive institutions might be doing now as they move toward the sophisticated out-of-wallet authentication, and not sort of the simplistic questions we saw many institutions turning to before.
BLACKSHAW: It's a really great point because for many years we have seen organizations relying on static challenge questions, as you said, to authenticate users during all types of risky activities. Now the increase of information online has really changed the effectiveness of those challenge questions. If you think back to 2005 when many organizations initially started using these static challenge questions, this was before there were 800 million Facebook users online willing to share every intimate detail of their life. These details are now being used from fraudsters to overcome those challenge questions, so what we have seen from more of a sophisticated out-of-wallet question is trying to use dynamically created questions that are based upon information that isn't necessary found on somebody's Facebook profile or LinkedIn or whatever you use.
We also have to remember that a lot of the increased availability of different types of malicious software has enabled sort of keyloggers or screen grabbers to capture these static questions and answers, allowing fraudsters to use those even if they haven't socially engineered going on to a user's LinkedIn or Facebook profile to find the answers. They may actually be able to use some of their innovative tool kits to capture the answers and questions and then use those for different account attacks across the user's portfolio.
A more secure approach to these is to use questions that still use answers that are relevant and easy for the genuine user to remember and use, but harder for the fraudster to find online and capture from a screen grabber or a key logger. We've seen compliance and regulatory mandating the use of these more sophisticated, we like to call them knowledge-based authentication that are dynamic and we really believe that these are designed to confirm users' identities through a series of questions and answers that are developed on a fly.
So again, they're not static. They come from public and commercially available data. And in addition to these questions, we think the various data and identity checks should also be performed, the access, the risk of the identity, and evaluate behaviors that raise suspicion of fraud. For an example, we have a solution here at RSA that not only uses harder to find information to create dynamic questions, but on the back-end we're doing risk assessments on that profile. Things like, have there been different profiles pulled on this user? Is this user even legitimately alive, right? Is this Social Security number even available? It's not just the fact that you can use dynamic questions to be more secure, it should be used within a solution to look at the risk.
FIELD: Another topic that I know is close to you is transaction signing. We asked a question or two about this in this survey and found that the survey respondents really needed more education in this area. It's not an option they knew a lot about. My question for you is: what do you find to be most misunderstood about transaction signing, and which types of organizations do you see that could be good role models for institutions so they could come to understand this better?
BLACKSHAW: That's a really great question. It was surprising to us that there were so many respondents who didn't have enough information on transaction signing, and then we took a step back and thought about it. Transaction signing has been in the market place pretty heavily for the past three years, but more specifically in Europe. The reason most likely is that fraud, when it occurs in Europe, there's a lot of liability that's on the end user. They have easily taken on this transaction-signing functionality from an end-user perspective and many of them demand it from their banks. They are the driver in saying, "I want to make sure my transactions are secure." What we're seeing ... is that we have to assume end points are going to be compromised, and if we're going to enable end users to transact online securely, not only do you need to be looking at the risk of that transaction, you need to put in place a control that's still going to allow a secure transaction to occur even if the end point is compromised.
So how do you do that? Well, transaction signing actually allows a user to transact with their bank even if there is a man-in-the-browser, man-in-the-trojan, or in the back end, because what transaction signing does is it takes information from the genuine user, such as account for the destination account and amount. Those two inputs are cryptographically signed with the end user's unique identifier.
On the back end, if there's a trojan sitting in-between the genuine user's browser and the server at the bank who then changes to a mule account adding a few zeros on the amount, the back-end server at the bank is actually going to recognize that those transaction details have changed on a fly, and it's going to block that transaction. What we have seen is that there has been a large deployment of these in corporate banking and again in consumer banking outside of North America, and we believe that this is a functionality that should really be looked at here in North America as well.
What we think is most misunderstood about transaction signing is that a lot of institutions feel that it may be inconvenient to the end user, however as I mentioned not only has this been adopted really broadly in different areas of the world, but that it depends on how you're going to deploy the solution. You can have a hardware device that's separate and that needs to be given to the end user, but maybe that's only used to sign certain transactions over a threshold of amount, or you can actually use a software version which is a solution that we have which can be natively embedded into the banking application.
So now you're providing a truly seamless functionality to the end user who doesn't need to carry anything in addition and it's not an effort to use. We really want to set that straight that it's not inconvenient for the end user and that we think the security provided by using transaction signing and different transaction protection solutions is really important and that it needs to be thought of really seriously by organizations here as well.