Fight Back Against Phishing - Email Security Insights from Paul Smocer of BITS
In an exclusive interview, Paul Smocer, VP of Security at BITS, discusses:
Smocer was hired in early 2008 by BITS, a division of the Financial Services Roundtable, to lead its security program. Smocer has over 30 years' experience in security and control functions, most recently focusing on technology risk management at The Bank of New York Mellon and leading information security at the former Mellon Financial. While at Bank of New York Mellon and at Mellon, Smocer was actively engaged with BITS as a member of its Vendor Management Working Group, as 2005 Chair of its Security Steering Committee, and as 2004 Chair of its Operational Risk Committee.
TOM FIELD: Hello, this is Tom Field, Editorial Director with Information Security Media Group. We are talking today about e-mail security and with us is Paul Smocer, Vice President of Security with BITS. Paul, thanks so much for joining me.
PAUL SMOCER: You're welcome Tom. Glad I could join you.
FIELD: Paul, I know that BITS and eCert have just released a paper entitled, E-mail Sender Authentication Deployment. What is the genesis of this paper and the main message in it?
SMOCER: The genesis of the paper really is in some work that BITS started doing a couple of years ago with regard to improving security in the e-mail space. In April 2007, BITS had published a paper that spoke about three protocols that it was encouraging financial organizations to adopt to enhance the authentication in particular of e-mail messages that appeared to be coming out from financial institutions but in many cases were in fact phishing e-mails or spam e-mails.
So in April of 2007 we published this paper that really called for the implementation of transport layer security as well SPF and DKIM. As we have progressed going forward I think it is safe to say there has been a broad implementation of TLS, at least opportunistic TLS. There has been an increasing implementation of in-force TLS, particularly between financial institutions, given some of the work they have done and some work that both BITS and the Financial Services Information Sharing and Analysis Center have done to encourage that.
But we were seeing a little bit of slowness in the uptake of both SPF and DKIM and there were a couple of reasons we thought that was the case. One was that both were newer protocols and both certainly involved a larger amount of work and effort to implement than TLS did. Second, the internet service provider industry had not yet really caught up with capabilities in that space. So in order to facilitate and help our members to move a little more strongly toward implementation, we thought that one of the steps we might take was a paper like we just published that is really a how-to guide to implement SPF and DKIM, the steps you need to take internally in your organization, the considerations you need to go through, and as I am sure you saw if you read the paper, a proxy project plan in the back for walking through what a project like this would look like.
The primary motivation in encouraging our members to implement these protocols is to help with the phishing problem and more generally, assuming we can get to a place where we have secure e-mail, not only help with the phishing problem but maybe even eventually be able to leverage e-mail into an actual product channel.
FIELD: Paul, you have outlined nicely the challenges that are facing financial institutions. How do you find that they are generally tackling these challenges now, in the environment before you released this paper?
SMOCER: There are a number of institutions that were attempting to do implementations themselves and in fact, as you read the paper in the acknowledgment section of the paper, many of the member companies who assisted in developing this were in fact from institutions that had gone fairly far down the implementation chain.
I think there were a few challenges that organizations more generally face. Number one is SPF and DKIM which are newer protocols so the understanding of those protocols is not as strong as it is with some other technologies. Second, if an institution in and of itself doesn't have a broad amount of resources to deal with e-mail, having someone take the time to sit down and develop a plan and develop the processes that you need to do is a little bit more of a strain on the institution. We are hoping that the paper takes the learnings of people who have been through this and the technology that is involved and makes the technology simpler and makes the learnings more available so folks don't have to reinvent the wheel as it were.
FIELD: What are some of the ways that this paper is going to help institutions to do just that?
SMOCER: We tried to make the paper a relatively easy to use how-to guide and we basically laid out the steps and the considerations that a financial institution needs to use to implement this. Honestly, I know a lot of your readers are financial institutions, but I know a lot are not as well. This paper could just as easily be used by any organization that is looking to enhance its e-mail security, so even though we have done it for our members and for financial institutions in general, we know there are other industries that are just as interested in enhancing e-mail security. It is not parochial in its nature such that only financial institutions could use it; your readers who may not be in that scenario could just as easily do it.
Again, what we tried to do was work with eCert who has a lot of experience in this space; we tried to lay it out in a fairly simple fashion. Folks who are in the e-mail space should have a pretty easy time walking through the paper and understanding what the financial institution needs to do on its end. We are certainly hoping and encouraging our members with this paper to begin to move a little faster in this space.
FIELD: You mentioned eCert Paul; I know that you collaborated on this project. What role did each of you take in developing this paper?
SMOCER: eCert was actually very, very helpful. They developed the first draft of the paper, largely on their own, which our members and staff then worked from to create the final paper. There were quite a few iterations and revisions from the beginning to the end, but I think we owe eCert a big round of thanks because they accelerated the process pretty significantly for us. In a typical project of BITS, when we get our members together and people are writing sections of a paper, it tends to take us a little bit longer to complete the whole paper. Their work in putting together the first draft based on the expertise they have was extremely helpful to us.
FIELD: So you have solved e-mail security for now. What's next for BITS?
SMOCER: I would answer that question two ways to be honest. In the e-mail security space I think there is still a group of "what's next" actions to take. Now that we have tried to lay out the steps for the financials institutions to go through, I think our focus will change in a couple of ways.
One is focusing more on working with the ISPs and the e-mail service providers to make sure that they understand the industry is now truly ready to move forward with this and to help assure that the ISPs are supportive of the implementation of these protocols as well. To that end, one of the things that we are working on is a way to develop a key repository of information if you would. There is a lot of information that gets created in terms of rule sets and whatnot when you are creating these protocols that have to then go out to the ISPs and your e-mail service providers to make sure that as they deliver mail, or as mail is delivered, the rules around the protocols are being followed.
Logically, the ISPs are concerned that if all financial institutions were doing that on a one-off basis with them it creates quite a bit of overhead for the ISP community. So one of the things that we are trying to do is create more or less a trusted repository and we are working with the FSISAC in that space. We have proposed to them that it makes sense for them, as kind of a key operating arm of the industry, to consider taking on that role. And we are working with them to see if they are willing to do it, but that is a next step in our minds.
Working with the ISPs and trying to set up this central repository are key next steps in the e-mail space. More broadly, which I think is where your question was going, we are looking at a number of different areas. You and I Tom have actually talked in the past about the authentication space; we are doing some work there, particularly focused initially on customer authentication and the financial institutions.
We are also doing some work in the area of software assurance, building to some extent off of the work that some of the other associations in the financial industry have already done or are looking to do.
Generally, we are certainly trying to collaborate in this space with a number of other institutions specifically around collaboration. We are working with a number of associations, including the American Bankers Association, the FSISAC and FSTC, looking at the question of new global top-level domains for the financial services industry and what kind of security and stability considerations ought to be in a domain that offers financial services.
Those are the three things that are keeping us hopping here in the next few months.
FIELD: Very good Paul. I look forward to talking with you down the road as you start to tackle some of these other challenges.
SMOCER: Tom, it is always a pleasure talking to you and I've enjoyed it.
FIELD: Thank you very much. This is Tom Field, Editorial Director with Information Security Media Group. We've been talking with Paul Smocer of BITS. Thank you very much.