We are so focused on the security issues that come over a network that we tend to ignore physical threats to our database installation. Certainly, we need to worry about a disgruntled employee with a hammer, but there is more to physical security risks than that. The major issue today is physical access to a server by a knowledgeable data thief.

All servers have at least one user account that has access rights to the entire computer. When the servers are housed in a locked location, operators tend to leave the privileged user account logged in. It makes administration just a bit easier. The operators rely on the security on the server room door to keep unauthorized people out. The problem with this strategy is that sometimes physical barriers aren't sufficient; a knowledgeable data thief will be able to circumvent whatever lock has been placed on the server room door and gain physical access to the servers. If the privileged accounts are left logged in, all the thief needs to do is sit down at a machine and start extracting data.

External threats are initiated by people known in the hacking community as crackers. Initially, the term hacker referred to someone who could write an ingenious bit of software. In fact, the phrase “a good hack” meant a particularly clever piece of programming. Outside of the hacking community, however, anyone who attempts illegal access to a computer network is called a hacker.

Hacking often involves becoming intimate with the details of existing software to give the hacker the knowledge necessary to attempt an unauthorized system break-in. Nonetheless, those who adhere to the original definition of hacker wanted to differentiate themselves from those who perform illegal activities, thus the term cracker.

There are many ways to classify those who break into computer systems, depending on which source you are reading. However, most lists of the types of hackers include the following (although they may be given different names):

When a hacker targets your network, what might you expect? There are a number of broad categories of attacks.

In most cases, employees know more about a network and the computers on it than any outsider. At the very least, they have legitimate access to user accounts. IT personnel, of course, have various levels of increased access. Intentional employee security threats include the following:

As dangerous as the intentional employee security threat may be, employees can also cause a great deal of damage unintentionally, such as the following:

Most unintentional employee threats theoretically can be handled through employee education. For example, it seems logical that instructing employees not to write passwords on sticky notes that are then fixed to monitors would help prevent compromised passwords. However, when you are dealing with human beings, even the best education can be forgotten in the stress of getting a job done on time.

Employees certainly can unintentionally damage a network. In addition, true accidents also occur. A security plan should guard against data damage and loss caused by

Guarding against accidental network damage includes power protection—for example, surge protectors and UPSs—and comprehensive backup schemes. When done well, backup takes significant planning and disaster recovery rehearsals.

A firewall is a piece of software that filters incoming and outgoing network traffic and stops messages that violate the rules that define allowable traffic. It is typically placed between the Internet and an internal network. Its primary job is to eliminate as much undesirable network traffic as possible.

If you look at Figure 15-1, you’ll notice that the network looks very much like something that might be used by SmartMart from Chapter 13. Specifically, it includes a Web server that is exposed to the Internet through a router and a database server that is isolated from the Web server by a second firewall.

The first firewall—the one connected to the edge router—allows specific messages to pass, including those intended for the Web server and for destinations that represent legitimate network traffic (for example, e-mail and remote employees).

The edge router will send all Web traffic to the Web server, preventing it from getting onto the internal network. However, because Web users need access to data stored on the database server, simply routing that traffic to the Web server doesn't provide protection for the database.

To protect the database, only messages from the Web server are permitted to interact with the database. A second firewall has therefore been placed between the two servers. The Web server is said to reside in a DMZ, a part of the network that is walled off from the internal network.

A Web transaction that involves access to the database server proceeds as follows:

Notice that internal users have direct access to the Web server without having to pass through the DMZ. The assumption is that internal users will be authorized for direct database access.

When a database server is infected by malware, it can be a serious problem. The result may be loss of data, loss of access to the database, or loss of control of the database server's hardware. Protection against malware is typically provided by “virus protection” software running on firewalls and the servers themselves.

Most current virus protection software handles worms, Trojan horses, and bots as well as viruses. The most important thing to keep in mind, however, is that there is an ever-escalating battle between those who write malware and those who produce the virus protection software. As soon as a new threat is identified, the software developers rush to add the new malware to their protection database; the malware producers then write new malware that is typically more powerful and more sophisticated than previous releases. You can never be completely safe from malware because there is always a lag, however brief, between the detection of a new piece of malware and the updating of virus protection software to handle that malware. The best thing you can do is update the database that accompanies your virus protection software regularly.

Because a buffer overflow problem is a flaw in the way software is written, there is really nothing an organization without access to the source code and a staff of programmers can do to fix it. An organization must rely on the software developer to release updates (patches) to the code.

