Chapter 7
Information security services to be provided by a database server
in a virtual web database environment
7.1 Introduction
The database server in the virtual web database environment of ABC Bids is the repository of all information such as items to be auctioned, member details or payments made by members. This information is a key asset of ABC Bids, without which the company would cease to exist within days. Its security is therefore of prime importance.
Normally, corporate information would be unavailable to the public. However, the virtual web database environment allows large numbers of unauthorized users or registered members to interact directly with the information in the database server through the web server interface provided. This increases the potential for security breaches.
The database server in a virtual web database environment is the centre around which transactional and other activities revolve. Figure 7.1 shows how a request from a member to add an item to the ITEMS table is processed. The member requests a page from the web server, where all item details are entered on a form. When the form is submitted, a web server script invokes a component at the application server that executes logic containing business rules that might limit maximum and minimum bid prices. Another application server component will then be invoked that will connect to the database server to write the record to the ITEMS table in the
database. A response is returned to the member, indicating the success of the transaction. HTTP Member
ODBC
Figure 7.1: A database server in a virtual web database environment ABC Bids VIRTUAL WEB DATABASE ENVIRONMENT
RMI
IIOP JDBC DCOM ODBC
OS ACLs Web server HTML XML ASP/JSP CGI WWW, mail, FTP, telnet, news
apps
Apps InternetOS ACLs Application server COM+/EJB Java C++ VB
OS ACLs Database server DBMS Ad hoc SQL support Stored procedures Remote DB listener Network services components
Figure 7.1 shows that a database server consists of more than the DBMS. Ad hoc SQL support, extended stored procedures, the remote database listener and network services are provided with database servers and can all introduce security vulnerabilities. The database administrator of ABC Bids should ensure that these features and services are configured securely or removed.
As the database server holds valuable information such as credit card numbers, it can be a prime target for attackers. Database servers provide a vast array of security features, such as user accounts and passwords, auditing and access control to database objects. These features have provided a good measure of security to database servers in the past, but the playing field has changed dramatically since database servers have been exposed to the Internet.
In chapter 3, current state-of-the-art database security was investigated in terms of identified security services and associated mechanisms. The remainder of this chapter will attempt to determine the extent to which these services and mechanisms can provide protection to the database server in a virtual web database environment. In this process, additional services and mechanisms may be identified that would be specific to a database server in a virtual web database environment. The database server information security threats identified in chapter 2 will then be revisited to establish whether they have been addressed.
7.2 Information security services to be provided by a database server in a virtual web database environment
The information security services that were used to discuss and investigate current state-of-the-art database security are identification and authentication, authorization, confidentiality, integrity, audit, availability, manageability, assurance and physical security. It now needs to be determined which of these services and mechanisms can be employed successfully in a database server in a virtual web database environment. Each of these information security services can be described by using the ABC Bids case study.
• Identification and authentication
The database server will identify and authenticate administrative users and application servers.
• Authorization
Application servers accessing the database server on behalf of members need certain permissions to, for instance, allow members the ability to create, view, change or delete their own items and view all bids on their items.
• Confidentiality
Some sensitive data such as credit card numbers, stored in the database server, must be protected from prying third parties such as employees of ABC Bids. This data should also be kept secret as it is moved from the application server to the database server.
• Integrity
The message received by the database server must be the same as that sent by the application server. The data entered into the database server must be correct and it must stay that way as items are added or bids are processed.
• Audit
The database server must keep track of all requests and administrative changes made by all users of the database server to ensure accountability.
• Availability
The database server of ABC Bids must be able to continuously process the requests that are sent to it by the application server.
• Manageability
Administrators must be able to easily configure and manage the security of the database server.
• Assurance
The database server security mechanisms must be assured to operate at a high degree of confidence.
• Physical security
The database server must be protected from theft, natural disasters and malicious damage.
Each of the above security services needs to be further explored to determine how the security of the database server could enhance the security of the virtual web database environment of ABC Bids. At the end of each service, state-of-the art products will be reviewed to show how database security services can be implemented.
7.2.1 Identification and authentication
Ideally, the database server should be identifying and authenticating all users and directly controlling what they can see and do. This, however, is not feasible in the case of a virtual web database environment. Sophisticated virtual web database environments that support millions of users make it impractical to create and manage a user account on the database server for each and every user. Not only does this result in an administrative nightmare, but it is also resource-intensive, making the database server slow and unresponsive.
To solve this problem, the application server can be given the responsibility of acting on behalf of users. The importance of web server identification and authentication of users should now be clear. The application server connects to the database server on behalf of users that it trusts to have been authenticated by the web server. To enable the database server to allow this, it needs to trust the application server. Therefore, the application server needs to be authenticated to the database server by presenting a digital certificate. [HEIM00]
This scenario is successful in situations where users can be categorized into groups. When data belongs to a specific user, or a very small group of users, it might be necessary to give them the ability to access the data under their own accounts. Username and password pairs can be employed to identify users such as an employee who has to update specific tables such as the PAYMENT_DESCRIPTION lookup table. Administrators of the database server will also have to be identified in such a way.
A database server placed on the Internet is highly exposed. For this reason, special care must be taken with default accounts and their default or non-existing passwords. For example, on 15 July 2000 eWeek Labs’ Openhack e-commerce site was cracked after 1,5 million attempts. [DYCK00] The vulnerability that was exploited was an Oracle MDSYS user account with administrator privileges. Its default password was accidentally not changed.
Database servers provide this service at the level stipulated in the current state of database security discussed in chapter 3, although it is insufficient for the virtual web database environment. Additional mechanisms such as authentication with digital certificates have to be employed, as shown in table 7.1.
Table 7.1: Additional database server authentication mechanisms Legend: DB = Database security; DS = Database server
Database security service Mechanism Employed by
Identification and authentication
Database authentication DB DS
Operating system authentication DB DS
Others (DCE, Kerberos, trusted client) DB
Digital certificates DS
Product review – identification and authentication
Database servers can authenticate users with passwords. Generally, databases do not enforce strong password management. In contrast, Oracle 9i allows administrators to enforce minimal password length, password complexity and password re-use. Accounts can be locked out after successive failed login attempts. [ORAC01]
Database servers need to authenticate application servers with digital certificates. This is not a functionality that is included in database servers. For instance, Oracle Advanced Security is an add-on, which allows Oracle database servers to support SSL to be able to authenticate application servers with digital certificates. [ORAC01]
Oracle database servers have been enhanced with abilities to incorporate LDAP directory services. This allows information such as the role of a user to be available from the web server to the database server. [ORAC01]
7.2.2 Authorization
Database servers in a virtual web database environment can utilize discretionary, mandatory and role -based access control policies, through which authorization to database objects can be enforced. It is important to analyze the measure of security that each of these access control policies would provide, as well as how they can be administered in a virtual web database environment.
a) Discretionary access control (DAC)
This is the most common form of access control used in database servers. DAC can only be implemented if the database server recognizes each user. Therefore, each member of
ABC Bids will have to be given a database server account with specific permissions assigned to it. The administration overheads involved in implementing DAC for a large member population are substantial. This makes DAC unpractical to be used by a database server in a virtual web database environment. Furthermore, as data can be copied to a user who is not authorized to access it, the application of DAC would not be effective in meeting the security requirements of ABC Bids. ABC Bids needs access control to database objects to be highly assured when it exposes its data to an open environment such as a virtual web database environment.
b) Mandatory access control (MAC)
MAC can enforce far better control over database objects by controlling the flow of data. This type of access control would therefore be very effective, as very sensitive data can be given assured protection when exposed on the Internet. A problem is that it would be difficult to classify all database objects and users of a commercial environment such as ABC Bids into strict security classes. Furthermore, as the administrator must classify all users and database objects, it is an inflexible policy to manage. The administration of MAC will entail large overheads, since the database server must recognize all users. These factors make complete implementation of MAC by the database server of ABC Bids impractical.
c) Role -based access control (RBAC)
RBAC allows a set of permissions to be assigned to a role such as “members”. In the virtual web database environment, the application server would be connecting through to the database server on behalf of users who belong to role s such as “members” at application server level. By creating a similar set of roles in the database server, these roles can logically be used together as the request moves from the application server to the database server.
The permissions that these database roles will possess should not be more than what the user, for whom the application server is making the request, should have. The principle of least privilege can be enforced in this way. The application server can ensure that a user for whom it is making the connection can only activate one role at a time. This enforces separation of duty. RBAC will not only ease the administration overheads, but will also
ensure effective access control to database objects in the database server of ABC Bids.
An interesting point to note is that no member accounts belong to a role in the database server, since no members are created there. This type of role is not the normal type of database role, but can be classified as an application role. These roles restric t users such as members to only access the database server through the application server.
As stated before, RBAC is policy neutral, and allows a partial implementation of MAC. The concept of a security class and a role can logically represent the same entity. If ABC Bids had a group of users such as “financial analysts” and only wanted them to access specific data, it could enforce MAC by creating such a role and giving only that role access to the required data. This role should be under the control of the administrator only.
ABC Bids can further make use of pre-defined database roles that have pre-assigned permissions to perform tasks specific to the operator or administrator. These users will have to have database accounts that can be assigned to the role needed.
d) Other considerations
If an application server is outside the corporate firewall, it could be granted roles with less permission than application servers that are not. These application servers connecting on behalf of users may, for instance, only read data in a view and not update it.
Very often, developers may feel that they are applying stringent access control at the application server and that it is unnecessary to apply this same level of access control at database server. All application server requests might be given unrestricted access to the database server, with full access to all database objects. Even though the proposed access control to be used by ABC Bids through application roles is not applied on a strict per-user basis, it still ensures that database objects are protected from situations where hackers might gain unauthorized access to the database server.
The database server in the virtual web database environment of ABC Bids should implement access control by creating database objects, such as views and stored procedures. Application roles such as “members”, “clerks” or “managers” can then be given permissions to these
database objects as required. This ensures that no direct access to tables or parts of tables is allowed. No access is allowed, except through the application server.
It is clear that authorization at the database server in the virtual web database environment can be implemented successfully at the level of authorization of the current state of database security discussed in chapter 3. Table 7.2 shows database server authorization mechanisms. Table 7.2: Database server authorization mechanisms
Database security service Mechanism Employed by
Authorization
DAC policy ACLs, RBAC DB DS
MAC policy Bell-LaPadula, RBAC DB DS
RBAC policy RBAC DB DS
Product review – authorization
The concept of an application role is not always directly supported in database servers. Very often, an account is created in the database server, given permissions and is used by an application server for the purposes of the application server and its users. This is sometimes called a shadow login, since no real user is represented by the account. In contrast, Microsoft SQL Server v7.0 and v2000 [MSSQ01] users can be restricted to access data only through a specific application by using application roles. These application roles contain no members and are inactive by default. [SPEN01] SQL Server authenticates applications with the password associated with the application role.
Oracle 9i, released in 2001, includes a secure application role that can only be activated by an application. [HEIM00] The database server can keep track of the real user for whom the application server is making the connection, as this information is available via an application context or in a user session. Furthermore, Oracle provides for a security option called Oracle Label Security in Oracle 8i and 9i. The labelling feature allows data to be labelled per row. Users can access data if their profile contains a valid label. This can allow the implementation of a MAC policy. [LELI01]
7.2.3 Confidentiality
It is very important for the database server of the virtual web database environment to protect the confidentiality of data that is sent to it, as well as the data that it stores.
Data that is sent from the application server to the database server must be encrypted to ensure its confidentiality. The data could include connection information such as passwords, as well as results of queries sent to the application server. Database servers do not directly support encryption at this level. They can be enhanced with capabilities, such as allowing SSL to be enabled. SSL can provide a secure channel between the application server and database server to protect data through encryption.
When data such as a member’s credit card number arrives safely at the database server, the protection provided by SSL is lost. It is known that hackers have broken into databases exposed on the Internet and have managed to steal information such as this. ABC Bids can very quickly be perceived to be a credit risk and members will stop using it. If the credit card numbers were encrypted, it would be safe. The encryption mechanisms that database server vendors provide should be used to protect sensitive information. Code such as stored procedures that is sensitive can be protected in the same way.
Confidentiality of data should be further protected from inferences that can be drawn by employees of ABC Bids. These employees should not, for instance, be allowed to access the average of bids made on an item. If all bids were displayed, they would be able to infer the highest bid amount placed, if there is only one.
Employees directly involved in the day-to-day administration of the database server of ABC Bids must be made aware of the role that they play in protecting the confidentiality of data. The database administrator of the database server has permissions to all database objects and must be monitored carefully.
For a database server in a virtual web database environment, the confidentiality service is found to be lacking, since no protection is provided as data is transmitted to and from the application server. Table 7.3 shows an additional confidentiality mechanism to be employed by a database server in a virtual web database environment.
Table 7.3: Additional database server confidentiality mechanisms
Database security service Mechanism Employed by
Confidentiality
Encryption DB DS
Inference control DB DS
Employee training DB DS
Product review – confidentiality
Confidentiality of stored data can be ensured in various ways. Oracle9i provides the PL/SQL package DBMS_OBFUSCATION_TOOLKIT to encrypt and decrypt stored data using single or triple DES (data encryption standard). [ORAC01] Microsoft SQL Server allows encryption and decryption of data when a database trigger such as “After Insert” is fired. This will ensure that the field is always encrypted when stored. [WYNK97]
Confidentiality of data must be ensured as it is moved across the network. This is not a functionality that is directly provided by database servers. For instance, the Oracle Advanced Security add-on gives Oracle database servers the capability to enable SSL to allow encryption of the message. [ORAC01]
7.2.4 Integrity
The integrity of a database server in a virtual web database environment has to be maintained at all times. The information of a company such as ABC Bids is its lifeblood and all efforts must be made to ensure its consistency.
Various aspects have been defined in the current state of database security in chapter 3 that can be used to protect the integrity of the database server. The operational and semantic integrity of the database server needs to be maintained, as described in chapter 3.
Following the exposure of the database server within a virtual web database environment on the Internet, database integrity mechanisms require more attention. In addition, messages sent to and from the application server must be protected from tampering.
A firewall is an additional mechanism that can be used to protect database server integrity. The protocols on the firewalls can be changed to allow, for instance, only ODBC, JDBC and database server vendor supplied connector libraries, as shown in figure 7.1. This will protect the database server from all unlawful external, as well as internal accesses. All activity should be monitored, to detect possible attacks.
As the database server is more exposed, the administrator of the database server of ABC Bids will have to ensure that the database server software is configured securely. The database server can, for instance, be configured to accept connections only from specific IP addresses. All unnecessary services must be disabled and all ports running by default must be closed. This will protect the data from users who try to access the database server unlawfully with desktop query tools, with the aim of corrupting data.
All possible security vulnerabilities must be removed by applying all vendor-supplied security patches. Virus detection software must be installed and updated regularly. This will protect data from any damage. These aspects are furthermore very important for a database server exposed on the Internet, since a compromise at the database server can compromise the whole virtual web database environment. For instance, an attacker who gains access to extended stored procedures in Microsoft SQL Server can reconfigure the IIS web server to accept anonymous logins. [BLAC99]
Finally, the message sent to the database server must be protected by checksums. By enabling SSL, the integrity of the message can be maintained.
The current state of database security discussed in chapter 3 provides a proper set of integrity mechanisms. In addition, database integrity, as well as the message sent requires additional mechanisms, to provide protection in the changed environment. Table 7.4 shows additional mechanisms that can be added to database server integrity mechanisms.
Table 7.4: Additional database server integrity mechanisms
Database security service Mechanism Employed by
Integrity
Database integrity Checksums DB DS
Virus and Trojan Horse protection DB DS
Patch vulnerabilities DB DS
Proper configuration DB DS
SSL (checksum) DS
Firewalls DS
Intrusion detection tools DS
Operational integrity Transaction processor DB DS
Semantic integrity Entity integrity DB DS
Referential integrity DB DS
Domain integrity DB DS
User-defined integrity DB DS
Product review – integrity
Database servers need to protect the integrity of software and stored data with a wide range of mechanisms. For example, Oracle Advanced Security can be added to Oracle database servers to provide data integrity with Message Digest 5 (MD5) algorithm support, when the message is sent to and from the application server with SSL. The DBMS_OBFUSCATION_TOOLKIT PL/SQL package can allow data in the database server to be hashed with MD5 to ensure data integrity. In addition, a Java Cryptographic Extension (JCE) provider allows Oracle JServer applications to hash selected data such as fields, rows or tables with MD5 and SHA-1. [WESS00]
7.2.5 Accountability
The database server in a virtua l web database environment should record all application server and administrative user actions. This data can be used to ensure accountability and to detect any possible intrusions. Audit can be done at a very detailed level and must be planned carefully. The database server should implement, for instance, object auditing on selected tables such as PAYMENTS or BIDS, privilege auditing to track changes made on the database and security auditing to follow permissions being changed.
The user performing the action should ideally be included in the audit record. As application servers access the database server on behalf of users, audit records will reveal the actions the application server is performing on behalf of the user. This does not enforce the
accountability of the real user. For audit data to be meaningful at the database server, the identity of the real user for whom the application server is making the connection must be included. This information might be included in a parameter, which is part of the connection string used to connect to the database server. The database server can then include the member identification in its audit records.
Audit data is voluminous and difficult to read. For audit data to be meaningful, an audit analysis tool should be used. This analysis tool should ideally integrate the log files of the web server, application server and database server. Furthermore, if a security breach is detected, the administrator needs to be alerted as soon as possible.
The database server of the virtual web database environment can provide audit as a service if the identity of the real user is passed to it.. Table 7.5 shows the additional accountability mechanisms to be used.
Table 7.5: Additional database server accountability mechanisms
Database security service Mechanism Employed by
Accountability
Audit DB DS
Identity of real user to database server DS
Log analysis tool DS
Alert when breach detected DS
Product review – audit
A database server such as Microsoft SQL Server allows its authentication to be done by the operating system through Windows Authentication Mode. If an application role is used by an application on behalf of a user, Windows NT 4.0 or Windows 2000 can audit the user account, if it has been previously authenticated. [MSSQ01]
VigilEnt Audit Manager [PENT01] provides enhanced auditing for Microsoft SQL Server 7 and Microsoft SQL Server 2000 databases. It uses native Microsoft SQL Server stored procedures and audit triggers to provide finely tuned auditing for auditing user actions and data modifications within the database server.
7.2.6 Availability
An anonymous user of ABC Bids, browsing a list of items to be auctioned, will not spend more than seconds on the web site if item data is unavailable or the response time is unacceptable. For this reason, the availability of the database server in the virtual web database environment is crucial.
The current state of database security investigated in chapter 3 listed hardware redundancy, backup and recovery, replication and a contingency plan as aspects that could enhance database server availability. All these aspects are even more important to ensure high availability of the database server in the virtual web database environment.
A problem that faces the database server is that its availability cannot be as easily improved by replicating it in real terms, as in the case of the web server and application server. If
various database server instances are used to process more requests, integrity of data can be compromised. Availability of a continuously updated database server in a virtual web database environment can be improved by hardware solutions, such as using more expensive servers capable of better performance with more processors.
Enhanced hardware does not provide for availability if there is a failure. Careful examination of the database design could reveal that it can be partitioned. For instance, the MEMBER table can be split according to where the members are located. If a partition fails, not all members may be affected by the problem. [MULL00] Replication of some selected tables, such as lookup tables that are not frequently updated, may also achieve better availability by eliminating a single point of failure. Identical access control configurations should be applied to these replicated or partitioned tables.
The current state of database security identified in chapter 3 provides mechanisms that will ensure availability. Partitioning of the database and replication of selected tables can be helpful in the case of hardware failure. Table 7.6 shows database server availability mechanisms.
Table 7.6: Additional database server availability mechanisms
Database security service Mechanism Employed by
Availability Hardware redundancy DB DS Backup DB DS Recovery DB DS Replication/partitioning DB DS Contingency plan DB DS Extended configuration DS
Product review – availability
Availability of database servers can be ensured in various ways. For instance, the Dell PowerEdge 8450 is an eight-way server that can improve the performance of computationally heavy database transactions. [BASS00]
Informix Dynamic Server provides internal parallelism so that database operations, such as I/O, complex queries, index builds, log recovery and backups and restores, can execute in parallel across all available system resources. [INFO01] Microsoft Cluster Services enables a database server that fails to be automatically replaced by a backup through a RAID device. [MSSQ01]
7.2.7 Manageability
Without a management tool the database administrator will require a high-level knowledge of SQL to create user accounts, set permissions, create roles and audit selected database actions. The management of the security of the database server in the virtual web database environment will be fraught with error and complex to manage. This can introduce errors such as assigning incorrect permissions to users, disabling accounts of retrenched employees after they have left and allowing temporary permissions that have been assigned to users to endure forever.
The database server of ABC Bids should include a management tool that would allow the administrator to secure it easily. Aspects such as creating user accounts and passwords, groups and roles, permissions and auditing and performing backup and recovery should all be addressed.
This tool should include a graphical interface that can allow the administrator to drag and drop permissions to roles or accounts and roles to roles. It should include a feature to allow the administrator to set selective auditing on database objects and statements, as well as the before and after values of sensitive fields. Backup and recovery procedures should be created and modified easily. The administrator should, for instance, be able to select what types of database server files to update, the intervals at which this must be performed and the media to which the files must be written. Recovery should also be automated to allow speedy return of availability.
It is very important to protect the management tool from intruders. Its access control should be managed carefully. Remote access to it should be encrypted and it should be kept in a protected environment.
The current state of database security identified in chapter 3 provides manageability as a service. Management tools are very important, since the security of the database server is complex to maintain and configure. Table 7.7 shows database server manageability mechanisms.
Table 7.7: Database server manageability mechanism
Database security service Mechanism Employed by
Manageability
Security management tools DB DS
Product revie w – manageability
The Oracle Enterprise Manager [MORA01] allows new privileges to be granted to users or roles by a drag-and-drop functionality. Password profiles can also be created to set expiration dates for passwords, write verification routines and define when passwords can be reused. Resource restrictions such as limiting the number of database sessions and prohibiting excessive CPU usage are associated with these profiles. Other aspects such as backup and recovery, redo logs, rollback segments, archived logs and physical backups of data are also addressed.
7.2.8 Assurance
Database servers have an advantage over web servers and application servers in that they can be highly assured. The database server of the virtual web database environment of ABC Bids should ideally be a database server that has been successfully evaluated with ITSEC, or TCSEC evaluation criteria. Tables 7.8 and 7.9 show some of the database servers evaluated until August 2001. [ITSE01] [TCSE01]
Table 7.8: Database servers at TCSEC C2 level are assured for commercial environments
TCSEC evaluated database server Level Certification date
Informix Online/secure v5.0 B1 Nov 94
Trusted Oracle v7 B1 April 94
Oracle v7 C2 April 94
Sybase Adaptive Server Anywhere v7.0.0 C2 Sept 2000
Microsoft SQL Server v2000 C2 Aug 2000
Table 7.9: Database servers at ITSEC EAL4 level are equal to TCSEC C2 assurance
ITSEC evaluated database server Level Certification date
Oracle v7.2.2.4.13 EAL4 Sept 1998
Oracle 8i v8.1.7.0.0 EAL4 July 2001
The database server of the virtual web database environment of ABC Bids must be configured according to the criteria specified in the evaluation report released by the evaluating body. The database server must, for instance, be installed on a secure operating system. If this is not done, an evaluation rating such as C2 is meaningless.
In addition, security settings such as permissions assigned to application roles need to be tested to ensure that they work as expected. Furthermore, assessment tools can assist in assuring the security of the database server in a virtual web database environment.
The database server in a virtual web database environment provides assurance at the level stipulated by the current state of database security defined in chapter 3. Table 7.10 shows database server mechanisms that can be employed to improve the assurance.
Table 7.10: Additional database server assurance mechanisms
Database security service Mechanism Employed by
Assurance
Certification DB
Test security configuration DB DS
Vulnerability assessment tools DS
Product review – assurance
The NSA (National Security Agency) evaluated the Sybase Adaptive Server Anywhere (ASA) 7.0.0 with C2 Update in September 2000 and rated it at C2 level in accordance with TCSEC. [NSAT00] This means that discretionary access control and some degree of accountability are supported. This certification applies only if the database is installed as prescribed. ASA executed on the Microsoft Windows NT 4.0 with Service Pack 6a and C2 Update operating system.
7.2.9 Physical security
If a disaster such as a fire should destroy the facilities of ABC Bids and all data is lost, the company will have to close. The database server of ABC Bids should be physically secured to protect it from theft, malicious attack or natural disasters. An important aspect is the physical security of the backups stored at another site. The current state of database security in terms of the physical security service defined in chapter 3 can be successfully employed at database server level, as shown in table 7.11.
Table 7.11: Database server physical threat mechanisms
Database security service Mechanism Employed by
Physical security
7.3 Database server information security services and the threats facing the database server of ABC Bids
Database server threats will now be revisited to see if they have been addressed by current state– of-the-art database security services and mechanisms discussed in chapter 3. Table 7.12 shows all threats as well as the services that can address them.
Table 7.12: Database server threats and security services that can provide protection
7.3.1 Network threats Services
1. An attacker may try to intercept sensitive details such as passwords or credit card details as they are sent between the different servers.
Confidentiality – SSL can encrypt the message as it is
transmitted.
2. An attacker may try to change the data in a message as it is moved between the different servers.
Integrity – SSL can hash the message as it is
transmitted.
7.3.2 Database server threats 1. Buffer overflow vulnerability in the database server
of ABC Bids allows a remote attacker to assume control of database server. Because the database server is running on a Windows system, the attacker gains control of the underlying operating system.
Integrity – By applying all patches, the vulnerability
can be removed. Firewall and intrusion detection might detect and stop the intruder.
Audit – By enabling audit, suspicious activities can be
detected. Log integration and analysis tools can aid to allow an alert of this condition.
Availability – By keeping backups of data, it can be
restored if needed.
Assurance – Using a TCSEC or ITSEC DBMS and
configuring it as specified may prevent this. Vulnerability assessment tools might detect the problem.
2. An attacker exploits a default password on the database server, where the password was never changed.
Identification and authentication – All default
passwords should be changed.
Integrity – Firewall and intrusion detection might
detect and stop the intruder.
Assurance – Vulnerability assessment tools might
detect the problem.
Manageability – The management tool can aid the
administrator in managing such passwords. 3. The administrator of the ABC Bids database server
finds that the task of assigning accounts to the huge number of users is becoming an administrative nightmare. Furthermore, the database server is experiencing performance degradation.
Authorization – By using RBAC with application
role, the process of ensuring access control is simplified.
Availability – By incorporating more processors or
hardware, performance is restored to an acceptable level.
4. An attacker uses a desktop query tool to gain direct access to the database server. The attacker manages to access tables in the database through the account of a friend who has disclosed his/her password.
Identification and authentication – The password must
be changed regularly.
The authentication required by the database server with digital certificates will prevent this.
By using stored procedures no direct access to tables is allowed.
Integrity – By allowing only specific IP addresses to
access the database server, this can be prevented. Firewall and intrusion detection might detect and stop the intruder.
Confidentiality – Training employees not to disclose
their passwords can prevent this.
Audit – By enabling audit, suspicious activities can be
detected. Log integration and analysis tools can aid to allow an alert of this condition.
Availability – By keeping backups, data can be restored
if needed. 5. A developer of ABC Bids installs a Trojan Horse
that will notify him/her of any changes that are to be made to passwords.
Identification and authentication – The developer might
be deterred if the database server knows his/her identity.
Access control – The developer must not have the
ability to install the Trojan Horse.
Integrity – Virus detection software can prevent this.
Firewall and intrusion detection might detect and stop the developer.
Audit – By enabling audit, suspicious activities can be
detected. Log integration and analysis tools can aid to allow an alert of this condition.
Availability – Data destroyed by the developer at a later
stage can be restored with backup and recover procedures.
Manageability – This can aid the administrator in
correctly assigning permissions to the developer. 6. When the management of ABC Bids analyze
reports produced from information kept by the database, they find discrepancies such as bids without related members.
Identification and authentication – The application
server must be authenticated with digital certificates.
Integrity – By setting semantic integrity constraints, this
can be prevented. A transaction processor can write back all partial results if a transaction aborts.
Audit - By auditing all events, the source of the problem
can be determined.
Availability – By keeping backups, the data can be
restored. 7. A disgruntled employee of ABC Bids tries to
access credit card numbers of members stored in the MEMBERS table.
Identification and authentication – The employee might
be deterred if the database server knows his/her identity. No access should be allowed except through the application server.
Authorization – The employee should not have
permission to see this data by utilizing stored procedure and views with roles. By employing application roles that can only be enabled through an application, access can be prevented.
Confidentiality – By selectively encrypting this field as
it is stored, it will be unreadable.
Audit – The actions of the employees can be tracked
with audit logs. Log integration and analysis tools can aid to allow an alert of this condition.
Manageability – A management tool can help the
administrator to give the employee the relevant role and permissions.
7.3.3 Employees and facilities threats
1. The database server is stolen. Physical security – By locking the database server
away, this can be prevented. 2. An attacker gets a password from a member by
social engineering.
Confidentiality – By training employees not to disclose
their passwords, this can be prevented. Ensuring that all employees are aware of the security policy might minimize this threat.
3. A retrenched employee uses his/her still valid password to access the database server to make a copy of all credit card numbers to use against ABC Bids.
Identification and authentication – The employee might
be deterred if the database server knows his/her identity.
Access control – By disabling the account with
permissions before the employee is retrenched, this can be prevented.
Audit – By tracking all employee activities, this can be
detected.
Manageability – By using a management tool, the
administrator can be aided to perform this task with haste.
This table shows that the additionally identified security services and mechanisms to be implemented by a database server in a virtual web database environment can provide more protection against database server threats.
7.4 Conclusion
Table 7.13 summarizes all security services and associated mechanisms to be employed by a database server in a virtual web database environment. The services and mechanisms are almost identical to those provided by current state database security. Other mechanisms that have been included accommodate the security requirements of the virtual web database environment.
Table 7.13: All database server security services and mechanisms
Database security service Mechanism Employed by
Identification and authentication
Database authentication DB DS
Operating system authentication DB DS
Others (DCE, Kerberos, trusted client, etc.) DB
Digital certificates DS
Authorization
DAC policy ACLs, RBAC DB DS
MAC policy Bell-LaPadula, RBAC DB DS
RBAC policy RBAC DB DS
Confidentiality
Encryption DB DS
Inference control DB DS
Employee training DB DS
Integrity
Database integrity Checksums DB DS
Virus and Trojan Horse protection DB DS
Patch vulnerabilities DB DS
Proper configuration DB DS
SSL (checksum) DS
Firewalls DS
Intrusion detection tools DS
Operational integrity Transaction processor DB DS
Semantic integrity Entity integrity DB DS
Referential integrity DB DS Domain integrity DB DS User-defined integrity DB DS Normalization DB DS Accountability Audit DB DS
Identity of real user to database server DS
Log analysis tool DS
Alert when breach detected DS Availability Hardware redundancy DB DS Backup DB DS Recovery DB DS Replication/partitioning DB DS Contingency plan DB DS Extended configuration DS Manageability
Security management tools DB DS
Assurance
Certification DB DS
Test security configuration DB DS
Vulnerability assessment tools DS Physical security
Secure buildings and equipment DB DS
This chapter concludes the investigation into security services and mechanisms, defined in current state database security, to be provided by all the servers in a virtual web database environment. The next chapter will define information security services and mechanisms for the complete virtual web database environment.
[BASS00] Bass J.
A look at eight -way server scalability,
Network World, 7 March 2000,http://www.nwfusion.com/reviews/2000/0703rev2.html [Sept 2001][BLAC99] Black K., Securing Microsoft SQL Server, The encyclopedia of computer security, www.itsecurity.com/papers/black.htm [July 2000]
[DYCK00] Dyck T., Openhack database gets cracked, eWeek, July 18 2000
[HOSS01] Hoss D., Data Warehousing Trend Report: Database Vendors Gear Up, www.dataWarehouse.com, 4 March 2001, [Sept 2001]
[LELI01] Lelii S., eWeek, Oracle, IBM zoom in on database security, 2 March 2001, http://www.zdnet.com [Jul 2001]
[NFO01] Informix Dynamic Server, Technical Brief,
http://www.informix.com/informix/techbriefs/ids/adv.htm [Sept 2001]
[ORAC01] Oracle home page, security www.oracle.com/security
[OSBO00] Osborn S., Sandu R., Munawer Q., Configuring role -based access control to
enforce mandatory and discretionary access control policies, ACM
transactions in Information and Systems security, Vol 3, No 2, Feb 2000
[PENT01] Pentasafe, http://www.pentasafe.com/products/vamsqlserver.htm
[RITT98] Ritter D., The middleware muddle , DBMS, May 1998
[SPEN01] Spenik M., Microsoft SQL Server's Security Model, Datamation, 22 March 2001, www.earthweb.com [Aug 2001] [HEIM00] [WYNK97] [WESS00] [ISSY01] [MULL00] [MORA01] NSAT00]
