The Most Overlooked Aspect in Credit Union Security

There is one big, scary security hole in credit unions that most IT people pass over and I’ve never heard an auditor mention: domain registration and DNS hosting. Whoa, whoa, whoa, DNS sounds technical. And it is. But domain registration is very self explanatory. You’ve seen the GoDaddy commercials (or bought domains in a drunken stupor late at night) so you know who easy it is to purchase a domain name. Generally your domain registrar handles your DNS hosting for you. DNS is like the phone book of the internet. It takes and converts it to an IP address and then sends the request off to the correct web server. DNS controls your MX records, or email records, as well as where the domain name should be directed.

Why do we have multi-factor authentication in online banking? To prevent unauthorized access, yes? What do you suppose would happen if somebody gained access to your domain registrar where your credit union’s domain was registered?

  1. Bad guy downloads all of the html of your website
  2. Bad guy posts the html of your website on a server he controls. It might not work fully, but it looks legit.
  3. Bad guy logs into GoDaddy (again, just an example) and tells to point to his server instead of your server.
  4. Members visit the site controlled by bad guy who then steals all of their online banking credentials and whatever else he feels like collecting/asking for.
  5. Oh, and while he’s at it, he’ll change where your CU’s email is pointed at and point it to his own email servers. That means he is now getting every single email sent to the credit union for every single employee.
  6. And he might do it after hours. Members will have problems logging into online banking, but won’t be able to contact anyone. Email won’t be coming in, but probably won’t get noticed. He flips the switch right after the call center closes and changes everything back before you open.

Scary stuff to think about. Talk about a security catastrophe for your credit union. So what’s a CU employee to do?

First, follow normal security guidelines in regards to password management and computer security. Keep your anti-virus up-to-date. Use traffic monitoring and/or endpoint protection to disable any traffic outbound from your CU to a known bad guy website. Never, ever, ever write down a password. Etc, etc.

VeriSign Identity Protection LogoSecondly, pick the right registrar. Cheap is rarely the best. Picking on GoDaddy again, but you log into your account on their homepage which is not protected by an SSL. That means your username and password are sent as plain-text over the internet. Fail. So far only one domain registrar,, has implemented mutli-factor authentication. And it is the cream of the crop as far as MFA goes. VeriSign’s Identity Protection, or VIP, works exactly like the RSA key fobs of yore do: an encrypted algorithm that cycles through a code every 30 seconds. VIP Program screenshotIn addition to your username and password being required to log into the site, has the ability to require your VIP credential as well. These credentials can either be a physical key fob or can be downloaded to your iPhone or Blackberry if you’d rather not carry around yet another thing on your key chain.

Currently, is the only domain registrar doing this type of multi-factor authentication. This doesn’t mean you should run out and change domain name providers, just that you need to be aware of the security risks. Some of the larger credit unions use DNS hosting companies rather than their registrar to handle DNS. Even these enterprise level services are vulnerable to comprise as Twitter can attest when their account a Dyn, a large DNS hosting company, was comprised and all of their traffic was redirected.

Credit unions are obsessed with security, but often, their obsessions are missed place. I’d be more concerned with a trojan virus getting on the network and implanting keyloggers on employee machines or this type of DNS redirection than I would with (gasp) CTR and SAR compliance. Sure, failing CTR/SAR compliance will cost you, but what will ultimately have a bigger impact on your members?

Sensitive Compartmented Information (and your money)

For those with military experience out there, you may be familiar with SCI. Actually, you probably can neither confirm nor deny your SCI or non-SCI status. Regardless, for those not in the know, SCI is the step above top secret. You’ve heard the old saying, “It is on a need to know basis, and you don’t need to know!” Unfortunately, most online transactions performed today do not follow rules anywhere close to that, even though they don’t really need to know.

Ars TechnicaEveryone in the industry is familiar with the Heartland breach, the TJ Maxx theft, and probably half-a-dozen others. Too bad retailers, both brick and mortar and online, don’t believe in SCI. Of all the players in the industry, Microsoft has recently stepped up with a program they’ve dubbed “U-Prove“. U-Prove works with a model similar to SCI, in that it only gives the information necessary to complete a transaction and nothing else. A recent Ars Technica article has offered some editorial insights:

On the other hand, there’s no reason why a storefront like, say, iTunes, needs to know your identity; it only needs to know that the money being handed over is yours to hand over.

To use a credit card on iTunes, I have to hand over so much information that Apple, if it was a bad actor, could masquerade as me. I can’t just give Apple some electronic money; instead, I have to give them my name, address, and credit card number. In practice, the real problem with me handing over so much info to iTunes isn’t that Apple might pretend to be me—with billions in the bank the company doesn’t really need to charge things to my credit card, after all—but that hackers (both external and internal) might take this stored data and use it for their own nefarious purposes.