Patching is a cooperative operation in that once the vendor has released a patch, it is up to organizations using the software to install the patch. Nonetheless, the best defense against buffer overflow vulnerabilities (and any other vulnerabilities caused by bugs in software) is to apply all available patches.

Patch management can become a nightmare for an IT staff. There are so many patches released for some types of software (for example, Microsoft Windows in all its myriad versions) that it is difficult to know which patches are important and stable and, in a large organization, which patches have been applied to which machine. Nonetheless, to protect your database server (both the operating system and the DBMS), you must work with IT to ensure that all necessary patches have been applied.

Physical security requires a two-pronged approach: preventing physical access to the server and, should that fail, securing the administrative accounts. Actual physical methods include any or all of the following:

The recording produced by security cameras and smart locks must be examined regularly to determine if any unusual access patterns appear.

Should an unauthorized person manage to defeat the physical security, he will probably want to gain software access to a computer. (We are assuming that physical damage to the equipment is a rare goal of an intruder.) This means that the administrative accounts for each server must be secured. First, the accounts should never be left logged in. It may be more convenient for operators, but it makes the servers vulnerable to anyone who happens to walk by. Second, login attempts to the administrative accounts should be limited. For example, after three failed attempts to log in, the server should disallow further login attempts for some predetermined length of time.

Any user who is permitted direct access to a database must first be authenticated for access to the local area network. The forms that such authentication takes depend on the size and security risks of the network. Positive user identification requires three things:

The first can be achieved with passwords, the second with physical login devices, and the third with biometrics.

Remote access to a database is typical today. Users travel; users work from home. The days are long gone where remote users dialed into their work network using a modem and a standard telephone line. Most remote access reaches an internal network over the Internet. The problem facing a database administrator is ensuring that the data remain safe while traveling on the external network.

One commonly applied solution is a virtual private network (VPN). VPNs provide encryption for data transmissions over the Internet. Although there are several types of VPNs, many use a security protocol known as IPSec, including the VPNs that are built into desktop operating systems such as Windows and Mac OS X.

IPSec encrypts the data, turning it into something that is meaningless to anyone who does not have the secret encryption keys. Even if data are intercepted while traveling over the Internet, they will be useless. We say that IPSec provides a secure tunnel for data (see Figure 15-3). One type of tunneling encrypts data only when it is actually on the Internet; the other provides end-to-end encryption where data are encrypted from the sending computer to the destination network.

To operate a VPN, the destination network must have a VPN server, a machine that receives all incoming VPN traffic and handles authenticating the VPN user. The VPN server acts as a gatekeeper to the internal network. Once authenticated, VPN users can interact with the destination network as if they were physically present at the network's location.

Social engineering isn't a technical attack at all but a psychological/behavior attack, so it can't be stopped by technical means. It requires employee education to teach employees to recognize this type of attack and how to guard against it.

As an example, consider the following scenario: Jane Jones is the secretary for the R&D department of a high-tech firm. Her boss, John Smith, often works at home. Ms. Jones has been with the company for many years, and she is a trusted employee. She knows the user names and passwords for her computer, Mr. Smith's desktop and laptop, and Mr. Smith's mainframe account.

One morning, Ms. Jones receives a telephone call. “Ms. Jones, this is James Doe from IT. I have some upgrades that I need to install on your computer and Mr. Smith's computer. I don't need to come to your office. I can do it over the network if I have the user IDs and passwords.”

“Oh, that sounds fine,” says Ms. Jones. “I hate it when IT has to come by and interrupt my work to fix something. My user ID is . . .” (she gives Mr. Doe the user names and passwords).

Unfortunately, the man who claims to be James Doe isn't who he says he is. He's a hacker, and with just a little research and a phone call, he has received access to two corporate desktops. First, he checked the corporate directory online. It was simple to find the name of an IT employee, as well as the names of the head of R&D and his secretary. Then all he had to do was place a phone call to Ms. Jones. She cooperated, and he was in business.

The phony James Doe does install a file or two on each of the compromised computers. However, the files are actually a Trojan horse that he can activate later when he needs control of the compromised machines.

Ms. Jones made one critical error: She revealed user names and passwords. She felt comfortable doing so because she knew that someone named James Doe worked for IT. She had never thought that there would be a problem trusting someone from that department; the idea of an impersonator never crossed her mind.

There is no technological solution to a social engineering attack of this type. The best prevention is employee awareness. Training sessions with role playing to demonstrate how such attacks are perpetrated can be very helpful. A few simple policies will also go a long way:

An organization should also take steps to restrict the information that it makes public so it becomes more difficult for a hacker to develop a convincing social engineering attack. For example, employee directories should not be available publicly. Instead, use titles (such as “IT Manager”) in any contact lists that are accessible to nonemployees. Organizations with registered Internet domain names should also restrict the information available to those who issue a “whois” command on the domain name.

There are many things an organization can do to guard against other employee threats:

The user IDs and passwords we discussed earlier in this chapter are used to give a user access to a network. They do not necessarily (and probably shouldn't) give access to a database. Most of today's relational DBMSs provide their own user ID and password mechanism. Once a user has gained access to the network, he or she must authenticate again to gain direct access to the database (either at the command line or with an application program).

It is important to distinguish between direct access to the database and account access by Web customers. Someone making a purchase on a Web site does not interact directly with the database; only the Web server has that type of access. A Web user supplies a user name and password, both of which are probably stored in the database. The Web server sends a query to the DBMS to retrieve data that match the user ID/password pair. Assuming that a matching account is found, the Web server can then send a query to retrieve the Web user's account data. Web customers cannot issue ad hoc queries using a query language; they can only use the browser-based application provided for them. Therefore, there is little that the typical Web user can do to compromise the security of the database.

However, internal database users have direct access to the database elements for which their accounts have been configured. They can formulate ad hoc queries at a command line to manipulate the tables or views to which they have access. The trick, then, is to tailor access to database elements based on what each user ID “needs to know.” A relational database accomplishes this by using an authorization matrix.

Most DBMSs that support SQL use their data dictionaries to provide a level of security. Originally known as an authorization matrix, this type of security provides control of access rights to tables, views, and their components.

When you create an element of database structure, the user name under which you are working becomes that element's owner. The owner has the right to do anything to that element; all other users have no rights at all. This means that if tables and views are going to be accessible to other users, you must grant them access rights.

The internal database security measures we have discussed to this point assume that we know which users should have access to which data. For example, does a bookkeeper need access to data from the last audit or should access to those data be restricted to the comptroller? Such decisions may not be as easy as they first appear. Consider the following scenario (loosely based on a real incident).

The Human Relations department for a small private college occupies very cramped quarters. Personnel files have not been converted to machine-readable form but instead are stored in a half dozen locked four-drawer file cabinets in the reception area, behind the receptionist's desk. The receptionist keeps the keys to the file cabinets and gives them to HR employees as needed.

The problem with this arrangement is that the receptionist, who is a long-time college employee, has a habit of peeking at the personnel files. (She is known for having the juiciest gossip in the building at break times.)

One day the receptionist comes in to work and sees that the file cabinets are being moved out of the reception area. In their place, a PC has been placed on her desk. The new HR system is online, and an IT staff member has come to train the receptionist. She has a word processor, access to the college faculty/staff directory, and an appointment scheduling application.

The scene degenerates from there.

The problem would appear to be that the HR receptionist should never have had access to the personnel files in the first place. However, it's a bit more complicated than that. Access to information makes people feel powerful. It's the “I know something you don't know” syndrome. Remove or restrict access, and many people feel that they have lost power and status in the organization.

Some organizations have solved this problem by appointing a committee to handle the decisions about who has access to what. Users who feel that they need additional access must appeal to the committee rather than to a single individual. This protects the staff members who are making the decisions and provides broader input to the decision-making process.

The other side of this issue is data sharing. Occasionally you may run into employees who have control of data that have to be shared, but the employee is reluctant to release the data. Whether it is a researcher who controls survey data, a district manager who handles the data about the sales department, or a salesperson who guards the data he collects when in the field, psychologically the issue is the same as determining data access: Access to data and controlling data can make people feel powerful and important.

Data sharing can be mandated by a supervisor (if necessary, as a condition to continued employment). However, it is often better to try to persuade the data owner that there is benefit to everyone if the data are shared. By the same token, the committee that makes decisions about data access must also be willing to listen to the data owner's arguments in favor of keeping the data restricted and be willing to agree if the arguments are compelling.

We don't usually think of backups as a part of a security strategy, but in some circumstances it can be the most effective way to recover from security problems. If a server becomes so compromised by malware that it is impossible to remove (perhaps because virus protection software hasn't been developed for the specific malware), then a reasonable solution is to reformat any affected hard disks and restore the database from the most recent backup. Backups are also your only defense against physical damage to data storage, such as a failed hard disk.

A backup copy is a usable fallback strategy only if you have a backup that isn't too old and you are certain that the backup copy is clean (in other words, not infected by malware).

