Safety Nets For The 'Net
The Internet brings new opportunities - almost beyond imagination. But with it come risks. In fact it is the very structure of the Internet, global and flexible, that opens the possibilities and also introduces the risks. To provide banks guidance on Internet risk and how to manage it, the FDIC released a paper on the topic in mid-December, 1997. The paper provides information and explanations of risk and advice on how to manage the risk.
FDIC advises that Internet security must be addressed as part of the bank's risk management program. The bank has responsibility for this not only for its own activities, but also for outsourced services. As with Year 2000 issues, the bank should never simply take the vendor's word but should always take steps to verify the security.
Five areas of concern
The FDIC identifies five areas of risk that banks should address. First, data privacy and confidentiality. Although the sheer volume of transmissions on the Internet make it unlikely that a specific transmission will be monitored, banks must deal with the reality that they cannot have any transmissions monitored. Otherwise, privacy, and safety and soundness are threatened. The paper warns that there are "sniffer" programs that can be set up to look for and collect certain types of data.
Moreover, the concern extends beyond actual transmission on the Internet. Security concerns include data storage systems, such as network drives, that can be accessed through the Internet.
Second, data integrity. In theory, a skilled hacker can interfere with and alter a data transmission to or from a bank. Another way to undermine data integrity would be to invade the bank's data storage system. To prevent these actions, a variety of security measures should be taken.
Third, authentication. It is important for the bank and the bank's customer to be able to verify identify to verify that the transaction is legitimate. FDIC warns of "ID spoofing", a process by which one computer poses as another, legitimate, computer. Similarly, identity can be fabricated through spoofing. Authentication controls can minimize this risk by ensuring that the bank has an adequate method of making certain who it deals with over the 'Net.
Fourth, non-repudiation. This involves proof of origin or delivery, a means of validating that the transaction in fact happened and is enforceable. This security issue depends on preventing users from repudiating or denying an electronic banking transaction.
And finally, access control or system design. Each connection between internal systems and the Internet is a potential access point into the bank's internal operating system. Thus, the risk management program should encompass all of the connecting points within the bank's systems, both internal and external. The security system should have firewalls to protect each area of information or system.
FDIC recommends that banks look into using certain types of programs such as security scanning products, logical access controls, managing security flaws and bugs, and using virus detection programs. The security system should consider using encryption, secret key systems, digital signatures, certificate authorities and digital certificates.
Security scanning programs run automated security scans. These can target Web servers, internal networks, and firewalls the bank has established. The programs identify weaknesses in these security systems that may be vulnerable or actually breached.
Logical access controls are access codes, such as user IDs or passwords. Access codes are designed to allow only authorized persons to access the system. There are, however, systems that are designed to fool the protection system into identifying the password as valid. The existence of these techniques, called "spoofing," make it important that there is regular and careful scrutiny of the password or ID system.
Security flaws and bugs are essentially weak or vulnerable areas in software or hardware. Usually these tend to be most common in new products. One solution is to wait until a product has been in use for a period of time before purchasing and using it for bank purposes. (Let someone else's security be breached!) Also, keep in regular contact with the software vendor and other users to find out about any security problems as soon as they arise. When it comes to computer security, the sooner you know about a problem, the better you can protect the bank.
Viruses may be the biggest threat because they are common, and may download automatically. Sometimes, viruses can come on the supposedly clean discs you purchase. (It has happened to this editor!) Viruses can affect any aspect of your software, including data, communications, and - perhaps worst of all - your security programs. To minimize this problem, the bank should actively use an anti-virus program and be sure that the program is kept current as new viruses are invented.
The specific types of programs and techniques the bank should use will depend on the structure of the bank's operating systems and data storage. The risk management program should identify those elements, the weak points for each system or system connector, and identify methods that can be effective in minimizing risk. Since a basic step in assessing Year 2000 compliance involves a complete inventory of anything that is computerized and every system that talks to or interacts with other systems, you may find that the groundwork is already laid for risk management.
- Read the FDIC paper. Think about how the risks identified apply to your bank.
- Share the paper with operations and security staff. Make sure they are aware of the issues and the resources.
- Also share the paper with bank management.
- Schedule the topic for discussion with your Year 2000 task force. That group probably has all the key staff for security issues.
- If you are using an outside vendor for 'Net or electronic banking activities, review the contracts for liability provisions and the procedures for adequate security.
- Leave the technical work to the techies. Just make sure it does the job.
- Be sure that someone (preferably your bank's techie) participates in software user groups to learn about possible problems.
Copyright © 1998 Compliance Action. Originally appeared in Compliance Action, Vol. 3, No. 1, 1/98
First published on 01/01/1998