USA East: Database Security Makes Good Business

As the shift to client/server and distributed computing environments continues to gain steam, so too does the burden of managing and protecting the volumes of data stored within the network. For database administrators, enterprise-wide security issues are becoming more complex as scores of new users gain access to once isolated databases. Throw in the explosive growth of the Internet and the proliferation of corporate intranets, and it becomes clear that the threat of database intrusions has multiplied greatly in recent years.

While most reported "horror stories" of data security breaches focus on shadow-clad hackers breaking into systems during pre-dawn hours, the stronger threat of intrusion may lie within an organization. Consider that your corporate databases contain everything from sensitive financial, payroll and hiring information to strategic planning and customer purchasing profiles. Any company can have disgruntled or snoopy employees, perhaps with plans to cause trouble or leave. For this reason, the need to effectively limit access and verify that protective security measures are working as planned is critical.

Many information technology managers feel secure with top-notch firewall systems in place. Many data security experts warn, however, that no one data-security tool will adequately guard against the breadth of threats that exists today.

"Limiting access, implementing authentication policies and monitoring and tracking user activity are all critical pieces of a comprehensive data security strategy," explains Stephen Lilly, president of BrainTree Security Software, a database security software vendor in Norwell, Mass. "Installing a firewall and relying on it alone to handle your security needs is a dangerous practice."

For these reasons, database vendors such as Oracle have worked to improve data security features. The company uses highly secure OLAP and SQL3 database standards. Additional firewall, authentication and auditing tools are offered through a host of Oracle vendor partners. "Security can be a whole separate industry. There are smart cards and authentication. Or you can use a third-party fingerprint-secure device to authen- ticate your users, and Oracle supports that," says Neeracha Tayakoo- Navudh, Oracle's senior manager for server marketing.

Beefing Up Password Security

One Oracle user that has turned to third-party security solutions to assure database integrity is American National Bank and Trust Company of Chicago. The regional bank, with more than $8 billion in assets, has its corporate headquarters in Chicago and branch offices throughout the greater Chicago metropolitan area. Jim Newman, American National's assistant vice president and manager of database services, says the organization's need for increased security was based on several factors, including two major areas of concern. The first is common to many business organizations: the protection of data against accidental disclosure, destruction or inappropriate updates from employees. The second is the requirement by the Federal Financial Institutions Examination Council (FFIEC) of the Federal Reserve Bank that national banks maintain proper data security measures for all computerized processing systems, including all financial data transactions and records.

"In late 1995 we started looking for something to address our security needs when we started to implement Oracle throughout our organization," Newman says. "We started with our Netware Server and then later on our first Oracle UNIX server. At the time, we only had a single instance of Oracle running with a very limited user audience, but as we started to broaden the number of users who would have access to that data we knew it was time to address database security."

With plans to grow the client/server network from one Oracle instance to four, Newman and his staff decided to address the problem of the increasing number of users who would need access to the multiple instances. In addition, users had to be able to synchronize their passwords across each of the multiple instances. Not surprisingly, secure password and authentication procedures are often cited by IT professionals as major flaws in data security levels. In a recent survey reported by InformationWeek, more than 80 percent of respondents claimed that "users don't change passwords frequently enough." Other concerns were that user access to files is too broad, that passwords are easily guessed or too short, and that passwords often are not required at all.

American National Bank realized that today's client/server database applications users rarely log into the host operating system. Instead, they log directly into the database, specifying a username and password given to them by the database administrator. Most database systems today do not provide the level of authentication security administrators are familiar with at the host operating system level. Databases have traditionally relied upon the operating system to authenticate the users: if users could log into the operating system, then they must be validly authenticated, so why bother checking another password? Database administrators realize that this method is no longer valid, since client/server users seldom log directly into the operating system. The database must now take on the role of authenticating users, who could be anywhere on the wide expanse of today's corporate networks.

While most databases seem to do an acceptable job of encrypting and verifying users' passwords, few provide any functionality when it comes to setting secure passwords. For this reason American National chose the SQL<>SECURE Password Manager and Audit Manager products from BrainTree Security Software. "Our primary concern was to keep our security synchronized across the multiple Oracle instances. We also needed a way to provide an external interface that would be able to adapt and provide our centralized help desk personnel the ability to do some user setup and administration of user passwords," Newman says. "We also liked the fact we could set security parameters and synchronize them with those on our mainframe applications."

The American National Bank network consists of a Sun Sparc 1000 E server with Sun Solaris 2.4 and four instances of Oracle 7.2. The company plans to add two Sun 3000 E servers with a total of eight Oracle 7.2 or 7.3 instances within six months. End-user applications include Microsoft Access for ad-hoc querying against the database (with plans to implement Business Objects 4.0 within three to six months). A sales force automation program called BankPRO is used by calling officers to track information on customers and prospects of the bank. PCs on the network range from 1200 to 1500 users, with more than 500 users defined to Oracle and the SQL<>SECURE Password Manager.

Some of the security parameters set by American National Bank require users to reset passwords every 90 days. Standards are also set for minimum and maximum password length, and break-in threshold levels were set which limit the number of invalid log-on attempts before a user ID is automatically disabled. Dormant or unused accounts are set to disable if inactive for a specified number of days, or if the account has never been used for a period of days after it was created.

The bulk of American National Bank's transactions are still processed on the mainframe system, with new decision-support applications running on Oracle. Some selected, low-volume transaction processing applications are being downloaded from the mainframe to Oracle. The system allows data coming from the mainframe system to be processed during the day through Windows applications. Then changes that have been entered during the day are passed back to the mainframe application or host overnight.

Newman says making a successful transition from the mainframe environment to a client/server system is much easier if end users can experience similar operating functions. American National helped ease its transition by using the security tools to synchronize passwords across the multiple Oracle instances. With the mainframe environment, users were used to a single sign-on process that allowed complete access to all on-line systems once the initial identification was completed.

"We wanted to emulate that as closely as possible in the client/server environment," Newman says, noting that several GUI applications are generally opened and closed numerous times throughout the day by the same user. "Through the synchronization of passwords across multiple instances each application that is launched may actually be connecting to a different instance of Oracle. The user is allowed to use the same user ID and password on all instances because, once they set it in one place, that change is automatically propagated to other Oracle instances. The result is transparent to the end user." Also, Newman points out, users do not know which Oracle instance they are connected to because they use only one password.

"Data security was a major part of our philosophy to move over to client/server technology. Without the extra security tools, we could not have made the change as easily as we did," Newman says. Security tools such as BrainTree's SQL<>SECURE products provide sophisticated features that seamlessly integrate with Oracle applications. Newman says the system maintains an Oracle function that determines if users are enabled or disabled, whether passwords are current and if other "dysfunctions" exist. If, say the password is about to expire, a return code prompts the application to put up a dialog box suggesting the user change the password on the spot through the application that is running.

With multiple client/server applications available to users, Newman was also interested in limiting access through the security function. The system monitors the log-on process when the user connects to the data-base checking that the user is valid, the user can connect successfully to the database and the password has not expired. Newman has also added extensions to SQL<>SECURE that set parameters each application program must pass which identify the application and the user by job function.

This information causes certain Oracle roles to be activated for the lifetime of the application session. When the application session ends, termination of the Oracle session disables those roles for the user. As a result, the user cannot go through an ad-hoc query tool, such as Para-dox or Oracle SQL*Plus, and access those same tables outside the appli-cation because the roles were automatically disabled once the GUI session ended.

Other interfaces within the security system provide for administration and management functions that allow helpdesk personnel to access the SQL<>SECURE Password Manager when end users need assistance. "If a user forgets a password or the password has expired, the helpdesk can easily provide a temporary password to get the user operational without involving the database administration function," Newman says.

In addition to password authentication, American National Bank is pre-paring to install BrainTree's SQL<>SECURE Audit Manager. "Our primary use for auditing upfront is in connection with the password expiration function, as the audit manager needs to be running to actively manage the password expiration of the system," Newman says. "We will use the auditing tools to collect statistics on usage of the system by user and look for opportunities where we can track unsuccessful log-on attempts and determine if they are security breaches or opportunities for user education. Auditing may also reveal ways we can help our users better use the system."

Data Security and Oracle

Consider these guidelines for reviewing Oracle database security within your organization:

1. Remember to treat Oracle as an operating system, not as an application.
2. Regularly review all database users to ensure that users are deleted when they no longer need access. Logging on via "dead" accounts is one of the most common methods of gaining access to data.
3. Review users with database privileges. Do they need these privileges? Why? Is there another way the user can be allowed access without granting the privileges?
4. Consider the use of roles. Create roles for certain classes of users, operations staff, for example.
5. Ensure that any database application gives users the ability to change their passwords and, if possible, forces them to do so on a regular basis.
6. Regularly review audit-trail data. If possible, use triggers on sensitive database options.
7. Use restricted views of tables to limit the information a user is offered. A view could allow a user to check personnel records, but not to see salary data, for example.
8. Understand the limits of desktop authorization. Be aware that the desktop is not a secure environment. Be prepared to investigate some of the third-party security tools that secure desktop machines.
9. Control the software available to desktop users. Many tools are freely available that enable desktop users to access database information via ODBC drivers. Be aware that if your data security relies on the security of the application designed to access, there are other applications that may offer you better protection.

Conclusion

Securing databases within client/server environments requires planning and an understanding that third-party tools may be required to achieve the desired security level. With sensitive, corporate data the source of great wealth and importance in today's business, database managers like Jim Newman are putting data security policies and procedures in place that protect databases and make very good business sense.