Imagine the bank president walking through your door, telling you a former employee sold the bank's client list to a competitor, your bank has no legal recourse, and it's your fault because you did not write an information security policy to cover the situation.
It doesn't matter that information security was only one of many duties outlined in your job description. It doesn't matter that information security is an extremely complex problem. It doesn't matter that information security is not your area of expertise. What does matter is you didn't get the job done - and now you don't have a job.
Such scenarios are becoming more frequent as information security becomes more complex - not only in the financial services industry, but also in the corporate and government world. For instance, John Deutch, former director of the CIA, was recently stripped of his security clearances after it was discovered he had taken classified information home and entered it into his personal computer. This is the same computer Deutch used to surf the Internet, violating CIA regulations and posing a threat to the nation's security.
If your company or firm is on-line and otherwise computer-oriented, there's a distinct possibility that sensitive information is at risk. And it's not just businesses that are concerned about the loss of information privacy. Three out of four people in a survey reported recently on CNN said they were worried about privacy invasion because of unauthorized dissemination of personal information.
What it boils down to is that any organization with more than 50 workers should give serious consideration to writing information security policies that cover most every situation expected to occur in a normal business - from employee termination to improper use of computers on the job. Virtually every organization - but especially financial service companies - needs well-constructed and clearly articulated policies to protect information against a variety of risks including industrial espionage, sabotage, fraud and embezzlement, errors and omissions, and system unavailability.
The Dreaded Hacker
Consider this example. Could it have happened at your bank?
Late one Monday night, the senior system administrator supporting the intranet for a large regional bank watched as a hacker took full control of all 200+ systems and began roaming at will, collecting passwords and perusing data. Unfortunately, the system administrator had received no instructions on how to respond, so he did little more than watch. Though the bank had written policies and procedures for most other situations, there were no formal incident-response guidelines.
Because he had no specific instructions, the system administrator spent three days trying to identify the hacker before contacting the bank's security team. The security team was unable to identify the hacker, though there was internal finger-pointing and suspicion was cast on several employees. Finally, an information security consultant was called in, but it was too late to pinpoint who broke into the system, primarily because systems administrators had not been instructed via policies to keep adequate logs.
How did this happen? The senior system administrator configured the software server so that it was trusted by the other systems. Consequently, all systems on the network were granted remote root access to the software service without first requiring a password (a web-of-trust among systems). Several hundred systems trusted the software server.
This arrangement makes it easy to distribute new software, perform maintenance, and sign on, but it can be risky - especially when vulnerabilities associated with supporting trust are not clearly understood. If a system must be configured as a trusted server, the trusted server absolutely must be secured with an extended user-authentication mechanism such as Kerberos (an encryption process). If a trusted server is not adequately secured, any hacker who breaks into the trusted server can get root access - with no password required - to every system that trusts the server.
Policies provide a proactive internal mechanism that a bank can use to prevent hundreds, maybe thousands, of potential security problems every year. For example, what would happen in a financial institution where, instead of concentrating on work, a clerk spent a lot of time surfing the Internet? If there were no policy specifying what constituted excessive personal use, management would have no means to discipline the employee.
Or what about another actual incident, in which a company received a virus warning that turned out to be a hoax? Thinking they were doing others a favor, 10% of the staff broadcast what they thought was a legitimate warning to everyone they knew. Because there was no policy defining how to handle these warnings, they flooded the company's internal networks with e-mail and wasted a great deal of technical-staff time.
Breaches in security not only create internal turmoil, sometimes they create a public relations nightmare. For example, what would happen if a financial institution had no policy about encrypting private financial data, and a computer disk containing such data were stolen?
This actually happened to a West Coast manufacturing company with 20,000 employees, but it could just as easily happen in a bank. Newspaper accounts of the theft raised the possibility that the stolen information could be used for identity theft, including fraudulent application for credit cards. The breach resulted in a massive notification process, including recommendations that individuals change their bank account numbers.
Management in many organizations has yet to appreciate information security is both a management and a technical problem. Management personnel need to better understand that they must provide technical staff with instructions in the form of information security policies. Such policies can be the basis for a variety of other written material on subjects such as network security architectures and employee awareness.
To accelerate your bank's progress in information security, make sure you have comprehensive policies and keep them up-to-date. Mr. Wodd is the president of Baseline Software Inc. of Sausalito, Calif., and the author of "Information Security Policies Made Easy."