Step-by-Step Guide: How to patch SQL Server

Chip Andrews, Contributor

So you've decided to secure your SQL Server infrastructure and you don't know where to start. This first guide in a two-part series on SQL Server patch deployment will help you track down those pesky servers before getting them properly patched.

More on SQL Server migration and related topics

Learn how

    Requires Free Membership to View

SQL Server Upgrade Assistant can simplify transitions

Find out if SQL Server Express is right for you

Get an idea of what features to expect from SQL Server 2014

SQL Servers represent a significant security challenge for a number of reasons. Primarily, they are ubiquitous. Hundreds of software packages use SQL Server as a data store as do a large number of commercial websites. In addition, since SQL Server 2000 can have multiple instances on a single machine that must each be patched separately, developers generally have at least one instance for their local builds or sample applications. SQL Server has features not rolled into Microsoft's Windows Update or Windows Update Services Tools and thus the servers rarely receive the patching attention they deserve. And finally, SQL Servers usually run with a very high level of privilege (LocalSystem) despite the fact that SQL Server 2000 defaults to the designation of a domain user account.

Most people run SQL Server as a LocalSystem account, and there are several reasons: They never took the time to ask their administrator for a domain user account for SQL Server; they don't know that a local user account will also work in most cases; and using LocalSystem is so much more convenient since no account creation is needed at all. In the world of users (and, sadly, some systems administrators and developers), convenience has long trumped security.

The first thing we need to do in order to patch our SQL Servers is to get our infrastructure identified and assessed so we can prepare a plan to patch them.


 Home: Introduction
 Step 1: Map your network
 Step 2: Perform an active scan
 Step 3: Check for SQL registrations
 Step 4: Probe remote services
 Step 5: Probe for SSNetlib.dll versions
 Step 6: Directly request version information
 Go to: How to patch SQL Servers, part 2


Chip Andrews is the director of research and development for Special Ops Security Inc. and the founder of the Web site, which focuses on Microsoft SQL Server security topics and issues. He is also the author of SQL Server Security.

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: