This article investigates some of the security issues that organisations must address when implementing client/ server distributed database systems.

In a traditional centralised system, with dumb terminals, it is the operating system in the host computer that performs all the processing necessary for the operation of that system. All the screen handling, program logic, referential integrity checks, verifying the integrity of users wishing to use system resources and similar functions is done on that central computer. The terminals simply provide a view into that computer.

In client/server systems where the data may be distributed across multiple servers and sites, each with its own administrators, centralised security services are impractical as they do not scale well and more opportunities are available for intruders to access the system. The client PCs often run operating systems with little or no thought to security and the network connecting clients to servers is vulnerable.

Security is a concern from both a technical and management viewpoint. It is critical to examine the needs of the business and develop a security policy that addresses both of these issues.

Client/server systems

Prior to addressing individual security issues a brief explanation of client/ server computing is required. Client/server is an architecture in which a system's functionality and its processing are divided between the client PC and a database server. System functionality, such as programming logic, business rules and data management is segregated between the client and server.

Client/server computing comprises three building blocks:

• The client
• The server (may be more than one)
• The network (tying the client and server together).

A logical and physical separation exists between the client and server and the client/server system co-ordinates the work of both of these components and efficiently uses each one's available resources to complete assigned tasks. This separation of client and server provides an open and flexible environment where mix and match of hardware and operating systems is the rule. The network ties everything together. Today the client applications run predominantly on PCs connected to a network (or LAN). The servers are also connected to the network and know how to connect to their clients.

Security is often not given the consideration it requires in client/server partly because the implementation of security represents a cost that does not reflect an immediate return and partly because purchasers are often not aware of security issues and buy the cheapest client because they can get more for their dollar. 

Security in client/server

The distribution of services in client/ server increases the susceptibility of these systems to damage from viruses, fraud, physical damage and misuse than in any centralised computer system. With businesses moving towards multi-vendor systems, often chosen on the basis of cost alone, the security issues multiply. Security has to encompass the host system, PCs, LANs, workstations, global WANs and the users.

However, every level of system security requires dollars and additional steps for the users. The cost and inconvenience (to the users) associated with security must be balanced against the cost and inconvenience of corrupted or insecure data.

The client

As the primary front end device of a client/server system the desktop is typically the least mature with respect to security. Where the mainframe environment had a period of steady growth for more than 20 years, with the demand for security products that went with that growth, client/server has increased in popularity only since the early 1990s, and its hardware components, including the PC, has not been subject to the same security considerations that the mainframe has.

The client machines pose a threat to security as they can connect to the servers, and access their data, that are elsewhere in an organisation. One large problem is that they are easily accessible and easy to use. They are usually located in open plan offices that present a pleasant environment for users (and intruders) making it impossible to lock them away when unattended. Products are available that offer a measure of physical security by locking or bolting equipment and cabling into place.

Physical protection for the client machines can include disk drive locks, or even diskless workstations to prevent the loading of unauthorised software and viruses. The cases can be fitted with locks to prevent access to the hard drives, and memory. [4] One of the greatest risks with the client workstations is that the operating system is easily and directly accessible to the end user which exposes the whole system to a number of risks. The workstation operating system assumes that the person who turns it on is the owner of all files on the computer, including the configuration files. Even if the client/server application has good security, that security might not be able to counteract attacks at the operating system level which could corrupt data passed to other tiers of the client/server system. The tighter security now being offered with Windows NT addresses some of these issues.

Often client machines are bought based on cost alone, but in this case the cheapest may actually cost the company more as additional security features are added. Weak cases have to be strengthened to prevent opening and supplied operating systems replaced with more robust ones, for example the login password can be bypassed on Windows 95 machines whereas Windows NT V4.0 prevents access to the file system until authenticated but it costs two to three times more.

The network

The network connecting clients and servers is a less than secure vehicle that intruders can use to break into computer systems and their various resources. Using publicly available utilities and hardware an attacker can eavesdrop on a network, or "sniff" the network to read packets of information. These packets can contain useful information, e.g. passwords, company details, etc, or reveal weaknesses in the system that can be used to break into the system.

Encryption of data can solve the problem of attackers sniffing the network for valuable data. Encryption involves converting the readable data into unreadable data. Only those knowing the decryption key can read the data. A problem here is that some network operating systems don't start encryption until the user has been authenticated (i.e. the password is sent unencrypted).

Most systems employ re-usable passwords for authenticating users which allows an attacker to monitor the network, extract the login information and access the system posing as that user. Even if the password is encrypted the intruder can just inject that packet into the network and gain access. The problem is compounded when, to maintain that single system illusion, only one login is required to access all servers on the network. Customers want a "single system image" of all networked computing resources, in which all systems management and administration can be handled within a single pool of system resources.

To have a secure network it must conform to four basic principles of a trusted computing base (TCB):

• Identification and authorisation
• Discretionary control
• Audit
• Object re-use.

The fundamental aspect of the TCB is that if you can trust all of the security features, then the network can also be trusted. The TCB must be self protected against tampering and malicious, inadvertent altering and attempts to circumvent it.

The National Computer Security Centre's (NCSC) evaluation model specifies a C2 level of security that provides the above features. C2 is a defined level for operating systems requiring users and applications to be authenticated before gaining access to any operating system resource. All clients must provide an authenticated user ID, access control lists must protect all resources, audit trails must be provided, and access rights must not be passed to other users that re-use the same items.

User authentication can be managed by the Kerberos authentication mechanism. The Kerberos protocol, with add ons introduced by the Open Software Foundations Distributed Computing Environment (OSF DCE), fulfills the authentication requirement of C2. Kerberos is a secret key network authentication system that uses DES for encryption and authentication. It authenticates every user for every application. It consists of three distinct services that provide access to network resources, Registry, Authentication and Privilege Servers.

In DCE, users, servers and client computers are all referred to as "principals". The Registry server creates user accounts for the network principals and unique user IDs are created and stored with other information in the security database. At the time of logon, the DCE security system uses encrypted "keys" that reflect private validation information, such as a principal's password, the server and services or data required. This process of validating a principal through credentials is known as authentication. At the time of the logon request, a logon request is submitted to the Authentication Server. [6, 7]

The Authentication Server responds to the logon service by forwarding a ticket that is encrypted using the user's secure key. Once received by the logon service, an attempt to decrypt the ticket is made using the password supplied by the principal. If a valid password has been supplied, a new ticket will be created by the logon service. This ticket is then forwarded to a Privilege Server, where a new ticket is created that will be used to provide access to a specific application server and the specific services required. Properties of the Kerberos tickets include encryption of the ticket to insure its authenticity. If any data within the ticket is modified, the ticket becomes invalid. Further, tickets are issued with a specific time duration to protect against an attempt to modify, copy, or utilise someone else's ticket. The DCE Security Service is designed to allow applications to authenticate not only users, but servers as well. This is provided with each application server having again its own secret key that can be used by the security service to send packages that only the true server can decrypt. [6, 7]

Once the client receives the ticket, it presents the ticket and request to the targeted server. The server then compares the incoming ticket with the ticket from the Kerberos server to verify that the client has access. [6]

Applications, files, and other DCE services then use Access Control Lists (ACLs) to identify specific access privileges of a principal, whose individual or group identity is provided via the ticket. An ACL might identify whether a principal has read, write, test, or other permissions against a file or records within a database. If the ACL permissions match the action requested, the access is granted; otherwise, the RPC call is denied and a result returned to the calling application. [1, 7]

The purpose of the DCE Security Service is to provide a security architecture that provides both users and servers the ability to communicate in a manner which is very difficult to impersonate. This allows servers to offer service only to authorised users, and it allows users to have confidence that they are communicating with the "real" server. An illustration of the DCE RPC authentication and application access sequence is shown in Figure 1.

Audit services allow network managers to monitor user activities, including attempted logons and the file servers or files used. It is achieved by monitoring all user workstations and recording transaction activity. Most network operating systems support audit trails. Securing the network also requires securing the devices. This is particularly important on the devices that interconnect large parts of the enterprise, such as the backbone or campus routers. These devices should be in one spot or in secure rooms placed strategically around the enterprise. They can be engineered to generate an alarm (raise a management event) if the cases are opened, module removed or if anything is changed.

Additional levels of security are also provided by building in rules, filters and screening into the interconnecting devices. For example, a router can be configured to only allow certain IP addresses access to a segment of the backbone.

The server

The first line of defence for the server(s) is to have the server centre in a secure location where access, by authorised personnel only, can be supervised and administration can be performed simply. The server should be attached to an uninterruptable power supply as this protects the server by filtering the mains and provides backup power should the supply fail. This allows the server to shut itself down in a controlled manner to protect data.

The servers should be protected with the level of password security applicable to the business. Upgrades to the server software should be planned, monitored and controlled with updates done out of hours. Virus protection should also be active on PC-based servers.

To ensure privacy of the data the entire contents of the database can be encrypted using either cryptogram or advanced DES encryption mechanisms. The level of encryption is dependant on government regulations. For example, SQLBase supports a minimum of 40-bit encryption.

Some database systems, e.g. Oracle, can validate database users without database passwords by using information in the hosts operating system authentication mechanism. This simplifies the database security administration as it is centralised at a system level. However, the problem with this is that often the database user does not have to start a host session on the database server before using the database across the network, effectively bypassing the operating system security mechanisms.

Many client/server database systems do not have adequate password management facilities similar to those found in operating systems. This means that there is no easy way for the database administrator to ensure that users have chosen good passwords and will change them frequently. Most database systems allow users to change their passwords using simple SQL utilities. Unfortunately these SQL utilities do not force the user to verify the current password prior to changing it. Therefore, it is easy to change another user's password. Third party database password management utilities are starting to appear which address the above deficiencies.

To guard against "trial and error" login attacks to a database, servers can impose increasingly long delays in responding to a user, with additional mechanisms to alert other users in the event of a protracted attack.

Server database software vendors are now extending their products to include government specifications for multilevel data security. Database management systems can offer their own security, for example, Sybase uses stored procedures to define, limit and authorise user access. By storing the security within the database, no data can be accessed without going through the security checks.

The integrity of the database can be maintained by guaranteeing that data cannot be changed except through the control of the database. Page checksums enforce this.

The users

The first line of defence against illegal entry to a multi-user client/server system is user identification and authentication. It follows, that the easiest way to gain illegal entry to the system is by obtaining a valid users ID and password. The problem with keeping passwords secret has been around since passwords were invented. For example, they can be discovered when:

• The user picks a short password or one that is easy to guess, such a spouse's name
• The user keeps a list of passwords taped on the screen or in a desk drawer
• The users share their passwords with other users
• An attacker phones the user, posing as one of the companies IT staff, and requests the user's password to fix an unnamed problem.

To overcome this a good security policy and strong password management must be implemented. A security policy will set guidelines for minimum password length, types of passwords that can be chosen, how often passwords should be changed, and so on. Password management utilities are available to check for guessable passwords, for minimum lengths and regularly ask users to change their passwords.

Conclusion

There is no one solution that addresses all security issues raised when implemeeting a client/server system. The view to the users must be that of a single homogeneous system when the reality is that it is a system made up of multiple levels and parts, each with its own security issues.

The enterprise security policy should encompass the physical security of devices, including the physical media in which the data is carried, the backup of critical data, which should not be stored on a desktop where it can be copied to a diskette and the integrity of the network and the database through authentication and access control.

Users are often not receptive to mandatory security procedures because the very measures used to keep attackers out are just as effective at keeping the users out. One solution is to carry out as many of the security measures as possible at the network level rather than at individual workstations. This can be achieved in a network operating system that supports OSF's DCE (i.e. Kerberos).