our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at www.networkcomputing.com /express/

Injecting bogus SQL statements onto the network (spoofing) is almost as easy for industrial spies and disgruntled employees alike. A series of bogus messages might transfer money within the database, trigger the printing of a bogus check or provoke any number of similar disasters. Collecting SQL statements from a short eavesdropping session gives anyone with mischief on his or her mind enough information to build a highly accurate replica of critical portions of your database's schema.

Beefing up the security of your data-access middleware involves more than shielding the contents of your network's database server traffic. Those who want to steal or damage data crave physical access to client machines and servers. Keeping unauthorized hands off your computers is the first step toward safeguarding your database transactions. The next step is keeping them from poking around your network. Good database security keeps data confidential, identifies each person transacting with the database and resists attempts to spoof transactions.

Breaking the Code To explore data-access middleware security we set up ODBC (Open Database Connectivity) connections using two representative security-aware third-party products: High Performance Data Access drivers from OpenLink Software and DataDirect SequeLink ODBC Edition from Intersolv. In a second test, we enabled simple firewall filtering of network messages to secure our database transactions. Finally, we created secure SQL*Net connections with Oracle Corp.'s data-access middleware and its Advanced Networking Option. For both Oracle7 and Oracle8, we tested Advanced Networking Option's encryption of SQL*Net data (curiously, a function not provided by Oracle Security Server). Our experiments with these products' security features let us evaluate just how much we could improve security in a simulated vertical market application environment.

On a network consisting of two 100-Mbps Fast Ethernet LANs connected by Larscom CSU/DSU units and Cisco Systems routers, we used TCP/IP to transact with the Oracle database from within a Visual Basic test application. Our 25 database clients included Microsoft Corp. NT Workstation, Windows95, Windows98, OS/2 Warp (VB 16-bit) and Apple Computer Macintosh System 7 (ThinkC) platforms.

During our tests, we used Network Associates' Sniffer protocol analyzer software running on a Dolch PAC63 computer to eavesdrop on SQL messages as they traveled over the wire. The Oracle7 and Oracle8 RDBMSes ran on an NT Server 4.0-based Gateway 2000 NS-8000 computer with dual 333-MHz Pentium II processors, 512 MB of RAM and three 9-GB SCSI RAID drives.

Setting up security for data-access clients and servers is a relatively simple task. You toggle the configuration option for encryption at the server, and the client-side module discovers upon initial connection that it needs to provide a private key to communicate with the server. Unless you designate special privileges for the client, the public and private keys come from the data-access drivers. The client and server automatically issue and exchange the public and private keys used to verify each other's identity, so administrators do not need to maintain the encryption keys. For instance, SequeLink clients and servers embody Intersolv's Network Data Encryption scheme, which uses dynamically changing encoding tables for privacy.