Did you hear about the credit union Web site that installedviruses on members' PCs? Or the one that supplied graphics used ina successful phishing expedition? Or the site that captured memberinformation and sent it overseas? Hearing these and other horrorstories make credit unions want to turn back their clocks to a timewhen Web sites weren't a service commodity. However, consumerstoday expect a credit union to have a Web presence, and regulatorsexpect credit unions to manage the risks inherent in their Websites. Credit unions know that they need to protect memberinformation. But since most credit unions contract a third party todesign their Web sites and another third party to host them, it'shard for most credit unions to tell where the additional risks lie.Raising the stakes still further is that Web components andfunctions can constitute "alchemy" in credit unions' minds. How thesite works and where information comes from are total mysteries. Intoday's red hot regulatory environment, credit unions need to askfundamental questions of their Web developers and hosting services- and not let these vendors off the hook until their answers passregulatory muster! The vast majority of Web developers do notgenerate their own unique scripts to create the forms, dynamicmenus, and popup windows commonly found on Web sites. They rely onthird-party software, usually found by "googling" (aka searching)the Web. That by itself isn't a bad thing. But EVERY third-partysoftware has weaknesses! COCC recently thwarted a spamming schemepoised to launch unwanted e-mails to 500,000 AOL users. The launchcode arrived on the site via a popular script used to collectinformation from Web site visitors. The developer had simplyforgotten to apply the most recent security patches. Had he doneso, the incident would have been nipped in the bud. To combat thistype of incident, your institution should have a comprehensive listof every third-party application used in the Web site'sdevelopment. Many developers fear that such a list reduces theperceived value of their service. But your credit union has a moreimportant mission: you must be able to identify those applicationsas part of your risk assessment process. The credit union alsoneeds to know whenever those applications change and who'sresponsible for the update. It's important enough that this shouldbe included in the developer's contract! In fact, third-party Webapplications are no different than any other IT system that touchesyour members. You should know each time an application is upgraded,what was done, who tested it, and how it can be backed out in caseof trouble. You should also ask if there are processes in place toenforce dual control so that no one can make changes to the sitealone. Lately, credit unions have seen offers of simplified Websites, commonly known as content management systems. These sitesenable almost anyone in the credit union to publish information tothe Web. A Web designer creates templates; the credit union enterstext, graphics and links into a Web database; then the templatesautomatically format the database information into Web pages. Yetthese new sites have a large Achilles heel: they are proprietary.This should be a giant red flag to any credit union becauseproprietary systems offer greater opportunity for error as well asgreater difficulty in tracking security breaches should they occur.If your Web site breaks and your designer is out of town, who willfix it? If you suspect malfeasance on the site, who will examinethe code to accuse or exonerate the developer? Proprietary systemsrequire highly trained, third-party resources to review them, asrequired by most regulatory agencies. Those resources typicallycost a great deal and are not readily available. Add the prospectthat the proprietary code will eventually need to be upgraded, andthe risk of extended Web site down time is sitting on yourdoorstep. Finally, there are contractual issues with contentmanagement sites. Contrary to conventional Web sites, credit unionsdon't own a content management Web site. Yes, the words belong tothe credit union, but the templates and database belong to the Website provider. Should your institution want to switch providers,those key elements of your site won't come with you. As you cansee, the credit union's Web site is a major IT application thatneeds to be looked at carefully from a number of angles. If youdon't ask the tough questions, your examiners will! Credit unionsshould apply the same IT systems approach to their Web hostingservice as well. Many of these services cater to general purposeWeb sites and therefore have little experience delivering the depthof security that credit unions need to pass a regulatory exam. Askfor your Web hosting service's SAS 70 or equivalent EDP auditdocument. This basic IT audit report separates the serious playersfrom the wannabes. But passing the audit test shouldn't completeyour scrutiny. There are no bullet proof hosting services.Combating the thieves requires diligence and procedures thatquickly bring irregularities to light. Your hosting service shouldhave those in place. Plan to dig into the host's ability to detectsuspicious activity, such as phishing attacks, and its ability torespond appropriately. Examine the host's storage methodology. Weoften find that information collected ever so securely from Websites is completely available for download. Look at the backupprocess for additional theft opportunities. Many leaks of memberinformation have started with the host's backup tapes. Who hasaccess to that information? What's their knowledge level and howgreat is their opportunity to steal the information for malicioususe? A good way to detect potential trouble is to track memberrequests. Knowing who responded to the member and when the responsewas sent can be very helpful - both from a security and servicepoint of view. The bottom line: you should scrutinize your Web sitedevelopers and Web hosting service as carefully as your accountprocessing vendor. It may be the Web, but it's really IT.