Assessing the Security Risk

In the same way that you need to gather specifications and plan the design of a database system, you need to assess security risks and develop a security plan before cooking up a security implementation. It's always easier to build security into a database system as it's being built than it is to add security features to a complete system, so if you're constructing a new database system, security considerations need to be factored in at the database design stage, not later on.

A security risk assessment can be performed on an existing database system right away, but if a new system is being created from scratch, you need to design the database structure before conducting the security assessment. Without the database structure, you have no way of knowing the scope of the security issues.

The first step in creating a good security implementation is to assess the security risk. The term "security risk" is a very general one. The risk can take a variety of forms:

• Your client information falls into the hands of your competitors and they begin to call on your customers.

• Your customers' credit card numbers are used by unscrupulous employees for their own purchases.

• A copy of your system is reverse-engineered by a competitor and your proprietary formulae or trade secrets are discovered , damaging or eliminating your competitive advantage.

• One or more of your employees don't know how to use the system properly, and they accidentally delete important information.

• Certain employees have the ability to edit scripts, and accidentally cause a business process to malfunction.

The concept of "data" should be thought of in broad terms. Data is certainly the data stored in the fields of a database, but it's also the organizational logic stored in the structure, scripts, and calculations of the database system itself. When you perform a security assessment, you should try to answer the following questions for each table or logical group of tables (a Purchase Order and the corresponding Purchase Order Items, for example) in the database system:

What's the worst thing that could happen if this data fell into the hands of a competitor or hostile user ?

What's the worst thing that could happen if all this data were deleted?

What's the worst thing that could happen if the system were tampered with so that this process started handling data incorrectly? For example, what if the line items on an order were assigned to the wrong order?

How long would it take to detect system malfunction errors like the one just described, and how much damage would be done in the mean time?

How much data entry work could you afford to lose in the event of a system failure or malfunction?

For the system itself, you should answer:

What's the worst thing that could happen if a copy of the system fell into the hands of a competitor or hostile user?

Even if data is available from other sources such as product catalogs or the company Web site, there are still reasons to secure your database systems. Just because the data isn't sensitive doesn't mean that it wouldn't be an inconvenience or even a drag on productivity if the system stopped working properly. If a system is left completely unprotected , there's nothing to stop poorly trained users from attempting system modifications. A user who has stumbled into layout mode can easily rearrange fields on a layout, or delete them from a layout.

The point is that even if data isn't sensitive, it's a good idea to implement at least a minimal level of security just to protect the proper functioning of the database system itself. That brings us to the topic of users. While you're evaluating security risk, you also need to identify the different classes of users who work with the system. After you've gathered this information, you're ready to formulate a security plan.