How often should you make backup copies? The answer depends on the volatility of your data. In other words, how much do your data change? If the database is primarily for retrieval, with very little data modification, then a complete backup once a week and incremental backups every day may be sufficient. However, an active transaction database in which data are constantly being entered may need complete daily backups. It comes down to a decision of how much you can afford to lose versus the time and effort needed to make backups often.

Assuming that you have decided on a backup interval, how many backups should you keep? If you back up daily, is it enough to keep a week's worth? Do you need less or more than that? In this case, it depends a great deal on the risk of malware. You want to keep enough backups that you can go far enough back in time to obtain a clean copy of the database (one without the malware). However, it is also true that malware may affect the server operating system without harming the database, in which case the most recent backup will be clean. Then you can fall back on the “three generations of backups” strategy, where you keep a rotation of “child,” “father,” and “grandfather” backup copies.

It used to be easy to choose backup media. Hard disk storage was expensive; tape storage was slow and provided only sequential retrieval, but it was cheap. We backed up to tape almost exclusively until recently, when hard disk storage became large enough and cheap enough to be seen as a viable backup device. Some mainframe installations continue to use tape cartridges, but even large databases are quickly being migrated to disk backup media. Small systems, which once could back up to optical drives, now use disks as backup media almost exclusively.

The issue of backup has a psychological as well as a technical component: How can you be certain that backups are being made as scheduled? At first, this may not seem to be something to worry about, but consider the following scenario (which is a true story).

In the mid-1980s, a database application was installed for an outpatient psychiatric clinic that was affiliated with a major hospital in a major northeastern city. The application, which primarily handled patient scheduling, needed to manage more than 25,000 patient visits a year, divided among about 85 clinicians. The database itself was placed on a server in a secured room.

The last patient appointment was scheduled for 5 PM, which was when most staff left for the day. However, the receptionist stayed until 6 PM to close up after the last patient left. Her job during that last hour included making a daily backup of the database.

About a month after the application went into day-to-day use, the database developer who installed the system received a frantic call from the office manager. There were 22 unexplained files on the receptionist's computer. The office manager was afraid that something was terribly wrong.

Something was indeed wrong, but not what anyone would have imagined. The database developer discovered that the unidentified files were temporary files left by the database application. Each time the application was launched from the server, it downloaded the structure of the database and its application from the server and kept them locally until the client software was shut down. The presence of the temporary files meant that the receptionist wasn't quitting the application but only turning off her computer. If she wasn't quitting the database application properly, was she making backup copies?

As you can guess, she wasn't. The only backup that existed was the one the database developer made the day the application was installed and the data were migrated into the database. When asked why the backups weren't made, the receptionist admitted that it was just too much trouble. The solution was a warning from the office manager and additional training in backup procedures. The office manager also monitored the backups more closely.

The moral of this story is that just having a backup strategy in place isn't enough. You need to make certain that the backups are actually being made.

The term disaster recovery refers to the activities that must take place to bring the database back into use after it has been damaged in some way. In large organizations, database disaster recovery will likely be part of a broader organizational disaster recovery plan. However, in a small organization, it may be up to the database administrator to coordinate recovery.

A disaster recovery plan usually includes specifications for the following:

The location of backup copies is vitally important. If they are kept in the server room, they risk being destroyed by a flood, fire, or earthquake along with the server itself. At least one backup copy should therefore be stored off-site.

Large organizations often contract with commercial data storage facilities to handle their backups. The storage facility maintains temperature-controlled rooms to extend the life of backup media. They may also operate trucks that deliver and pick up the backup media so that the off-site backup remains relatively current.

For small organizations, it's not unheard of for an IT staff member to take backups home for safekeeping. This probably isn't the best strategy, given that the backup may not be accessible when needed. Some use bank safe deposit boxes for offsite storage, although those generally are only accessible during normal business hours. If a small organization needs 24/7 access to off-site backup copies, the expense of using a commercial facility may be justified.

When a disaster occurs, an organization needs to be up and running as quickly as possible. If the server room and its machines are damaged, there must be some other way to obtain hardware. Small organizations can simply purchase new equipment, but they must have a plan for where the new hardware will be located and how network connections will be obtained.

Large organizations often contract with hot sites, businesses that provide hardware that can run the organization's software. Hot sites store backup copies and guarantee that they can have the organization's applications up and running in a specified amount of time.

Once a disaster recovery plan has been written, it must be tested. Organizations need to run a variety of disaster recovery drills, simulating a range of system failures. It is not unusual to discover that what appears to be a good plan on paper doesn't work in practice. The plan needs to be modified as needed to ensure that the organization can recover its information systems should a disaster occur.