Did you hear about the credit union Web site that installed viruses on members’ PCs? Or the one that supplied graphics used in a successful phishing expedition? Or the site that captured member information and sent it overseas? Hearing these and other horror stories make credit unions want to turn back their clocks to a time when Web sites weren’t a service commodity. However, consumers today expect a credit union to have a Web presence, and regulators expect credit unions to manage the risks inherent in their Web sites. Credit unions know that they need to protect member information. But since most credit unions contract a third party to design their Web sites and another third party to host them, it’s hard for most credit unions to tell where the additional risks lie. Raising the stakes still further is that Web components and functions can constitute “alchemy” in credit unions’ minds. How the site works and where information comes from are total mysteries. In today’s red hot regulatory environment, credit unions need to ask fundamental questions of their Web developers and hosting services – and not let these vendors off the hook until their answers pass regulatory muster! The vast majority of Web developers do not generate their own unique scripts to create the forms, dynamic menus, and popup windows commonly found on Web sites. They rely on third-party software, usually found by “googling” (aka searching) the Web. That by itself isn’t a bad thing. But EVERY third-party software has weaknesses! COCC recently thwarted a spamming scheme poised to launch unwanted e-mails to 500,000 AOL users. The launch code arrived on the site via a popular script used to collect information from Web site visitors. The developer had simply forgotten to apply the most recent security patches. Had he done so, the incident would have been nipped in the bud. To combat this type of incident, your institution should have a comprehensive list of every third-party application used in the Web site’s development. Many developers fear that such a list reduces the perceived value of their service. But your credit union has a more important mission: you must be able to identify those applications as part of your risk assessment process. The credit union also needs to know whenever those applications change and who’s responsible for the update. It’s important enough that this should be included in the developer’s contract! In fact, third-party Web applications are no different than any other IT system that touches your members. You should know each time an application is upgraded, what was done, who tested it, and how it can be backed out in case of trouble. You should also ask if there are processes in place to enforce dual control so that no one can make changes to the site alone. Lately, credit unions have seen offers of simplified Web sites, commonly known as content management systems. These sites enable almost anyone in the credit union to publish information to the Web. A Web designer creates templates; the credit union enters text, graphics and links into a Web database; then the templates automatically format the database information into Web pages. Yet these new sites have a large Achilles heel: they are proprietary. This should be a giant red flag to any credit union because proprietary systems offer greater opportunity for error as well as greater difficulty in tracking security breaches should they occur. If your Web site breaks and your designer is out of town, who will fix it? If you suspect malfeasance on the site, who will examine the code to accuse or exonerate the developer? Proprietary systems require highly trained, third-party resources to review them, as required by most regulatory agencies. Those resources typically cost a great deal and are not readily available. Add the prospect that the proprietary code will eventually need to be upgraded, and the risk of extended Web site down time is sitting on your doorstep. Finally, there are contractual issues with content management sites. Contrary to conventional Web sites, credit unions don’t own a content management Web site. Yes, the words belong to the credit union, but the templates and database belong to the Web site provider. Should your institution want to switch providers, those key elements of your site won’t come with you. As you can see, the credit union’s Web site is a major IT application that needs to be looked at carefully from a number of angles. If you don’t ask the tough questions, your examiners will! Credit unions should apply the same IT systems approach to their Web hosting service as well. Many of these services cater to general purpose Web sites and therefore have little experience delivering the depth of security that credit unions need to pass a regulatory exam. Ask for your Web hosting service’s SAS 70 or equivalent EDP audit document. This basic IT audit report separates the serious players from the wannabes. But passing the audit test shouldn’t complete your scrutiny. There are no bullet proof hosting services. Combating the thieves requires diligence and procedures that quickly bring irregularities to light. Your hosting service should have those in place. Plan to dig into the host’s ability to detect suspicious activity, such as phishing attacks, and its ability to respond appropriately. Examine the host’s storage methodology. We often find that information collected ever so securely from Web sites is completely available for download. Look at the backup process for additional theft opportunities. Many leaks of member information have started with the host’s backup tapes. Who has access to that information? What’s their knowledge level and how great is their opportunity to steal the information for malicious use? A good way to detect potential trouble is to track member requests. Knowing who responded to the member and when the response was sent can be very helpful – both from a security and service point of view. The bottom line: you should scrutinize your Web site developers and Web hosting service as carefully as your account processing vendor. It may be the Web, but it’s really IT.