Modern software contains flaws.
While we all strive to deliver software that is bug free, in reality no one succeeds in that quest. It does not matter how experienced your team or how large your budget, in the end you are going to have a defect, or a feature deviation that slipped through the cracks. One of the more famous examples of a software bug that made it past all checks is the Ariane 5 disaster. After ten years of development, supported by a seven billion USD budget, a simple conversion error caused the rocket to explode just 40 seconds into its maiden flight, causing the loss of the rocket and four uninsured satellites valued together at 500 Million USD.
Defects happen in all types of software, and operating systems like Windows as well as database management systems like SQL Server are no exception. Most of these defects are not as expensive as the one mentioned above. But they can have a significant impact to your bottom line.
If a software product deviates from its intended feature set, often that deviation can be used by malicious users to gain access or elevate their permissions.
Just look at the race between Apple trying to protect their iOS operating system and different hacker groups being successful again and again in publishing so called Jail Breaks. On a Jail-Broken iPhone, you can install software that did not go through Apples tight control process. I am not going to start a discussion about the advantages or disadvantages of Apple's app approval process. However, Apple has a dedicated and highly skilled security team working on trying to find and eliminate these bugs before they can be misused for jail breaking. Still, while it sometimes takes a few weeks, the "bad guys" seem to always find a way in.
The same can be said about the operating system and the database management system you are running right now. They contain bugs, and those bugs can be misused by people with malicious intentions. Therefore, it is of utmost importance that you keep your software up to date by establishing a strong patch management strategy.
If a bug causing a vulnerability is discovered by a bad guy, that one person or group could gain access to your server. You could argue that this is an unlikely scenario and that you cannot protect yourself against it anyway. However, once this vulnerability is published which often happens around the time a patch is made available by the software vendor, everybody out there can use it. Worse, shortly after a vulnerability is published, the common hack automation tools start to include exploits for it. Once that happens, everyone, even people with little or no hacking experience can now use this vulnerability against you.
The only good thing in this story is that quite often this all happens after the vendor has made a patch available. So you can protect your system and your data. But only if you actually apply the patches.
Because patches often contain security-related software improvements, and because information about the underlying problems is publicly available in most cases, you have to install software patches as soon as feasible. We all know that company policies sometimes get in the way of this. However, you should always have a patch management strategy in place and install patches when possible.
Thinking that upgrades are not important is a dangerous fallacy that can cost you in the long run. The time to act is now. If you do not have a patch management strategy in place, set one up today and start working on applying those patches.
An inadequate patch management strategy is one of the most commonly encountered database security problems. In this series of posts, I discuss 10 of them. Below are the ones that are published so far: