Security threats

Like any other system, a database is exposed to a range of common security threats. Some of them affect all types of system, but because databases make use of very specific technology, and because they contain large amounts of data, there are some threats that are of more concern than others.

The first scenario that may come to mind when thinking about database security is deliberate intrusion by an unauthorised user and the theft of information. However, threats come in many other forms and it is useful to categorise them in some way. Categorisation provides an overview of the variety of ways in which the system may be vulnerable, and like any other hierarchy it can act as a checklist during strategic planning.

Although threats can be categorised in many different ways, the table below is sufficient for the purposes of this module. It is not intended to be comprehensive, and students on security programmes will go on to develop a much more detailed picture.

Category	Deliberate	Accidental
Human	Abuse of privilege, Spoofing	Operational error
Software	SQL injection, Database rootkit, Denial of Service, Worms/viruses	Incompatibility
Hardware	Sabotage	Power failure, Disk failure
Environment	Terrorist attack	Natural disaster

Some threats such as denial of service (DoS), worms and viruses are common to all systems that are connected to the internet. Because they are not specific to databases, we will not be discussing the details here. Suffice it to say that they should form part of the company's overall security strategy.

Database rootkits are a special category of software threat which are designed to take control of the database application itself and provide administrator privileges. Although they affect the database specifically, they can only be used if the underlying operating system is compromised, and therefore concern operating system vulnerabilities more than those of the database system. Again, the details will not be considered here.

Threats in the hardware and environment categories are most effectively addressed through the appropriate planning and operation of backup strategies which are discussed in a later section of these notes.

Although the table divides other threats into the human and software categories, it is immediately obvious that those in the software category also involve humans beings when the threat is deliberately applied. The purpose of separating the two categories is to highlight the possibility of abuse of privilege by those people who have been specifically granted access to the database. This includes legitimate users taking advantage of their access rights to steal or otherwise compromise the contents of the database, as well as users who have been given access to parts of the data that they do not need to see or use in their working roles. These issues will be discussed under the heading of users and schemas, and measures to restrict access are described in the section on row-level security.

One of the common issues with all of the threats in the deliberate column is that the database security strategy must be able to detect when any of these situations occurs. Cases of spoofing, for example, in which an unauthorised user tries to gain access by using someone else's credentials can be very difficult to detect at the time, but in a later investigation, the existence of a record of all logins can be crucial in identifying them since the real user will be elsewhere at the time. Control over user accounts and the privileges they have are therefore one side of the equation, while an accurate audit trail of system access is another. These measures have a technical side which is the responsibility of the DBA, and they also have a procedural side which is typically set at a higher level of management. The security policies and procedures define how, when and how often user details are reviewed and what records are kept of account changes and system access. In this module, we are more concerned with the practical aspects of database administration, and these will be discussed in the section on users and schemas. The policy and procedural side will be left for later modules in relevant programmes of study.

One very specific threat to database security is SQL injection in which an attacker uses technical knowledge about the syntax of SQL and the architecture of database applications to gain unauthorised access to data. To understand fully how SQL injection works and how to guard against it requires an understanding of application architecture which not all students have at this point. Briefly, SQL injection means forcing an application to execute a series of SQL statements rather than the single one that was planned by the application programmer. The following example will illustrate:

Login dialogLet us say that an application requires users to log in, and presents the usual dialog as shown on the right. The user enters their credentials and clicks on the Login button. In order to verify the user's identity (authentication) and allocate the appropriate privileges (authorisation), the application code must embed the credential values into an SQL statement such as the one below. You have already seen the use of substitution variables where the variable name is replaced by the supplied value when the statement is executed. When the correct values are used, the statement below works as planned.

    SELECT  access_level
    FROM    users
    WHERE   username = '&username'
    AND     password = '&password';

However, let's say that instead of entering a simple password into the field on the screen, the user enters the string:

    rubbish'; SELECT * FROM users;

Because of the careful placement of the single quote and semicolon characters, when the string is substituted for the variable &password, the result is actually two SQL statements and one statement fragment as shown below. When this short script is executed, the first statement returns no rows, but the second one displays all of the data in the USERS table. This allows the attacker to select a set of genuine login credentials and spoof a real identity. The remaining code fragment simply produces an error.

Statement 1

    SELECT  access_level
    FROM    users
    WHERE   username = '&username'
    AND     password = '&password';

Statement 2

    SELECT  *
    FROM    users;

Fragment

    ';

Countermeasures against SQL injection can be built into the application code, and are therefore left for later application development modules.

Another threat which can be best countered by the design of the application is operational error. Although it is impossible to completely eliminate human error, an application can include verification checks and other constraints on the data that can be entered by a user. To a certain extent, user training and company procedures can also be effective against this threat, but again they is beyond the scope of this module.

Finally, because the DBMS is a software application that is installed alongside others and depends on the services provided by the operating system, it is possible for incompatibilities to arise. This can happen for example when the operating system or some component of the operating system is upgraded and the existing DBMS is only compatible with the earlier version. The only effective way to guard against this type of threat is for the DBA and other systems administrators to be systematic and rigorous in the way they plan and implement upgrades. As well as paper research with the software release notes, the planning process can involve a trial run of the upgrade on a copy of the operational system followed by a period of testing to ensure that the new configuration is stable. These issues however start to delve into the details of the DBA's work that are well outside the scope of this module.