FYI - IT leads recovery after regional power failure - Diesel generators at brokerage, bank and clearinghouse data centers around Manhattan and New Jersey kicked in, and IT departments said that they were far better prepared for what most called a simple power outage than they were on Sept. 11, 2001.  http://www.computerworld.com/printthis/2003/0,4814,84079,00.html 

FYI - Federal banking regulators say scam artists are impersonating banks around the country and committing both ID theft and wire fraud.  http://www.msnbc.com/news/952432.asp?cp1=1 

FYI - Citibank on Monday warned customers not to fall for an e-mail scam that threatened to shut down their checking accounts if they failed to provide their Social Security numbers.  http://news.com.com/2100-1017_3-5065394.html?tag=fd_top 

FYI - Scandinavia's largest bank, Nordea, has become the biggest European victim of the MSBlast worm.   The bank was forced to close 80 branches across Finland after the infection found its way into servers in all 440 of the bank's offices.  http://www.silicon.com/news/500013/1/5618.html 

FYI - Worm's spread shows holes in patch system - This week's MSBlast outbreak is raising old questions about the effectiveness of software patches that are intended to secure computers.  http://news.com.com/2102-1002_3-5062832.html?tag=ni_print 

FYI - New technology will eliminate return of canceled checks - A major banking change in the works will cut the amount of time it takes checks to clear, improve Internet banking services and probably phase out the returning of canceled checks to customers.  http://www.buffalonews.com/editorial/20030816/1004011.asp 

Return to the top of the newsletter

INTERNET COMPLIANCE - We continue our review of the FFIEC interagency statement on "Weblinking: Identifying Risks and Risk Management Techniques." 

B. RISK MANAGEMENT TECHNIQUES

Implementing Weblinking Relationships

The strategy that financial institutions choose when implementing weblinking relationships should address ways to avoid customer confusion regarding linked third-party products and services. This includes disclaimers and disclosures to limit customer confusion and a customer service plan to address confusion when it occurs.

Disclaimers and Disclosures

Financial institutions should use clear and conspicuous webpage disclosures to explain their limited role and responsibility with respect to products and services offered through linked third-party websites. The level of detail of the disclosure and its prominence should be appropriate to the harm that may ensue from customer confusion inherent in a particular link. The institution might post a disclosure stating it does not provide, and is not responsible for, the product, service, or overall website content available at a third-party site. It might also advise the customer that its privacy polices do not apply to linked websites and that a viewer should consult the privacy disclosures on that site for further information. The conspicuous display of the disclosure, including its placement on the appropriate webpage, by effective use of size, color, and graphic treatment, will help ensure that the information is noticeable to customers. For example, if a financial institution places an otherwise conspicuous disclosure at the bottom of its webpage (requiring a customer to scroll down to read it), prominent visual cues that emphasize the information's importance should point the viewer to the disclosure.

In addition, the technology used to provide disclosures is important. While many institutions may simply place a disclaimer notice on applicable webpages, some institutions use "pop-ups," or intermediate webpages called "speedbumps," to notify customers they are leaving the institution's website. For the reasons described below, financial institutions should use speedbumps rather than pop-ups if they choose to use this type of technology to deliver their online disclaimers.

A "pop up" is a screen generated by mobile code, for example Java or Active X, when the customer clicks on a particular hyperlink. Mobile code is used to send small programs to the user's browser. Frequently, those programs cause unsolicited messages to appear automatically on a user's screen. At times, the programs may be malicious, enabling harmful viruses or allowing unauthorized access to a user's personal information. Consequently, customers may reconfigure their browsers or install software to block disclosures delivered via mobile codes.

In contrast, an intermediate webpage, or "speedbump," alerts the customer to the transition to the third-party website. Like a pop-up, a speedbump is activated when the customer clicks on a particular weblink. However, use of a speedbump avoids the problems of pop-up technology, because the speedbump is not generated externally using mobile code, but is created within the institution's operating system, and cannot be disabled by the customer.

Return to the top of the newsletter

INFORMATION SYSTEMS SECURITY - We continue our series on the FFIEC interagency Information Security Booklet.  

SECURITY CONTROLS - IMPLEMENTATION

LOGICAL AND ADMINISTRATIVE ACCESS CONTROL 

AUTHENTICATION - Token Systems (1 of 2)

Token systems typically authenticate the token and assume that the user who was issued the token is the one requesting access. One example is a token that generates dynamic passwords every X seconds. When prompted for a password, the user enters the password generated by the token. The token’s password - generating system is identical and synchronized to that in the system, allowing the system to recognize the password as valid. The strength of this system of authentication rests in the frequent changing of the password and the inability of an attacker to guess the seed and password at any point in time.

Another example of a token system uses a challenge/response mechanism. In this case, the user identifies him/herself to the system, and the system returns a code to enter into the password - generating token. The token and the system use identical logic and initial starting points to separately calculate a new password. The user enters that password into the system. If the system’s calculated password matches that entered by the user, the user is authenticated. The strengths of this system are the frequency of password change and the difficulty in guessing the challenge, seed, and password.

Other token methods involve multi - factor authentication, or the use of more than one authentication method. For instance, an ATM card is a token. The magnetic strip on the back of the card contains a code that is recognized in the authentication process. However, the user is not authenticated until he or she also provides a PIN, or shared secret. This method is two - factor, using both something the user has and something the user knows. Two - factor authentication is generally stronger than single - factor authentication. This method can allow the institution to authenticate the user as well as the token.

Return to the top of the newsletter

INFORMATION SECURITY QUESTION:

B. NETWORK SECURITY

7. Determine whether network users are authenticated, and that the type and nature of the authentication (user and machine) is supported by the risk assessment.  Access should only be provided where specific authorization occurs.

Return to the top of the newsletter

INTERNET PRIVACY - We continue our series listing the regulatory-privacy examination questions.  When you answer the question each week, you will help ensure compliance with the privacy regulations.

Initial Privacy Notice

5)  When the subsequent delivery of a privacy notice is permitted, does the institution provide notice after establishing a customer relationship within a reasonable time? [§4(e)]

Return to the top of the newsletter

INTERNET AUDITING SERVICES - We offer independent Internet auditing regarding web sites compliance and penetration-vulnerability  testing.  Visit http://www.bankwebsiteaudits.com for more information about web site audits.  For information regarding penetration-vulnerability testing visit http://www.internetbankingaudits.com/ or email Kinney Williams at examiner@yennik.com.  We have clients in 38 states and more than 40 years banking and bank examining experience.