Today when you hire an IT professional you can expect them to keep your business systems relatively secure.  People working in IT today know how to protect your network and maintain your computers.  Less common in the IT industry is an understanding of data security.  Data security involves but is not limited to:

• maintaining data accuracy.
• preventing unauthorized data access or manipulations.

All business computer systems require a standard level of perimeter security to prevent worms and viruses from entering the system.  At the same time some of these businesses require that multiple parties can access and manipulate data.  For example, your bank now offers online banking - allowing you to access their data and conduct tightly controlled manipulations of that data.  So the question becomes - how do we grant and control access to your computer systems in order to optimize efficiency and customer satisfaction, yet remain safe?  This is where the concept of perimeter security goes out the window and data security comes into play.  Depending on the nature of your business, you may benefit greatly by allowing employees, partners and clients to access your computer systems.

Protect Data at the Source
Most of the data in the world is stored in databases - and currently, most of those databases can be cracked!  Yes, databases can be secure if they are set up properly but the reality is that very few are.  Let's look at the vulnerabilities and some non-specific examples.

Vulnerabilities

• Vendor bugs: mistakes made by the manufacturer of the database system
• Poor Architecture: mistakes made by an IT team in the application of a database system
• Mis configurations: adjusting database system settings incorrectly
• Incorrect usage: using developer tools and languages to break into a database system

Vendor Bug Example
One of the largest (if not the largest) enterprise level database systems contains two manufacturing mistakes.

First, you can connect to the database system's command line listener and send the "help" command and it will return a list of all the commands at your disposal.  No ID or password required.

Second, using the C programming language you can create a fake data packet and send it to the database system.  If you make the packet correctly (actually you must make the packet incorrectly in a very specific way) - the database system will send back all the information it has recently received - including system authentication information.  You can use this information to access the system like any other authenticated user.

This un-named database system is used by most of the world's largest companies.

Poor Architecture Example
When setting up a database some developers do not put enough emphasis on the security of the data.  In the end the system works, but there are not enough controls in place and as a result, the data can become corrupted.  For example, if you want to store phone numbers then the database should accept only numeric data AND the user should be prevented from putting parenthesis around the area code.  If the database is expecting numbers but receives a mix of numbers and other characters - it will not accept the data.

Poor architecture is unfortunately quite common.

Misconfiguration Example
All database systems come with default installation settings which include a default user ID and password.  These default settings are easy to find because most manufacturers offer trial versions of their database systems.  If your developer sets up a system and forgets to delete the default user ID and password - anyone can access your database.

Incorrect Usage Example
The most widespread example of incorrect usage is the "SQL injection".  Over-simply stated, this is when someone comes to your website and fills out a questionnaire, but instead of answering the questions they enter commands for your database system to follow.  It is very normal for data and commands to be sent to the database together.  In fact, data can only be passed to a database when accompanied by commands.

Incorrect usage can be blocked by good architecture.

Recommendation
Did I mention that all of these problems can be avoided?  Now that you are aware of the threats, you should be able to distinguish between solution providers who are on top of these issues - and those who will leave your company's business information at risk.  (Even if you aren't always sure what they are saying, you'll at least have a rough idea of the subject matter.) Finding a good technology partner is vital and you should consider screening them through an organized request for proposals that includes coverage of security issues.