Why Secure Your Database?
You're behind a firewall. Port 1433 (for SQL Server) is blocked. You've got passwords set on the accounts used by the web server, ERP software, etc. You've got intrusion detection, virus scanners, even an information security group. Why bother with the other database Servers? Consider this.
Jim Smith used to work for your company. He was a technical sales engineer that supported the sales group in making presentations to customers. Unfortunately, his position was eliminated during the slow economic times and he was laid off.
And he's not too happy about it.
Fortunately for Jim, a competitor hired him shortly after he was let go, but he needs to generate some quick sales to be sure that he keeps his new job. He's under pressure, and perhaps asked to use some of his knowledge of your company to successfully compete against them. Does he remember any pending sales customers in the queue? What advantages can his new company gain when trying to make sales against your company?
Jim has a laptop and decided to purchase a wireless NIC. He knows your company was piloting the Cisco series of cards and chooses one of these. He then drives over to your company and parks in the visitor lot. After booting up his laptop, he connects to the wireless network. He can't log into the domain, but he's a little savvy about databases.
He starts scanning for SQL Servers using the common port (1433). He knows by default that there is an account called "sa" and it often has a blank password. Within an hour, he has found a few servers that allow him to connect.
Including one that stores data transferred from your financial server.
From there, it's a short hop. Using a well known account and password, he easily then makes direct queries against your financial server and learns a number of things about the sales pipeline.
Jim has a couple successful sales for his company, at the expense of your company and he keeps his job.
Unethical? Perhaps. Maybe even criminal. But not likely to be proven, nor prosecuted.
Another scenario to think about. Suppose Jim can't connect from the wireless network. He calls a few friends and suggests lunch, conveniently neglecting to tell them he's working for a competitor.
"How about if I come up and say hi to a few people?"
His friends are happy to oblige. Be nice to see Jim. He comes over and is escorted into the building. He shakes some hands and sits down to talk to a few friends at an empty cubicle. As people talk, he pulls out his new iPaq to record some numbers.
"Getting full, let me send these to my home email"
He plugs his iPaq into an empty Ethernet socket, telling everyone how he has this slick setup at home and can upload his address book from here, without logging onto the network to his home machine.
Everyone's impressed.
Meanwhile his iPaq is now running the scan mentioned in scenario 1. He has written scripts to try and connect to your financial server. In ten minutes he's done, everyone is impressed and they go to lunch.
And he makes some significant sales the next month.
This happens all the time. Information warfare is the reality in today's world. Whether by your direct competitors, foreign governments, or just bored graduate students. Your network is constantly being attacked. And not always through the firewall.
Your databases contain the most important information used by your company. Great efforts, both time and resources, are spent ensuring the external walls of the company are protected by firewalls. Most large companies have an information security department or group. Yet there are always vulnerabilities, many of which can be avoided.
Security is a series of steps, a series of small walls, each designed to increase the total security of the asset. Having one extremely strong frontal wall with lots of vulnerabilities may not be better than small steps taken at every asset with no frontal wall. It may even be worse.
Wireless networks, worms (Digispid.B.Worm), SQL Injection (Advanced SQL Injection) are all techniques that can circumvent firewalls and be used to gain access to your databases. There is no excuse for most of these vulnerabilities. Managing change, having central architectural decisions made, and auditing could easily prevent most of these from ever becoming issues.
As could setting and changing passwords.
Conclusions
This is a fictional story. However it's one that occurred to me when examining some of the potential security vulnerabilities in my own systems. And, IMHO, it's possible without too great a stretch of the imagination.
I welcome some feedback on this article and I'd love to hear about any other potential vulnerabilities of which you are aware.
Steve Jones
©dkRanch.net October 2002
