Security teams need a louder voice
Yes, I’m a few weeks late commenting on the long awaited release of the FFIEC’s updated on-line banking security guidance to US financial institutions since the last major revision back in 2005. Of course, every security analyst, blogger, vendor and pundit had to offer some perspective on what the FFIEC presented. One particularly analyst, Gartner analyst Avivah Litan, of whom I’ve communicated with in-person and blogged about before here, is critical of the guidance (here) and in general, her critiques are valid from my perspective as she has presented them. One perspective that hasn’t been extolled enough in my opinion is the extra push this guidance gives to security folks in the trenches trying to merge good security with product teams trying to push as many new features as possible on to over stressed IT delivery teams. I’ve described this typical inter-dependent set of challenges in more detail before here. Lastly, for those that didn’t see the comments on my previous post on the recent pressures on banks to secure the on-line delivery channel, I’ve captured a comment dialog between myself and Jim Woodhill, founder of security company Authentify that supports the challenges of this cross-team security prioritization effort.
Again, if you are looking for more focused commentary on what the guidance did or didn’t address well, I urge you to read Ms. Litan’s article or simply Google “2011 ffiec guidance” and you will get a number of returns before you will see a link to the actual guidance itself. But what the guidance arms the “fight the good fight” security and IT teams with is additional ammunition to be heard louder in the cacophony of voices wrangling through the typical corporate IT on-line product delivery project. So before you get caught up in the groundswell of commentary that the FFIEC didn’t go far enough or didn’t account for this risk or this vulnerability, take some comfort that the fact that the guidance was updated to come closer to reflecting the currently multi-channel, multi-threat landscape that wasn’t appreciate back in 2005.
In closing, consider the comment conversation Mr. Woodhill and I had on my previous post on this topic as more evidence that security focused individuals need additional ammunition to wedge themselves into the product set feature and function discussions with a louder voice on baking in more security.
[cut/paste word for word from the commentary]
Jim Woodhill – There is no need for new security startups. The security solutions needed to beat the current-generation commercial-account online banking funds transfer fraud attacks are as much as 12 years old. Taking just two of the security solution layers recommended in most-recently-leaked draft of the FFIEC’s long-awaited 2011, totally out-of-band transaction confirmation and transaction reasonableness analytics, one vendor of the first, Authentify, Inc., was founded in 1998 and one vendor of the second, Guardian Analytics, was founded in 2005. Each has something like a dozen competitors by now. America’s cyber-security problem is one of adoption of long-proven solutions–no innovation required. Just ask Gartner’s Avivah Litan, from whose blog post on the wrongly-decided PATCO Construction vs. People’s United Bank case up in Maine linked to this entry (from a comment you posted to her blog post)–malware-based attacks are a long-beaten problem. (DISCLOSURE: I founded Authentify.)
jfbauer – Jim, You bring up a great points in your comment. I should have been more articulate in my closing comments about a potential influx of new technology aimed at trying to position a product that balances stronger security with minimal impact to the on-line customer experience (if such an appraoch exists). Being a veteran of the last round of FFIEC on-line guidance issuance in 2005 from the financial services (FI) in-house security side, the FI product teams were struggling with just how much change/impact to the on-line experience would customers tolerate. The perception that security is the inverse of convenience was prevalent. The bank that implemented something as significant as out-of-band transaction authentication/authorization where previously not implemented was concerned uneducated/unappreciative customers would revolt and take their banking business to a perceived more “convenient” bank. Plus, the sheer marketing hype and security punditry at the time that fraud was rampant and banks were doomed unless they implemented some crazy, half baked new security “thang” didn’t help. Much repressed in-house security staff jumped on the hype bandwagon for it gave them a seat at the table rather than being pushed to the background. Add in traditional bank IT/security budgeting cycles suggesting an unfunded mandate competing with product road maps and in-flight multi-year product project investments and the pragmatic need for real security enhancement got muted with all this noise. Thus, the device based authentication trend codified by PassMark and Bank of America seemed to be the safe play for FIs, the middle ground for executive decision making. Device based authentication suggested: meet the letter of the guidance, minimize the customer experience impact, increase the security toolbox in case this on-line fraud stuff accelerates and contain unfunded mandate expenditure all in one approach. I am not saying this was massively strategic thinking on the part of FIs, but given all the noise and emotion surrounding the 2005 FFIEC guidance, it seemed the risk adverse play for banks (given ACH fraud was mired in Reg Z, who has to pay for fraud losses which is still being settled in the courts). I had the opportunity to work directly with security technology copies at the time, such as the Arcot and PassMark technical folk but more so with the Bharosa team of sharp folks assembled by Jon Fisher and Thomas Varghese that provided new security technologies involving rules/risk engines and device based forensics with built in integration for out-of-band auth/az services (such as Authentify’s offerings). Hopefully the organizations that were more strategic and invested in these more comprehensive security products will be able to leverage that investment and finally extend into the full transaction out-of-band security space. So maybe one of the current challenges is: Does today’s on-line consumer appreciate the security value of out-of-band transactional auth/az and look for it as a market differentiator in bank product selection/use rather than resist it as onerous/intrusive? Jim, thanks for stopping by and taking the time to share your thoughts. (DISCLAIMER: IF my current employer has a relationship with Authentify I am unaware and I am not actively pursuing a relationship with Authentify on behalf of my employer.)
Jim Woodhill – Thanks for taking the time to write such a long and thoughtful response to my post. Even greater thanks for your being one of the few people in your generation who writes clearly without the reading “speed bumps” of errors in English usage! Information security for financial services needs a “terminology transplant”. Strong authentication (e.g., RSA token cards before RSA let hackers steal all their “seeds” <sigh>) was the the focus in 2005 because the assumption was that if the online banking server could be certain who logged on, then all transactions done in the session set up at logon time could be trusted. Session hijacking via man-in-the-browser malware has put paid to that happy simplification. Now, if a bank is serious about protecting its depositors’ funds, it will follow the “Krebs Rule” (after the central reporter on the commercial-account online banking funds transfer fraud beat, Brian Krebs of http://www.krebsonsecurity.com/) and employ security solutions that work even if the online banking user’s PC is totally controlled by cyber-criminals. What is need is for our industry to add “transaction confirmation” to its conversation about online security as a necessary backup to “user authentication. Transaction confirmation entails communicating the substance of security-critical online requests to the end user by some means independent of the technology with which the transaction was initiated (because it has to assume that the PC/its browser has been compromised) and then accepting his confirmation of that transaction through that same out-of-band means. Of course, transaction confirmation requires a high confidence in the identity of the person doing the confirmation, but there is more to it than that. > The perception that security is the inverse of convenience > was prevalent. Security is usually antithetical to usability. For example, I find it tremendously convenient to have some of my residences in locations where I never have to lock my door. So the typical question is how much inconvenience to the end users, and also how much cost to the service providers is justified to stop how large a threat? > The bank that implemented something as significant > as out-of-band transaction authentication/authorization > where previously not implemented was concerned > uneducated/unappreciative customers would revolt > and take their banking business to a perceived more > “convenient” bank. This is the great concern of your typical community banker, at least among those who have even *heard* of cyber-attacks against banking customer accounts. However, security measures can *enhance* customer satisfaction, as Jim Van Dyke, CEO of Javelin Research presented at the September 22-24, 2010 meeting of the Online Trust and Cybersecurity Forum. According to Javelin’s research, financial services customers prefer to be “touched” out-of-band by their financial services institution occasionally rather than never hearing from it. An example is a phone call to check on the validity of credit card charges. Such “touches” give the customers comfort that their F.I. is on top of things, as long as they are not so frequent as to impair the usability of the service. Authentify’s real-world experience shows that Javelin is right about totally out-of-band transaction confirmation in online banking and the conventional wisdom in the financial services industry is wrong. Of course, this would not be the case if the end user had to take a phone call for every payment he initiated, and taking a voice call just to log on would be beyond the pale. Fortunately, only the addition of a new payee (or employee) and certain very rare account-control transactions (e.g., change of the address on the account) need be “Authentified” (to coin a term <grin>) to prevent theft. The cyber-crooks cannot make away with a company’s money by sending it to a valid, established payee. The must add new ones–domestic money mules or just accounts they control overseas. For the typical American small- and medium-sized enterprise, the addition of a new payee is a “rare” transaction. For example, in the infamous PlainsCapital Bank vs. Hillary Machinery, Inc. case, Hillary did fewer than one such transaction a *month* during the life of its banking relationship with PlainsCapital. One of the central points in making the trade-off between the dollar cost to the service provider plus the hassle factor for the users vs. the cost of the attacks is that this is a decision about how much *crime* should be allowed, and it is a maxim of public policy that “decisions about crime are always and everywhere political decisions.” This is especially true for a crime like commercial-account online banking funds transfer fraud, where the proceeds are flowing to foreign organized criminal gangs, if not outright enemies of the United States. Thus, only the elected representatives of the people can legitimately decide what should be done. Hence, Avivah’s recruiting me to get this issue before the Congress. (Anyone who has followed her writings on this issue will know what she would like the Congress to do!)
jfbauer – Jim, thanks for the kind words on the effort I’ve put into the level of professionalism in my blog. I appreciate knowing readers find more traditional/formal language enjoyable. “Information security for financial services needs a *terminology transplant*.” I couldn’t agree more with your statement. Upon reading your response, I was wondering if one of the things the FFIEC, BITS, ABA, FDIC, OCC, NIST or other universally perceived as authoritative in the industry organization could benefit all involved by establishing a common vernacular that business, product, security, technology and customers could all use to have healthy discussions about on-line fraud. I recall the FFIEC issuing a follow-up glossary-like clarification document but for some reason it didn’t resonate well since I can’t even recall any details other than it didn’t become helpful in the ensuing regulatory compliance morass that was post Q3 2005. Without clear terminology, I believe one of the challenges is the preponderance of terminology thrown around in mixed stakeholder conversations. Security folks tend to throw out obscure domain terms like “cross-site forgery” as if everyone knows the exploit and its impacts. Or worse, in an attempt to confuse others or achieve a level of arrogance that creates barriers to continuing a healthy conversation. Security professionals do themselves a disservice in the enterprise when they conduct themselves in this way. This approach leads to their further frustration when the rest of the organization doesn’t perceive them as open and credible. I aways found significant success in be open to be challenged and being open to having real, fact based not fear based discussions to arrive at more understood and appreciated security solutions. With well agreed upon terms, Bank product teams could help educate and raise the level of awareness in their customer base thus calming their own fears that they will be challenged for creating a perceived negative user experience surrounding security features which leads to your comment: “ security measures can *enhance* customer satisfaction”. I do recall the FI I was working at on FFIEC compliance fretting over changing the look/feel of the login process. The FI was adding some “user personalization” changes to match what BofA was doing when they implemented PassMark. Yes, “what is BofA doing? (consumer) or what is Wells doing? (corporate/TM)” was a common theme at this institution among product teams. The fretting reached a high enough level that they felt they needed to preview the proposed changes with a customers in a focus group setting. They went to decent length to explain the changes, what the security benefits were and were not (helped with avoiding being phished but didn’t prevent it, etc.) Much to their surprise, and exactly what you described, once the customers were informed of the enhanced security of the changes, they were completely on board. In regards to your position that “Fortunately, only the addition of a new payee (or employee) and certain very rare account-control transactions (e.g., change of the address on the account) need be “Authentified” (to coin a term <grin>) to prevent theft.” , do you/Authentify have any research/published material to help support this? There is a competing approach that suggests that analyzing the transactions themselves for fraudulent or unusual payment patterns/characteristics coupled with out-of-band confirmation only inconveniences the user at the extreme minimum yet still stop fraud compared to more frequently as payees and payee details change. Of course, this based on the supposition that on-line customers would make odd payments less frequently than add/change payee details and (big and) the FI would have the level of sophistication to determine, quickly, that a particular transaction is abnormal. I just recently ran across Avivah’s articles. I’ll need to spend some time reading her past posts to better understand her position on these topics. I doubt I can, but if there is anyway I can assist with your/Avivah’s efforts to educate congress on the real security needs I will make myself available. Lastly, is Authentify participating in the Gartner Security and Risk Management Summit 2011 (http://www.gartner.com/technology/summits/na/security/)? I would enjoy participating in any Authentify sponsored presentations/events as well as talking with any Authentify individuals at the conference.
authentication, delivery teams, FFIEC, FFIEC guidance, fraud, fraudster, guidance, IT, IT teams, key logging, man-in-the-middle, Ocean Bank, on-line, Patco, Peoples United Bank, product, product teams, project teams, security
Articles RSS 2.0 Feed
Follow Midwest IT Survival on Twitter