U-Prove aims to stop organizations from being forced to collect excessive information from their customers when, in reality, it is not needed. To the contributor’s first quote, Apple doesn’t really need to know all of my info, just that the money I’m sending them is good. Microsoft has open-sourced the U-Prove framework, enabling other applications to use the protocols. U-Prove, using a combination of many cryptographic solutions, creates a one-time unique and secure key with the necessary information contained within it, which is then decoded and used by the organization requesting the transaction.

As is the case with any new technology, adoption is always going to be the hardest part. Some retailers, such as the Amazon example used the in Ars Technica article, will not welcome the U-Prove framework as it removes many key data mining aspects of their business. Amazon doesn’t really need to know your age, unless of course you are subscribing to Playboy or buying a CD with explicit lyrics, but they use that information extensively in their advertising. In much the same way, Apple has no need for your address when purchasing a song, but they can use that information to determine the best location to place their next store, geographic and contextual marketing, and potentially track down problems in their supply and distribution chain.

The U-Prove framework has the potential to be a game changer for the way business and individuals transfer information between one another, but the implementation and adoption hurdle will be a large hill to overcome. Microsoft has begun implementing U-Prove within some of their own products such as Active Directory and some of their web technologies. Even with this show of good faith, convincing other organizations to limit the amount of data they can collect from their customers, all in the sake of privacy and security, will be a challenge.

Is U-Prove the correct way to diminish some of the risk associated with breaches like Heartland and TJ Maxx by limiting the amount of data exposed on a need-to-know basis only or are the implementation challenges to great to overcome?

Credit unions need their head in the clouds

Cloud computing is the wave of the future for all things data related.  Amazon started it with EC2 and S3.  Microsoft is in it.  Salesforce is doing it too.  Credit unions are just starting to realize the benefits of virtualization and as more CU’s struggle with income generation, expense control, and capital expenditures, virtualization is going to take off.  But why use your members’ capital to acquire VMWare or Citrix servers, additional bandwidth, etc when you can “outsource” the hardware and infrastructure to providers that are much more efficient at it than the CU could ever be and do it cheaper?

Credit unions love to have control of their infrastructure and data, many IT departments love new projects and new technologies.  And they are pretty much required to.  Just look at the NCUA’s guide for doing third-party due diligence.  They don’t make it very easy to use new technology or unproven (read: new and innovative) vendors or products. Cloud computing is where we’re moving but how can credit unions make that jump while satisfying the NCUA’s security and vendor requirements?

More on OpenID

I was just reading an article in Information Week talking more about OpenID and how it has been starting to catch on and is being implemented on mainstream sites, like MySpace.  As quickly as they praise it, it rapidly turns around into how many sites enable the use of their OpenID, but they don’t accept ID’s issued by other providers because of “inherent risks”.  This sentence got my brain thinking:

“Since no OpenID provider makes public its practices around vetting and protecting identities, there’s effectively no way of assessing liability for faulty initial identification.”

Who is bound by law to verify ID’s stringently?  Oh, that’s right.  Financial institutions.  So why don’t banks and credit unions jump on board and offer OpenID?  (I’d love to see a start-up virtual credit union do this.)

One potential issue I see with this is there will still need to be a verificaiton step involved to verify that the OpenID was really issued by a bank or CU.  I could go get, issue “verified” OpenID’s that could be used to log into sites requiring stricter control over the content they are offering on their site.  So the question becomes how can you create a secure OpenID that is provided by numerous companies?  I think the answer may lay in an uber-secure TLD for banks and credit unions. Literally, have .bank or .creditunion or the like.  The registrar for the TLD would verify that the FI buying the domain is legit, using government verified documents like call reports.  This concept has been kicked around before but many it just doesn’t have any legs.

So what do you think?  Is there a need for a secure TLD for only financial institutions?  Do banks or CU’s really need to offer an OpenID service?

No, you can’t know what movies I watch!

Blockbuster and Facebook have recently come under attack for some aspects of Beacon, Facebook’s semi-new intrusive marketing tool.  Years ago, when I actually worked at Blockbuster, it was fairly well known that you couldn’t divulge what movies someone has watched.  Similar to how you have the primary member at a CU, the account holder of a Blockbuster account had to given written permission for their history to be divulge to a third party, even if that person was a spouse or a "joint" account holder.  When wives frequently called up to ask what movies they had out, if the account was under the name of the husband we couldn’t tell them.  Not to customer friendly, but it was the law. 

Movie Clique, Blockbuster’s Facebook app, lets you share your movie watching history with other Facebook users.  While this sounds cool and very web 2.0, it also appears to be illegal.  According to a law professor at the New York School of Law, the two companies should be preparing for incoming lawsuits.

So what does this mean for CU’s?  First off, that it is actually harder to share movie rental history with a spouse than it is to share banking transactions.  Personally, I feel like banking transactions are a little more private than that, yet they are not afforded the same legal protection.  With the recent advent of Mint, Wesabe, Cake, etc, our member’s information is getting spread all over the web and we to be very aware of how this info is being consumed.  It would also be a good idea to ensure your branch staff are relatively tight-lipped about the info they give out.

More open source news

If it is good enough for the Department of Defense, it should be good enough for CU’s, right?

From Colin, the DOD is hosting an open source conference this December in DC.  To quote the DoD article, they are,

"Fostering collaboration and interoperability across DoD"

Just cross out DoD and put in CU.  The credit union movement seems to be the perfect industry to grow open source projects, and not just software ones, but there seems to be quite a hurdle to getting true collaboration.  It seems to me that many CU’s would fear "interoperability", like cell phone number portability, because they could lose members to their neighboring CU.

I would like to think that if the DoD came out with a publication that says open source meets their requirements for security, CU’s would be much more comfortable in adopting those technologies.  But as Matt Dean from Trabian has said before, the hacker to contributor ratio is vitally important.  With Linux, Firefox, or Apache, there are a great number of eyes looking at the continued development of the product and hacking a linux distro would maybe get you access to a server or some data.  The ratio of hackers to contributors would be much greater in an open source core processor than in Apache or Linux because they payoff for hacking would be much greater.  They could again access to hard dollars and potential transfer money straight to an account in the Cayman islands where I do my banking.


How well are credit unions prepared for data center outages?

 Back in July, 365 Main, a major data center hosting companies such as c|net, Craigslist, e-surance, and the Oakland Raiders, lost power.  For most of the day.  And 365 Main has the time, money, and resources to make sure that (almost) never happens.  Here is the full story straight from 365 Main.  Jesse Robbins has a slightly more digestible version here at O’Reilly Radar.

 So if a major provider like 365 Main can drop clients for half the day, what protections are in place in our CU’s?  What are reasonable expectations from our members?  Do we need to stay up for 24 hours after a power outage, or just survive until the power company comes out to replace the broken transformer or power pole?  Obviously the most important thing is data loss and, for the most part, as long as the CU has the appropriate safeguards in place to protect against power surges, the servers and data should be safe from melting.  After basic data preservation then comes up time.  As a member, how would you feel if you went into a branch and the teller said that they couldn’t actually do anything on your account until tomorrow because their computer system was down?  You probably wouldn’t have online banking to check your balance and the CU would probably have to limit the amount of cash they could withdraw for members since they don’t actually know how much each member has.  So out comes the pen and paper to hand write which members took how much money.  Not an ideal situation.

Put the members’ hat on.  What would they expect?  I’d be miffed if I couldn’t get cash out, but I’d probably survive.  For a day. 



FIS Data Leaked

FIS, or Fidelity Information Services, had an employee steal confidential consumer information and sell it.  FIS has their official press release here.

What would happen if a CU employee decided that their member data was worth something and sold it?  How would or should a CU react in this instance?  FIS’ press release reads like it came from marketing, went to legal, and then back again.  Should CU’s issue press releases on their web sites, in their monthly newsletter(s), in a blog, or all of the above?  Are blogs appropriate avenues to communicate this type of sensitive information with your membership?

The .Bank Debate Part II

In my previous post, I commented on the proposed “.Bank” TLD. Since then, F-Secure has defended their proposal in their blog, addressing many of the key issues I commented about.

Here is what they had to say about users still being fooled the new addresses:

The main point of such a new TLD would not be that users would suddenly get a clue and would learn to read the web addresses correctly (although for those who do read the URLs, this would be obviously be an improvement). The main point is that it would allow the users’ software to work better. Security software and browser tool bars would essentially have a “white list” to work with.

Yes, .bank would help browsers know whether a site is legitimate or not, but users would have to look for something in their browsers.  If the EV-SSL certificate message below isn’t clear enough, what could web browsers possibly say that would be?

EV SSL Certificate

F-Secure addressed the issue of EV-SSL certificates as well:

We’re not against these new high-security web certificates. However, a secure top-level domain would still be a good idea: it would authenticate the domain as trusted by the name alone. There’s no way to know if a site has a high-security certificate without visiting it.

True, but EV-SSL certificates identify web sites while also assuring security in transactions.

What about a compromise, a variant of EV-SSL certificates just for financial institutions, a FI-EV-SSL Certificate? This wouldn’t give much additional benefit. One must prove they are a legitimate business to get an EV-SSL certificate anyway.

I’m still not convinced “.bank” is worthwhile, what do you think?